Shadow Command
Blitz3D Forums/Blitz3D Programming/Shadow Command
| ||
| So, I was looking at another B3D like engine and they have built into their engine a shadow function that all you have to do is add the function to the object you want to cast a shadow...setshadow object,x,x. Why don't we have one for B3D? I ask this because B3D seems to be the fastest Indie style engine, yet we are behind in some tech respects. Is there a "set shadow to object" command system and I just don't know it yet? At any rate, I will remain using B3D for my project, but dang, shadows seem to be B3D's nemesis :) |
| ||
| True, I don't have sswifts shadow system but it's the most user friendly native solution there is. Details and links will be in his sig. |
| ||
| Yeah with Swiftys system you simply do these commands... set the mesh to cast the shadow like this: Cast_Shadow(meshname,Shadow_Resolution, False) set the light which will create the shadow like this: Cast_Light(lightname, LIGHT_RANGE) set the mesh to receive the shadow cast by a mesh: Receive_Shadow(meshname) You may have to fiddle with some settings depending upon the scale of your level, and you can't cast on to a surface which rotates. You don't need to cast an animated shadow either, a soft edge circle can be used (graphic included in the system). It also casts none static shadows for things which don't ever move in your level. A nice little extra with swifty's system is that you can have a highly complex animated mesh for your character but his shadow could be cast by a synchronised low resolution animated mesh, which means you get more fps for your hero character. btw, the shadow resoultion is a power of two setting for the amount of detail in the shadow, realistically no more than 512, but 256 is pretty good. IPete2. |
| ||
| Would it be possible for someone to post code showing a very basic example of swwifts system? In the meantime I will go into the Code Archs and see if I can find it. |
| ||
| I just did... :) IPete2 |
| ||
| lol, sorry, I missed your post, dang cache... thank you :) |
| ||
| argh! I can't find it in the Code Archs and the forum search result replies with 0. Anyone have sswifts shadow system available? |
| ||
| argh! I can't find it in the Code Archs and the forum search result replies with 0. Is it no longer for free, just to purchase? |
| ||
| Hey CodeOrc! Simply look for Swifty's posts in any thread - he has links in his signature. Oh actually you could check here: http://www.blitzbasic.com/toolbox/toolbox.php?tool=87 It is very cheap for none commercial use (i.e. sharware) or reasonably priced for commercial licenses. afaik it has never been free as such. And to save any heartache, read the notes at the very bottom, incase you want to cast onto Blitz terrains or plains or use animated MD2s... Have fun... IPete2. |
| ||
| ty much mate :) |
| ||
| hey Ipete, what you mean, 'cant cast shadow on to rotating surface'? Does that mean that if my character passing by rotating big gear (or something) in level, shadow will not cast over it?? |
| ||
| Naughty, When I was developing the ss Great Britain project, I needed to cast realtime shadows across the deck, Shawn told me it was not possible without some changes to the library which he wasn't planning on doing at that time. In the end I had to keep the ship and the camera fixed and move everything else, the world the sea everything. It worked really really well though and the result is awesome. There may be a way around it but I don't remember what it is (I think Shawn had a couple of ideas for me but it is a couple of years ago). IPete2. |
| ||
| Naughty: That is correct. I did that for speed reasons. It probably wouldn't be too hard for one to modify the system to support it again though. Basically the reason for the requirement as far as I can remember, is that accessing the vertcies with the regular Blitz functions was slow, and storing it in banks was faster. Or maybe I did that as a result of needing to in order to implement a much faster octree-based polygon culling system which I never got around to doing, which wuod have required objects to remain unrotated/scaled, and would have required the data to be stored in a special way in banks. For whatever reason I did it, the vertex data of the receivers is stored in banks. You would need to exchange each bank access with the appropriate vertex access command. But I just remembered another couple issues. First, in using the banks, I did not need to loop through an object's various surfaces when rendering the shadows. So you'd have to have a surface loop in addition to the vertex loop in the main rendering loop of the shadow system. Second, once you have taken these vertex values from the object's mesh that won't do you any good alone because they'd be untransformed... They wouldn't be scaled or rotated... Hm... Actually come to think of it, that changes things. Scratch all that. There is no reason to change the code that relies on the banks, because the vertex data returned is always going to be the same anyway. The only thing that needs to be done, which would result in a slowdown, would be transforming the vertex data according to how the receiver is transformed. There is also a bounding sphere calcualted for the receiver, and that radius value would have to be scaled according to the current scale of the receiver. It would be a little more complicated to allow the receiver to be scaled differently on each axis, but only if you cared if the bounding radius was optimal, rather than being a bit larger than it needed to be. But the transformations of the vertex data would be handled with the tform commands built into Blitz, so that wouldn't be too hard to implement. So that's why it is the way it is. Because I'd planned to have a better culling system, and that would have required static receivers, and transforming the points from receiver space to global space comes at a speed penalty. And if the receiver has a LOT of points, then that comes at a really big speed penalty. You'd definitely have to split your receivers into small objects so they could be culled. Right now you can sort of get away with not doing that. Of course I could probalby solve that speed issue by transforming the light plane into receiver space per receiver instead of the receiver into global space, but that'd probably be a huge pain to do. |
| ||
| .hhhmmm I see...so, does that mean that shadow will not cast over rotating geometry even if caster is standing on that rotating geometry and moving with it/let say my character jump on to big gear and standing on it while rotating together with it?/ ? |
| ||
| Yes, that's what it means. Whether he's hovering over it, or standing on it and moving with it, a shadow could not be cast onto the moving gear without modifying the system. |
| ||
| ..ehh... :( |
   |