![[de]](/mwf/flags/de.png "Germany")
Or: "How could our tree model have been broken for all past releases without anyone noticing?"The tree material uses the "depth-write off" flag to ensure that the leaves in the back don't get culled by the transparent parts of the leaves in the front. However, there is no fixed order in which those are rendered to the screen, so now the opaque parts of the leaves in the back occlude the leaves in the front! the only reason nobody noticed is that the texture was so uniform that you wouldn't see it. have a look:
The new trees have the same problem, of course.
Ogre DOES have the Alpha-Reject-Field for materials which indicates after which alpha value a pixel won't be considered for occlusion, with that field AND depth-write enabled we should be able to fix it well enough for these "cutout" faces. However, the engine does not support the field yet. There might also arise a situation where semi-transparent faces become a problem.
Attachment: trees.PNG - nooo (367k)
![[us]](/mwf/flags/us.png "United States")
> However, there is no fixed order in which those are rendered to the screen, so now the opaque parts of the leaves in the back occlude the leaves in the front!
For materials with "scene_blend alpha_blend" (like the tree), the engine orders triangles by their Z position (back to front). This should in principle take care of this issue as well as semi-transparent triangles. The only issue is, how do you define the Z position of a triangle? At the moment, the engine takes the vertex with the maximum Z value, i.e. the one that is closest to the screen. This might not be ideal... at the time I did it this way because it got the rendering of the balloon correct (as opposed to e.g. taking the average Z of the three vertices). But maybe it is possible to improve the situation by modifying the model with this in mind, or splitting up the triangles that represent the leaves some more. If someone has better suggestions I'm all ears. A while ago I researched a bit about order-independent transparency, but I'm not sure how feasible it is with the hardware we are aiming at... maybe worth a try, though.
> Ogre DOES have the Alpha-Reject-Field for materials which indicates after which alpha value a pixel won't be considered for occlusion,
This is a simple alpha test -- if the alpha value is too low the pixel is not rendered at all, not only not considered for occlusion (i.e. depthwrite off). What you have in mind is more some sort of alpha-dependent depth-write, no? This might be possible with a custom shader for the tree: just write a very low value to
gl_FragDepth if the alpha value of the pixel is below the threshold.
> But maybe it is possible to improve the situation by modifying the model with this in mind
I actually thought about that and had begun sorting the faces internally in blender, but then I realised that this couldn't work, because the tree might be rotated 180 degrees.
> or splitting up the triangles that represent the leaves some more.
thats another possibility, but it's more a workaround. More complex models (that tree is actually a good example) might have to be splitted many times to ensure each overlap works correctly.
> Ogre DOES have the Alpha-Reject-Field for materials which indicates after which alpha value a pixel won't be considered for occlusion, with that field AND depth-write enabled we should be able to fix it well enough for these "cutout" faces. However, the engine does not support the field yet.
I just implemented this. If you can make the tree appear nicer using it, go ahead! :)
That was quick, many thanks! And it works nicely for this:
Attachment: trees_fixed.PNG - yay (513k)
Wow, the colours on that image look so much more vibrant compared to f.e. this old blog-post image here. I like it.
The base texture is actually not my work. The vibrant colors already were there. But I added in the self-shadowing of the leaves, thats how I found the wrong behaviour in the first place. I just wanted to see how clonkonauts lighting experiments looked with the existing tree and made the modifications ;)
So how did you do it? I guess we can commit the tree improvement right away, no matter what we do with the lighting.
I simply used your new option in the material and disabled the alpha blending. I can push this evening, but I noticed that the texture in objects.c4d and the texture in the ressource repos differ, even the UVs are arranged differently. It would be nice to have this cleared up, but I can't see the history of the graphics past the recent revert for some reason.
Powered by mwForum 2.29.7 © 1999-2015 Markus Wichitill
