@zzuegg said:
afaik http://www.opengl.org/registry/specs/EXT/shader_image_load_store.txt should do it
This is an interesting read. I only made it halfway through and the architecture necessary for synchronization is almost as complicated as I thought it would be to still allow proper pipelining. Though if I’m reading it properly, to do your own z-buffer implementation will nearly destroy pipelining performance as a stricter order is required, memory barriers, etc. and these by side-effect cause some other optimizations not to be used.
The nice thing about a z-buffer is that the fragment shader isn’t needed. It can be done right in the rasterizer deep in the GPU and doesn’t affect pipelining of fragments the same way.
@viewedclearly said:
Okay Paul. I guess it's enough to know what's happening, if not exactly why. I've already re-coded for the things you've taught me here, the gaps are gone. The self shading issues, I can work around now that I understand them.
You’ve been a terrific help, I feel like my eyes have been opened. And you’ve made a friend today.
I don’ t know if you are using the default bounding shapes or not but if you are then that could contribute to things being drawn not in the order you might expect.
For example, in this picture:
If the bounding boxes are based on the actual mesh, then I could imagine the bounding box situation looking something like:
In this case, if you are above it looking down then it’s possible that the nearest corner of the red bounding box is closer than the nearest corner of the yellow or green bounding boxes and so it sorts in front. This would cause the transparency issue since it would be drawn last instead of first.
For what it’s worth, the calculation of the bounding shape is non-trivial and if your world is tiled then you might choose to override that with a constant sized box the size of the whole tile. It kind of depends on how your world is tiled, though, and how your players will use it. For flying around with tiles really tall, it means you render a lot of the ground that’s not seen. For walking around on the ground you still end up not culling some things that should be but it has less of an impact.
In my engine the world is divided both vertically and horizontally so I take the hit.
<cite>@pspeed said:</cite>
Are you talking about something that a user could implement or something that graphics cards would have to implement? It would be interesting to see the graphics architecture that lets you read and write to the same buffer in the same pass. The Z-buffer is kind of a special thing.
Honestly, I don’t know enough about low level graphics card architecture to say. Something might be possible using methods like the one @zzeugg mentions but as you say its tricky.
How does the z buffer handle contention at the moment?
@zarch said:
Honestly, I don't know enough about low level graphics card architecture to say. Something might be possible using methods like the one @zzeugg mentions but as you say its tricky.
How does the z buffer handle contention at the moment?
Don’t know exactly… but it’s part of the rasterizer and not part of fragment rendering. I’ve always been curious how “discard” was made to work efficiently.
Your bounding box explanation of the gaps seems right on. The problem only occurred near the hills and not on the flatland.
the calculation of the bounding shape is non-trivial
I can see how to set a custom bounding box. But is there a way to get the JME not to perform the calculation to begin with, so I can save it the trouble?
@viewedclearly said:
Your bounding box explanation of the gaps seems right on. The problem only occurred near the hills and not on the flatland.
I can see how to set a custom bounding box. But is there a way to get the JME not to perform the calculation to begin with, so I can save it the trouble?
To do it, I had to extend Mesh and override updateBound() and getBound().
