CompuServe Thread

Alex, POV-Ray is available right here in GraphDev in the POV Sources LIB. If you have an IBM PC style machine the files you need are POVIBM.ZIP (the program it's self), POVSCN.ZIP (-lots- of example images) & POVDOC.ZIP (documentation files). As for importing 3DS files, there is a converter. It's posted here as 3DSPOV.ZIP. It converts 3DS ASCII Dump files to POV-Ray or Vivid format. Later — Bill There is 1 Reply. Read action !

Peter, Hmmmm, that could take volumes. <G> Basicly, Raytracing creates images by simulating the physics of light. We see something because light leaves a light source, reflects off of an object (& gets "filtered" in the process) & enters our eyes. Raytracing works basicly the same way although for practical considerations the actual calculations are, in most cases, run in reverse. (No need to calculate rays that dont actualy -enter- the eye) The rays are traced *from* the eye (camera) *to* the light source. Since the path of the actual ray is followed *all the way* things such as reflection, refraction shadows & the way a surface effects the light can be simulated very well. The drawback is you have to step thru a LOT of points in the scene to test whether, and exactly where, the ray intersects a surface. (And in the case of reflection/refraction you need to shoot out more rays for each point on the surface to see what should appear in -it- from other objects.) (Lots of tests = Long time… <g>) There are lots of ways of doing rendering similar to the way 3DS does it. Basicly algorithms are used to calculate shading & color on an object, when viewed from a particular point, based on the direction, color & intensity of light sources. This can be done quite quickly since you deal with the objects directly. They run into problems though when reflection, refraction or shadows occur. Since the actual path of the light is not followed there is no way to easily know -what- should reflect in, or show thru, any given object. One trick for reflection is to place the camera -at- the surface that is going to have the reflection *on it* in the final image, calculate the scene as "seen" from there, then take -that- image and map it -onto- the reflecting surface when the final image is made. 2 steps & not real accurate. You need to make sure the angles are correct or it "looks wrong" in the final image & the problems are compounded if the reflecting surface is curved. Raytracing can do it as part of the overall calculation & can be very accurate, but time consuming as a LOT more math needs to be done. Refraction is even more of a problem to deal with. There are several books on these subjects, & everybody is always looking for a quicker, more realistic way of doing things. Later — Bill There is 1 Reply. Read action !

Peter, Same as the difference between sports and football. <g> Raytracing is rendering, but rendering is not neccessarily raytracing. Commonly, though, rendering is usually used in the context of "cheaper" 3D methods. (I know I'm gonna catch flak with that word "cheaper", but it's the best word that comes to mind right now.) There is 1 Reply. Read action !