real time shadows

[fabricator]

I've been experimenting with BS Contact's shadow extensions, by removing the unneeded junk from their example. Namely the fake spot light texture and all the code that relates to it.

So I have a scene now with basic shadow casting, with a flat surface as the ground, and randomly moving avatars (bots) as the objects. Now it looks good most of the time, but there are ugly artefacts showing up in the shadow, so I have to look at that.

Of note is the ground cannot have a transform applied it to, that makes a mess of the shadow so it doesn't match the avatars any more.

A future test is going to be to see if it works on uneven ground, like say a hill.

I'll post some files later.

[vcard]

Great you are working on that Fab!

Shadows are one important aspect to make worlds look more realistic and some kind of automatic way to make them will be very welcome ;)

[alain]

""Great you are working on that Fab!""
yesssssssssssss

btw I absolutly dont care about realism or social realism , lol scuse vcard , just a joke ,
but I care a lot about shadows , because of Platon :)

and more about dynamic shadows , or dynamic platonism :)

go on , guys ,

thanx in advance

( by permission , I gues :

http://dumenieu.free.fr/louizeforum/seamless/lucy_amy.jpg







http://dumenieu.free.fr/louizeforum/seamless/lucy_amy.jpg

[fabricator]

Of the three different examples on the bitmanagement site, only one has multitexturing. Which means it has a shadow and a ground texture.

So far I've fiddled a bit with the other two examples, but I can't get it to work with two textures. Could be a bug in BS Contact though, but I'll try using the two other texture methods in the one that does work.

[Steve]

Yes, excellent project Fab. I know alot of people are curious if this can really work as a dynamic solution to shadows. The uneven terrain aspect is the on that I am curious about.

Also I am curious is this something that Bitmanagement has set up just for avatars or is this something a builder can attach to all outdoor objects in a world as well? If the ability to have dynamic shadows that react to light source is possible then truly vrml is going to get a jump start.

:)

[fabricator]

Steve said:

Yes, excellent project Fab. I know alot of people are curious if this can really work as a dynamic solution to shadows. The uneven terrain aspect is the on that I am curious about.

Also I am curious is this something that Bitmanagement has set up just for avatars or is this something a builder can attach to all outdoor objects in a world as well? If the ability to have dynamic shadows that react to light source is possible then truly vrml is going to get a jump start.

In the first example it has some moving objects and a moving spot light. I replaced the moving objects with an avatar test scene (20 avatars or something), plus also removed the light effect.

So it just produces shadows from the avatars, but can easily be modified to have other objects in the scene generate shadows.

As for uneven ground, it uses shaders and texturecoordinate generators, so it should work. Still not tried it yet though.

[Steve]

Would love to see your tests! :D

[Steve]

"Of note is the ground cannot have a transform applied it to, that makes a mess of the shadow so it doesn't match the avatars any more."

I wonder if this had elevation grids in mind for use? IFS terrain can be placed and/or created to sit where you want it i guess but if this works with uneven terrain perhaps elevation grids will see a resurgance in use or at least more care given to creating IFS terrains.

I can still imagine that this would only be able to be used in a limited capacity but it will still be better than what we had before. ;)

[fabricator]

I'm stuck on one problem at the moment, all the examples seem to use localized lights, and hence apply perspective to the shadow texture mapping. It is done by a block of code involved Matrix operations, hence rather hard to understand, much less alter to my liking.

Some horrible artefacts from the perspective texturing, hence why it needs to be removed.

[Doctor]

fabricator said:

I'm stuck on one problem at the moment, all the examples seem to use localized lights, and hence apply perspective to the shadow texture mapping. It is done by a block of code involved Matrix operations, hence rather hard to understand, much less alter to my liking.

Some horrible artefacts from the perspective texturing, hence why it needs to be removed.

Would you be willing to share the code (or code fragment) with me? Perhaps I might be able to offer some small insights into what the matrix operations are doing.

[Doctor]

