Open John-Nagle opened 3 years ago
Here's some more info and screenshots.
These define the problem a bit better. "blendfirestorm1" shows what the image is supposed to look like, rendered by the Firestorm Second Life viewer. The ashtray has been selected. Note that the ashtray has two triangles on the floor. Those have a baked shadow on translucent triangles. "blendfirestorm2" shows the same scene, with the glass counter, also with a baked shadow, selected. In both cases, the baked shadows are very close to floor level.
Now compare the Rend3 rendering. There are two big holes in the floor where those translucent shadows were supposed to be. It looks like that the system for resolving whether the floor or the shadow image is on top chose "neither", leaving a hole through which the grass ground plane is visible.
The other cases I've see are also the very close to equal depth case. So that's a good hint as to where to look for trouble.
I'm still seeing this. Looking through two translucent surfaces produces inconsistent results. Sometimes OK. Sometimes too opaque. Not sure why yet.
Here's a new piece of info. At least for translucent objects, there is no backface culling. This translucent sign has readable text on both sides. In the Second Life viewer, you don't see the back side of the other side of the sign, but with Rend3, you do.
Second Life Firestorm viewer, backface culling.
Rend3, no backface culling.
With no backface culling, some translucent materials go almost opaque.
An extreme example of the wrong face being in front:
Looking through two sets of windows, the most distant one is in front.
After moving the camera through the window wall, the distant windows are correct. But looking through two sets of translucent windows sorts wrong.
Alright, the backface culling issue has been solved with caceab26b206fc687114850c7b9636b0f6dcb336. The sort issue is really interesting. Are the windows part of the same object, or are they different objects?
This no longer seems to be a bug. Not sure when it got fixed, but I am not seeing it any more.
I think I finally figured out what's going on with translucency depth sorting.
This is the Firestorm viewer rendering (left) and Rend3 (right) rendering the same scene. The translucent windows are curved, single face, backface culled, and blended. Note the depth sort problem with Rend3,
How does Firestorm get this right when the viewpoint is looking through the same surface twice, once from the front and once from the back? I think it does it by doing the depth sort after doing backface culling. Here's the geometry of the situation:
The two big semicircles are the outside and inside of the window. The black areas of those are seen from the front, and would be rendered. The grey areas are back-faces and will be culled. The red and green dots are the "centers" (average of the vertices or some such metric) of the un-culled triangles of each object.
If you first cull the back faces, then use only the remaining vertices to determine depth for the depth sort, translucent objects which wrap around other objects work out better, because invisible back sides no longer affect the depth sort.
This is not high priority but explains a nagging problem. If it can be fixed at low cost, it's worth fixing at some point.
As the point of view changes, textures are replaced, and many change_material requests are made, sometimes objects disappear. This may be associated with thin stacks of faces. See the attached pictures. In alpha mask mode, the window, posters, and backing board are all in the correct order. With blend mode, sometimes some of the posters and the backing board disappear. This is with the same code except for a change to the transparency mode.