As seen in #1515, the way Chunky handles intersections in between materials is sometimes inconsistent. Additionally there are other quirks noticed between different blocks models, ie glass panes do not intersect on the transparent part because of how QuadModel handles alpha. However how we intersect something like glass should be different from something like flowers and could be adjustable. Additionally a user might be inclined to enable or disable back faces for some block models. As such, the way that intersection logic works should at least partly dependent on a blocks Material properties. The advantage of having exposed materials properties is that on some materials we can have simplified logic allowing for faster marching though the oct tree, while other materials would have more careful intersection parameters. Addionally, this can be made forward compatible with existing scenes.
Here is some intersection logic considerations:
Are we looking at the front or back face
1.1 Are we inside a block? (might be diff from 1 )
If looking at a FRONT face
do we want to intersect on change of material (ie glass air)
do we want to intersect on 0 alpha (glass)
do we want to intersect on geometry
Looking at a BACK face
do we want to intersect on change of material (ie glass air)
do we want to intersect on 0 alpha (glass)
do we want to intersect on geometry
do we want to intersect if inside a block
Finally: Heres what we want to do on an intersection:
pass though the ray, dont do anything (want to minimize these cases)
update ray direction, dont update cumulative color (ie to fix refractions without rendering back side) (dono if this would just cause artifacts
treat as a full surface
Im not sure if there are more relevant cases but that's the stuff I came up with
For example with glass allowing intersections on blackfaces only on material boundaries would probably fix #1515 without being as hacky as #1601
As seen in #1515, the way Chunky handles intersections in between materials is sometimes inconsistent. Additionally there are other quirks noticed between different blocks models, ie glass panes do not intersect on the transparent part because of how
QuadModelhandles alpha. However how we intersect something like glass should be different from something like flowers and could be adjustable. Additionally a user might be inclined to enable or disable back faces for some block models. As such, the way that intersection logic works should at least partly dependent on a blocks Material properties. The advantage of having exposed materials properties is that on some materials we can have simplified logic allowing for faster marching though the oct tree, while other materials would have more careful intersection parameters. Addionally, this can be made forward compatible with existing scenes.Here is some intersection logic considerations: Are we looking at the front or back face 1.1 Are we inside a block? (might be diff from 1 ) If looking at a FRONT face do we want to intersect on change of material (ie glass air) do we want to intersect on 0 alpha (glass) do we want to intersect on geometry
Looking at a BACK face do we want to intersect on change of material (ie glass air) do we want to intersect on 0 alpha (glass) do we want to intersect on geometry do we want to intersect if inside a block
Finally: Heres what we want to do on an intersection: pass though the ray, dont do anything (want to minimize these cases) update ray direction, dont update cumulative color (ie to fix refractions without rendering back side) (dono if this would just cause artifacts treat as a full surface Im not sure if there are more relevant cases but that's the stuff I came up with
For example with glass allowing intersections on blackfaces only on material boundaries would probably fix #1515 without being as hacky as #1601