TransparentNodeList.sort issue related to reflective planes

[robmar]

Reflective surface/water nodes with a transparent wave mesh suffer a problem when transparent nodes are placed above their surface.

This occurs because in drawAll a sort is used to render the furthest away transparent objects first, based on camera distance.

The problem is that the water surfaces are very large meshes, and the distance to the camera is calculated from the mesh's centre, which may, or may not, be further away from the transparent node above its surface, depending on the position of the transparent node along the water surface and angle of camera look down the water surface (its quite easy to understand the problem if you draw a little diagram).

The sort could be modified to find any reflective water surface and always render that first, but its a bit of a hack, and would need a control flag as it might not fit all scene layouts.

Does anyone have a good fix to this problem?

[hendu]

Take direct control of your water node. Remove it from the drawAll by grab(); setParent(NULL); and draw it manually in the place you need.

[robmar]

I've just modified drawAll to find and render the transparent water surface first, then render the remaining transparent objects, and that's solved the issue.

Of course there is a slight overhead on drawing now, but I guess its not going to impact framerate, not even with 100 transparent objects, so its okay,

Just wondered if anyone else had had this issue, and had a neater solution.

[lumirion]

I'm thinking up a solution that generates a list of nodes to render uses a quick sort once when the list is generated. It detects nearly planer nodes by finding the thinest dimension of a node's aabbox and measures against the longest. If the shortest dimension is less than probably about 1/5 the longest then it might be close enough to a plane to pretend.
-Next the comparison for sorting uses a normalized copy of the cameras look vector and the far coordinate of the nodes bounding box to make a plane. Any nodes with bounding boxes farther than the plane are get rendered first.
- If a node is not farther than the plane we make a seconnd plane from the same box's near corner and see if the other node is nearer than the new plane.

- if the other node is not completely further or nearer and the current node is plane like get its shortest dimension and normalize it. Now use aabbox center to make a plane. If the other node is on the same side of the our first node as the camera our first(planar) node is farther.
-if the 2 node's boxes don't intersect they are paralel.
-if they do intersect we can use our node's near plane and the second node's box near coordinate. If the coordinate is nearer our node is probly farther.
-2 planes can be compared directly to each other using clasfyplane relation.

Save last position for each node in the list. Now that it exists we use insertion sort to move nodes postion in the listthat have moved in the scene.

Use pointers in the list to refer to actual nodes.

[robmar]

The current system just takes the centre of objects to calculate distance, which is why it doesn´t always work correctly depending on sizes and positions of the objects.

So calculating using planes makes sense. In my case, the sea surface was large, and although my object was above the sea, it was in some cases further away than the other objects centre point, so transparency render priority was wrong.

To calculate this correctly requires using the camera position to determine if one object is "above" the other.

I imagine your technique would handle this, so it would be a useful improvement to Irrlicht IMO.