The problem with collision: node animators

[Rv]

Irrlicht has some odd design in the way it handles collision response and node animation. Here's why:

Taking the collision response animator as an example, these are attached to a node, say a camera node, in order to resolve any collision issues that have occured. The problem here is that it's all done inside the render -

Step1: Pre-render - cull and submit for rendering
Step2: Render - draw what's needed
Step3: Post-render - resolve collisions

See the problem? If we have moved our camera into an area it should not be, it is rendered in this position _before_ the collision is dealt with! Result: seeing through walls.

In my opinion, the Post-render step should be renamed to "Update" or "Animate" and removed from the render-flow entirely (it's not, after all, anything to do with rendering) or at the very least, moved to be the first step.

Hope this helps

[vitek]

Removing or renaming OnPostRender() is not a good idea simply because it would break source compatibility with previous versions. In the very least that requires every user to edit their code and recompile so that it would work with the new library. Another issue is that OnPostRender() is used for other things besides resolving collisions. It is used in many places to move the scene node or do things that require the current time.

The root of the problem is that the collision response is done as an ISceneNodeAnimator and those are processed after the render. One solution would be to process scene node animators and update the node absolute position before the render, possibly in OnPreRender(). This has been suggested by others several times to resolve this and other issues. It would probably work, but I'd be willing to bet that there is something that would break.

[Rv]

Removing or renaming OnPostRender() is not a good idea simply because it would break source compatibility with previous versions. In the very least that requires every user to edit their code and recompile so that it would work with the new library.

You are right of course. My suggestion was really just a quick fix for the collision issue.

Another issue is that OnPostRender() is used for other things besides resolving collisions. It is used in many places to move the scene node or do things that require the current time.

Admitedly I have not looked too deeply into the other things that are done in PostRender, but I doubt they would suffer being moved to before the render. The PostRender in this engine seems to be where the "update" is done, which is the wrong place for it all really.

The root of the problem is that the collision response is done as an ISceneNodeAnimator and those are processed after the render. One solution would be to process scene node animators and update the node absolute position before the render, possibly in OnPreRender(). This has been suggested by others several times to resolve this and other issues. It would probably work, but I'd be willing to bet that there is something that would break.

Possibly. Though to be honest, I'd move the lot of out the render and into an "update" where it belongs. Game engines typically manage each frame in this order:

1) Update AI/Player
2) Update movement/collision/anims/whatever
3) Render scene

But I'm merely pointing this out. How you deal with it is up to you

[choujs]

I think what you say is right but OnPostRender() of irrlicht is also a good ideal because it hidden many detail of scene updating from application.If we use the 'Update' you have said, application must deal with much more update operator, include those can be done automatic without intersection of user. So, to overcome the problem RV have said, a method is to define a new subclass of ISenceNode in which you can write your own OnPostRender() method. I think this way should be enough since in a scene the nodes you should manual control are not so many.

[vitek]

I agree that the position updating should not be part of the rendering process. You should be allowed to render the scene as many times as necessary without having any effect on the scene nodes.

Imagine that you are rendering the scene to several off screen buffers [shadow mapping or other post processing effects], you need to render the scene several times. When updating positions is connected directly to the render, you are update thing object positions [and possibly other things] several times for every main viewport render.

Unfortunately making such a change would probably cause some serious compatibility issues.

Travis