I had once considered trying to create a shadow PROTO that used the blaxxun collision detection extensions to generate a grey, semitransparent IFS that would be rendered just 1 or two millimeters above and below the surface on which the shadow should appear. My idea was to use the compute_rayhit extension (I forget its exact name) of blaxxun to cast rays from a single light source through all verticies of the avatar to construct a sort of prism from the avatar that represented its silouette (many rays would have to be somehow eliminated from all the ray casts to only leave the outside edges of the prism (huge amount of calculations already). The prism would then be intersected with the world geometry using the compute_collision extension (or some name like that) to retrieve the set of polygons of the world geometry that were inside the prism (even more intensive calculations). These returned polygons would then be used as the basis for two indexed face sets that hovered immediately above the world geometry and immediately below. In theory, if the processing speed was fast enough, one could update these shadow indexed-face-sets in real time and it would look like a shadow that followed the avatar.
Needless to say, I realized quite quickly that this would be way too computationally expensive, and since I could not come up with enough simplifications to the process I abandoned the idea.

I now think that one might be able to store within the avatar definition a set of precalculated profiles of the avatar (as would be seen from a variety of directions). The profiles could be projected down from the avatar onto an IFS (or other shape) in the world geometry using linear algebra transformations, rather than rayhit computations, thus avoiding most of the compute_rayhit and compute_collision calculations.
Such a system would be significantly faster than the first method that I mentioned, but the shadows would not always look exactly right (e.g. they would not follow a gesture made by a stationary avatar).
Still, the fact that any kind of shadow would appear in the right place on the ground below an avatar would do wonders for being able to judge the position and size of an avatar.
I am still unsure about how the shadow should actually be introduced into the scene (i.e. as the grey semitransparent IFS that slithered over the ground and objects below the avatar, or as a modification to the textures of the world geometry involved).

I would be interested in hearing the details of how it works in the bitmanagement extensions.

[Steve]

adding the shadows to the avatar iteself may not be the answer either. Although your idea would work at some level it would still leave alot of issues unresolved. With a fixed set of IFS' inside the avatar we would still be limited to a flat ground plane with no hope of actually having a shadow follow a more complex ifs or elevation type land grid. Also to compute the users position with an inworld light source that would require constant updates to the server to accomplish. I think that might be a bit costly on the server resources.

If you wire a print statement to a prox sensor's translation_changed event you can see how many events that actually sends. It will probably make more sense for these calculations to be done clientside through the browser instead of trying to make a half working model based on the server.

Just my 2 cents worth.

Doc,
I too did some work with shadows before and relaized how costly performance wise this could be. It would be easier code-wise to just use the world(wrl) code and avatar code but the results I dont think would get us much further in the long run. I think that Fab is on the right track if he can isolate the contact code for the local lighting and eliminate. then adding a routine to account for in world lighting will seem much more feasable. I still dont know, or have seen any examples of wether this contact shadows routine will be able to follow an elevation based ground plane. If it can then it has made a huge step. If not then it isnt going to be all that useful anyways. The worlds that use it will be limited to flat terrain or inside-building type environments only and the realism just wont be the same.

Although...
Some built in shadow function is still better than none. Maybe contact 10.0 will have what we are looking for. hehehe

Doctor said:

I had once considered trying to create a shadow PROTO that used the blaxxun collision detection extensions to generate a grey, semitransparent IFS that would be rendered just 1 or two millimeters above and below the surface on which the shadow should appear. My idea was to use the compute_rayhit extension (I forget its exact name) of blaxxun to cast rays from a single light source through all verticies of the avatar to construct a sort of prism from the avatar that represented its silouette (many rays would have to be somehow eliminated from all the ray casts to only leave the outside edges of the prism (huge amount of calculations already). The prism would then be intersected with the world geometry using the compute_collision extension (or some name like that) to retrieve the set of polygons of the world geometry that were inside the prism (even more intensive calculations). These returned polygons would then be used as the basis for two indexed face sets that hovered immediately above the world geometry and immediately below. In theory, if the processing speed was fast enough, one could update these shadow indexed-face-sets in real time and it would look like a shadow that followed the avatar.
Needless to say, I realized quite quickly that this would be way too computationally expensive, and since I could not come up with enough simplifications to the process I abandoned the idea.

I now think that one might be able to store within the avatar definition a set of precalculated profiles of the avatar (as would be seen from a variety of directions). The profiles could be projected down from the avatar onto an IFS (or other shape) in the world geometry using linear algebra transformations, rather than rayhit computations, thus avoiding most of the compute_rayhit and compute_collision calculations.
Such a system would be significantly faster than the first method that I mentioned, but the shadows would not always look exactly right (e.g. they would not follow a gesture made by a stationary avatar).
Still, the fact that any kind of shadow would appear in the right place on the ground below an avatar would do wonders for being able to judge the position and size of an avatar.
I am still unsure about how the shadow should actually be introduced into the scene (i.e. as the grey semitransparent IFS that slithered over the ground and objects below the avatar, or as a modification to the textures of the world geometry involved).

I would be interested in hearing the details of how it works in the bitmanagement extensions.