Hi! For those who still remember discussions about volumetric fog and for other guys (and girls who is interested in this topic: As we decide, volumetric fog can be defined by sphere or box for simplifying calculations, but what is the way to define volumetric lighing? Since it can shine on objects and cast shadows from it, making volumetric light rays (for example, sun shining thru opended window with/without window-frame). Also, since light shape will be more complex, will the techniques for volumetric lighting be acceptable, or there are different technique? ------------------------------------------------------------ FlyFire/CodeX
http://codexorg.webjump.com

Hi !!

Well, I think the same technic can be used for any "shape", because the principle is always the same. My engine uses Volumetric Fog with Spheres and Boxes (for ground fog). I also tried to implement fog with mesh-shapes, so as you said, for example a window where bright line shines through. It was looking amazing (so the same technic works) however, the performance was very low.
I do not have much time at the moment to improve my algo, but I think with a little bit of optimizations it should work fine. However, you need a very, very fast "ray-triangle"-intersection-algo in order to do that in realtime. Using meshes you could also create great looking clouds, and all that stuff, but performance will be very, very bad.

If you try to keep your light volumes convex, it should be no problem at all to do volumetric lighting without shadow casting in realtime. Just approximate the light volume with a bunch of planes. A ''window'' consisiting of 4 little squares of glass can be approximated by multiple light volumes. As soon as you also want to catch shadows dynamically, things will get harder to do in realtime for arbitrary objects. My suggestion is that you do cast shadows dynamically (it is cool, and not seen before), but that you keep the shadow-casting objects simple so you can build a shadow volume tree fairly quickly.

I am interested in the results, since I plan on implementing such a thing myself when my basic 3D engine works.

Hi

I already thought about dynamic shadow casting, and i''ve found a way of doing it fast with convex object using precalculated links tree for building object''s silhouette viewed from given point (all in theory right now, because my rendering engine is not yet done).

But what about shadow volumes? How you think to implement them? For example, same light shining thru window, and there are a arbitrary oriented box inside that light volume, which will of cource cast some shadows. Hm, this can be handled by splitting intual light volume into pieces which will form new volume around object, but now calculations will be painly slow because of many new light volumes that can be created...

Another way of handling this stuff is using two buffers. First, you render all polygons which form light volume and which is oriented to the viewer into front buffer, then all back-faced polygons - into back buffer. Then just blend a light color onto screen using difference between front and back buffer as alpha value. Also, we can do the same with shadow volume and substract it from light buffer before blending. This raster method might be faster than complex calculations, but i don''t see the way how to done it in hardware (anyway, i''m making software rasterizer right now , but i''m also looking forward for future hardware implementation)

-----------------------------------------------------

FlyFire/CodeX
http://codexorg.webjump.com

A way to subdivide your light volume is to use a beamtree. This will handle the arbitrary box-in-front-of-the-window case you mentioned pretty well. After construction, the beam tree gives you information about what parts of the scene are ''in shadow'', and what parts are not, as seen from the light. For not too complex geometry it is also fairly quick to construct.

I do not entirely get your two-buffer algo, but it looks terribly slow to me. It is not well suited for hardware rendering adaption, since hardware hates it when you read from the card. This kills your rendering pipe, and it is usually slow implemented on every gfx adapter since it is such a special case. I did this with OpenGL, and my framerate dropped with more than 1000%. You are warned.

DaBit.

Hi

Well, where i can find a good complete tutorial about beam trees?



FlyFire/CodeX
http://codexorg.webjump.com