a series of strange limitations

[buhatkj]

In working with irrlicht on a physics and special effects demo I have run into a few interesting limitations in the way some features or effects are provided by the Irrlicht engine.
I just wanted to put these out there, and see if maybe somebody had a better idea than I do why they are so.

1A-You can't add a shadow volume to a non-animated mesh node, and (1B) you can't apply normal mapping or parallax mapping to an animated node. This becomes a problem if you want to have a normal mapped object cast a shadow.

2-you can't apply normal or parallax mapping to the test nodes like Cube or Sphere. Since the normal or parallax mapping requires you to copy a mesh object to get one with tangents, and these have no mesh per se, you just can't do it. I would like to be able to set properties or apply effects to "the mesh contained or associated with *this node".

3-As far as I fan tell, Irrlicht 1.1 does not yet support POST shaders. this makes things like light blooms and motion blur perhaps a little more difficult. It is still possible I think to use render-to-texture, then apply your "post" effects to that texture and then paint it on a textured quad attached to the front of the camera, but this probably negates the speed advantage of using a shader for post processing.


anybody have a better idea than i do why these things are so?

[Electron]

It is still possible I think to use render-to-texture, then apply your "post" effects to that texture and then paint it on a textured quad attached to the front of the camera

Isn't that the way post-processing is usually done? Render a scene to texture (roughly the same speed as rendering to screen, afaik), then render a fullscreen quad w/ orthographic projection and apply the post-processing. Your fill cost doubles, since you're rendering twice, but it's called post processing for a reason. If it could be done on objects in the first pass, it wouldn't be post-processing. Could you explain what these POST shaders are?

[omaremad]

with a little thought we can jump over the limits.

Shadows only on animated meshes? well for the normal mesh make a child node that is animted, the child node doesnt have a mesh per say but uou set its shaddow mesh ( look it up in the api) so you have a vsible non anim node and a dummy anim node with the shadow mesh set as seen in the api.

Posprocessors are not special i made allot of postprocessor stuff for irrlicht and its easy, its all in the vertex shader: just use a test scennode for the quad and apply a postprocessor vertex shader.

If you are gonna use shaders read first then code, it will save you time in the long run.

[buhatkj]

yeh i think you guys are right that post shaders always do involve render-to-texture; more what I was trying to express was that at present I felt the interface could be a bit more simplified. hey whatever, I can see why that might be the way it is, but still what's up with the shadows?

Code: Select all

Shadows only on animated meshes? well for the normal mesh make a child node that is animted, the child node doesnt have a mesh per say but uou set its shaddow mesh ( look it up in the api) so you have a vsible non anim node and a dummy anim node with the shadow mesh set as seen in the api. 

I dunno, but that seems like a kludge to me. also, if i did as you suggest, what mesh would the child node extrude to make it's shadow volume? if i did give it the same mesh, but then made it invisible, shouldn't the child's shadow go away too? for that matter, even if it didn't, I still would not have self-shadowing on the original parent node.

hey maybe it's worth a try, but i really would not think what you describe would work.

[Electron]

If shadows are only possible on animated mesh's, sounds like a bug someone should fix rather than something that should be worked around. Fixing it in the engine source will prolly be less of a hassle in the long run then trying to deal with workarounds

[buhatkj]

yeh i would think that any node with 3d geometry should be able to cast a shadow, so a static mesh, an animated mesh, a cube, a sphere, an octtree should all be covered. it would be cool to have shadows for billboards or particle systems, but im not sure how well that would work or if it's possible.

[Mikenoworth]

I've looked at the shadow nodes code, it uses an IMesh, so limiting them to animated meshes, I believe, wasn't intentional. There is little extra work involved, but IMeshSceneNode should DEFINITELY support shadows.

As for other scene node types, I don't know how wise it would be. Oct tree nodes with shadows would be great, but they're ISceneNodes and that would require ISceneNode to have a mesh pointer, so every scene node type would have a pointer to a mesh, invalid or otherwise. But as far as that goes, every node having a mesh pointer isn't a bad idea. Or is it?

*dreams*

[buhatkj]

yeh i noticed that too mikenoworth, the CShdaowVolume casts it down to an IMesh anyway, so it's just prolly an accidental omission. I am trying to update it now.

[hybrid]

Right now some scene nodes even do not have mesh buffers, so IMeshs are definitely not standard. But the shadows only require some kind of triangles so there is really no need for larger structures, only the need to expose the triangle data and maybe some overloaded functions to add triangles to shadow.