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
2 times, most recently
from
67411df to
d8ca421
Compare
douira
force-pushed
the
translucent-quad-splitting
branch
from
d8ca421 to
1044cdb
Compare
douira
force-pushed
the
translucent-quad-splitting
branch
from
a34bac3 to
c84be9c
Compare
|
This is ready for review and merging. No open in-scope issues found during testing remain. Note that the bug fix PR #3033 is included in this for testing reasons and once it gets merged into upstream I'll drop it from this. |
douira
force-pushed
the
translucent-quad-splitting
branch
from
5343d79 to
0d11b5f
Compare
douira
force-pushed
the
translucent-quad-splitting
branch
from
0d11b5f to
959498e
Compare
…ns instead of using instanceof Signed-off-by: douira <douira100@gmail.com>
…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.
…ion by zero assertion to fail
… a shared splitting group
…perfect triggering at the cost of many more normal planes being used.
douira
force-pushed
the
translucent-quad-splitting
branch
from
959498e to
067b8e4
Compare
TQuadconstruction to happen mostly in its own classA 1.21.1 version of this patch is available at https://github.com/douira/sodium/tree/1.21.1/translucent-quad-splitting (currently outdated)
Fixes #2943