Translucency Sorting With Quad Splitting #2993
Conversation
Would it make sense to pull this patch out of this pull request so we can backport it? I'm not sure what it is breaking exactly. |
|
It does break things that require sort triggering on unaligned normals but it's unlikely anyone would notice unless the geometry is particularly weird. It only becomes more noticeable with this patch because previously the partition tree wouldn't generate unaligned partition (i.e. triggering) planes, and unaligned trigger planes were only generated by the super rarely used dynamic topo sorting mode. I could split it out if you'd merge such a fix before 0.7, which is when I'd expect this to be ready for as a whole. |
|
Does this fix #2943? May be worth marking as such if so. |
douira
force-pushed
the
translucent-quad-splitting
branch
from
ec5a877 to
0939e4f
Compare
douira
force-pushed
the
translucent-quad-splitting
branch
from
a6e0d9e to
d1409cb
Compare
|
Does this also fix #2802? Images posted in the discord thread certainly appear to imply so. |
Not completely. This only splits geometry based on the information available in a per-chunk basis. There is no splitting that happens across chunk boundaries, so any over-sized model with translucent geometry will render incorrectly if it crosses into another chunk. Likely the problem will never be fixed, since it would complicate render code dramatically for what is arguably a broken model. |
douira
force-pushed
the
translucent-quad-splitting
branch
from
db29175 to
4cfb2d4
Compare
douira
force-pushed
the
translucent-quad-splitting
branch
from
4cfb2d4 to
c66b2b4
Compare
…ns instead of using instanceof Signed-off-by: douira <[email protected]>
…ome bugs around quad count handling and quad init
…update logic, fix split case logic to take on-plane vertices into account
… (degenerate quad) cases
… later would not be added to the triggering system even though they should have been, this was caused by a buggy equals implementation in AlignableNormal. remove AlignableNormal and replace with a Vector3f & int pair in NormalList and NormalPlanes, associated refactors to remove custom hashing strategy usage again,
…ree builder and the topo sorter
…o avoid getting into an inconsistent when later calculations yield different results because precision was lost along the way
…ncy sorting is disabled overall
…get updated repeatedly
…an on-plane vertex to
…wo nearly identical vertices
…sed by the bsp tree
…uish between index and mesh sizes. Revert ChunkMeshBufferBuilder to be mostly how it was before, without write methods and instead allow it to write to an external buffer. Modified quads are no longer repeatedly written during splitting and instead just written out once in their modified form. Clarified the difference between index and mesh quad counts throughout the translucency sorting code. Removed MixedDirectionData and SplitDirectionData as part of moving the translucency sorting before the meshing code so that meshes may be modified more easily.
also refactored the data removal methods into one because they have significant overlap, and they can also share the same clear call if both types of data are being removed at the same time
…ates (like around 16 million) by using full double precision in the calculation of the NormalPlanes's dot product offset
douira
force-pushed
the
translucent-quad-splitting
branch
from
67411df to
d8ca421
Compare
Fixes translucency sorting for geometry that is intersecting or otherwise unsortable by splitting quads in the partition-tree. Also fixes an old mistake in the sort triggering code in the form of a wrong
equalsimplementation onAlignableNormal.A 1.21.1 version of this patch is available at https://github.com/douira/sodium/tree/1.21.1/translucent-quad-splitting
Fixes #2943