CompuServe Thread

#bend objects

3 messages in this thread
#123982From: Marion K. MarksSep 15, 1994 4:48 PM
Raytraced shadows has little to do with raytraced rendering. Basically, both Phong and Metal rendering compute the color of each pixel of an object separately. By determining whether a given light would illuminate that pixel of an object, either by mapped or ray-traced shadow algorithms, these can simulate shadows. Ray-traced rendering, though, means that the pixels of the objects themselves are computed by drawing a ray through each pixel and following it until it either hits a light or is blocked by another object (or part of itself), and repeating this for each light, to determine what color the pixel would be. This is far more time-intensive than merely ray-tracing shadows (which is itself time-intensive — compare how long it takes to render the same scene with raytraced shadows as opposed to mapped shadows). Radiosity takes this further, by allowing objects to reflect the illumination aspects of lights as well as to block them. In effect, each pixel of each object itself becomes a light source! This simulates the effect of light reflected from objects contributing to the overall illumination of a scene. 3DSr3 can fake this to a degree with Ambient lighting and carefully placed lights with exclusion lists and ranges, but it doesn't look anywhere near as realistic as the real thing. But then again, it doesn't take anywhere near as long to render, either. Raytracing is an order of magnitude, if not more, slower than Phong or Cook-Torrance (Metal) rendering. Radiosity is an order of magnitude, if not more, slower than raytracing! This is why SELECTIVE raytracing/radiosity would be so important. Currently, 3DSr3 has four shaders: Flat, Gouraud, Phong, and Cook-Torrance. 3DSr2 didn't have Cook-Torrance, but did have simple wireframe, which was even faster than Flat. (The Wire mode in 3DSr3 isn't a separate shader, but rather an instruction to the Renderer telling it to render only the pixels at or near the edges of an object, rather than the entire faces. This is how wireframes can now have mapping, specular highlights, etc.) Flat tells the computer to simply fill each face with a color computed by measuring the cosines of the normal angles to the angles of the lights, coupled with the surface properties of the material itself (diffuse and ambient color, plus texture maps). Gouraud computes each pixel's illumination based on the cosine of the normal angles of the pixels to the angles of the lights — for "smoothed" faces, anyway. Phong computes each pixel's color value in a more complex manner, enabling specular highlights, transparency falloff, bump-mapping, etc. Cook-Torrance works like Phong but in a manner that simulates the way metals reflect light, which is different from non-metals because of the dielectric properties of metals, and the fact that light is itself an aspect of the electromagnetic force. None of these actually involve following rays of light to their sources on a per-pixel per-light basis. Only raytracing and radiosity do that. Mapped shadows work by creating a square pixel matrix of NxN, where N is the "Shadow Map Size" parameter. This map is projected from the spotlight such that at any point it is perpendicular to the line which goes from the light to its target, and sized so that it exactly fills the falloff at that point as it would be if the light were set to Rectangular. This map is projected along the path of the light, and it starts with each pixel of itself having a value of "full illumination" (assume this to be 1 for the purposes of this discussion). As this map sweeps past objects in its path, any object whose Casts Shadows flag is set basically cuts a hole in the map, setting the pixels that intersect it to 0, with "feathering" along the edges according to the "Map Sample Range" value such that map pixels may end up being somewhere between 0 and 1. Where it intersects a surface with "Receive Shadows" set, the pixels of the object are illuminated by the light according to the values of the map as they intersect the surfaces — in effect, the light's illumination effect is multiplied by the current shadow map pixel value, and since that ranges from 0 to 1, the effect is to either use the full lighting (shadow map pixel=1), don't illuminate the object by this light at all (shadow map pixel=0), or illuminate it with partial effect (shadow map pixel between 0 and 1 — for instance, value .5 means the illumination works at 50% of the strength it would be without shadows active). This cutting of holes in shadow maps by Cast Shadows objects ignores the transparency of materials, since it's looking only at the objects themselves. This is why Mapped Shadows don't behave properly with transparency, or with opacity maps. Ray-traced shadows follow rays from each pixel of each Receive Shadows object that lies at least partially within the light's falloff, back to the light itself. If the ray is blocked by one or more Cast Shadows objects, the light's illumination is reduced according to the opacity of the materials in the intervening objects. If any intervening Cast Shadows object has 100% opacity (0% transparency) along the path of the ray, the illumination is set to 0 for that pixel. If no Cast Shadows objects lie along the path of the ray, or the total opacity of all such objects is 0 (all are set to 100% transparency, or have an opacity map with full black at the portions that intersect the ray), the illumination is set to 1. There are no provisions for soft-edged shadows with ray-tracing — either the ray is blocked or it isn't. (True raytracing can only do soft shadows by allowing lights to have sizes, and tracing rays back to each pixel of the surface of the light — a very time-consuming process, since effectively each pixel of the light's surface is like a separate Spotlight!) Because ray-traced shadows have no map, they use less memory — but the sheer time involved more than offsets this unless the alternative is shadow maps so huge they cause lots of swapping during rendering. Note that 3DSr3's ray-traced shadow process does NOT take into account objects reflecting and/or refracting the light — only blocking it or passing it through. True raytracing handles reflections and refractions. 3DSr3 just doesn't have this ability, period. As I've said already, raytracing and radiosity would require new shading types, selectable either for the whole scene or on a per-object or per-material basis. My proposal is for a new .RXP IPAS routine type, Renderer External Procedures, which could do raytracing, radiosity, new mapping types (say, refraction mapping while still being Phong or Cook-Torrance such as Crystal TOPAS Pro 5.0 can do), and whole new things we can't even imagine yet. Gary Yost himself said some time back that the Renderer was the last module of 3DS to lack IPAS abilities. I'm quite disappointed that such wasn't added for 3DSr4's IPAS4.
#124248From: ARA GREGORIANSep 17, 1994 7:15 AM
Wow!! Thanks a lot for putting in the time to type such a thorough, informative message. I defenatly learned a lot. Really!! Well in light of what you described, I guess Rayman is the way to go now. I love your Rxp idea and am willing to bet that R5 or Ipas5 will allow for this type of implementation!! But Refarction mapping, i believe can be done through the present Ipas. I think i wrote you a message about how this can be done?! If not let me know, i will send you my idea. Any way, again thanks a lot for this very informative message. I have already saved it for ref. Take care Ara
#124278From: CyberdreamsSep 17, 1994 12:46 PM
Yes very good reference! -brandon