FastExtension 1.13 shadow solution

Blitz3D Forums/Blitz3D Userlibs/FastExtension 1.13 shadow solution

Sake906(Posted 2009) [#1]
This goes directed specially to MikhailV.

I have seen your work on the shadows, and to me it appears that most of the problems you are having on the following images are directly caused by something you overlooked:





Before you released this update, I have made my own shadow casting system that works very much the same way as this one (also aided by FastExt). What I do is to render my "casters" on a white space with an orthographic camera mode, changing their color to black and then making it so their rendered black has a slight color HUE to match the ambient light (by using lame camera fog).

To prevent the bugs as seen on the images, I simply took all the receivers, instanced them (copied and cached) and rendered their copy at the same time on the same "white" space of the casters, but changing their color to white (and removing textures and making them full bright, etc) during the shadow rendering process. This will automatically "clip" the black shadow casters by using their Zbuffer information. The white receivers being in front of the casters will also overlap the casters, preventing them from rendering all across the receivers.

Since the final result renders on multiply mode, the receivers which have been rendered as white meshes will not appear on the shadow texture.

I believe this is a very easy fix which you should consider.. it is actually the only reason why I am not using this new feature in the update and stick to my old, slower code :(


MikhailV(Posted 2009) [#2]
You right, BUT your method fix restriction from first image ONLY!

This not critical restriction. Why I shall not use your method (I knew his earlier) — since receiver can be any mesh (as example: whole level of the game containing >100000 triangles!). And render 2 times all receivers this unreasonably, this will vastly reduce speed of the shadow system and worsen situation, expressed on second image. Can be caster is found between two receivers (see second image) — your method destroys the shadow from it!

Too not unambiguous method to use him in shadow system, he can give unpredictable results and will tangle users.

p.s. You can modify included files (ShadowsSimple.bb & ShadowsMultiple.bb) to get necessary functionality. This is your right.


Sake906(Posted 2009) [#3]
Are you sure it reduces performance? the receivers would simply have a portion of them rendered, that's just a few additional polys on the render area considering they are not being rendered entirely...

And yes, method destroys shadow when found between two receivers... but isn't that supposed to happen anyway? shadows should not render where light doesn't reach: let the level lightmaps handle this, otherwise the shadow will render even on places where there is supposed to be a baked shadow.

How can I enable this anyway?


MikhailV(Posted 2009) [#4]
@Sake906: I shall try to add this option in new version (in ShadowsSimple.bb & ShadowsMultiple.bb files).


Sake906(Posted 2009) [#5]
I think that the best way to do it is to tell it which "receivers" are needed to "clip" the casters during rendering, so we can have other receivers out of that rendering process.

Anyways MikhailV, thank you for the consideration, I love the work done so far with this lib :)


Santiworld(Posted 2009) [#6]
hi, sorry for my ignorant contribution.

i buy this product, is amazing.. the problem with the shadows reciber is not a problem for my games, but anyway, i made this graphic to show my opinion about caster an emiter shadow concept...

i don't know how works this lib, but, maibe this is a contribution idea.
(sorry sorry for my english)



regards!..