Crack stitching

[Eideren]

Crack Stitching

Introduces a toggle to the model inspector UI which, once toggled on, fixes cracks appearing through generated geometry. It does so asynchronously to prevent interrupting the user while he's working.

See discussion on discord for further information.

Inspector

Result

Here's a more advanced implementation of the debugger interface if someone wants to debug this in the future: StitchingDebugger.zip Don't forget to comment out #define YIELD_SUBSTEPS above CracksStitching.cs

[nukeandbeans]

If I am not mistaken, these would technically be called "T-Junctions", if they are vertices along an edge like -|. If this is the case, then changing the title and label would be great.

Also just a minor nitpick: an image comparison with wireframe on would help a bit with making it more apparent exactly what is being done.

Thanks for this! I'm sure a few people would find this very useful (and it would probably fix some PostFX issues, like bloom, for some projects).

[Eideren]

This issue doesn't appear only around t-junctions, see this case where multiple white pixels peek through two edges that should be touching:

It's not caused by the rasterization process either as getting closer does show a multi-pixel wide crack.

an image comparison with wireframe on would help a bit with making it more apparent exactly what is being done.

Sure, edited the post to add one in.

Also, the logs for how long auto lightmap gen and stitching took are a bit too spam-y, could we do something about that ? Maybe log a warning for auto lightmap gen if it takes a significant amount of time since that's a blocking operation and users might become frustrated waiting for editor response when moving things around. Stitching isn't really blocking so not sure there even is a need to log it ?

[Eideren]

Regarding my last complaint about duration logging, I replaced debug logging by unity's progress API.

[Gawidev]

Currently in a very good spot, this feature is really amazing and RCSG will benefit greatly from it. Only small issue discovered when playing around with it is relating to surfaces set to non-visible, they currently seem to get in the way of the crack detection doing its job properly, sometimes filling them up in a broken manner.

[Eideren]

I'm still looking into @Gawidev's issue, I have a fix - just have to iron out a couple of bugs and with the holidays and all I don't have a lot of time to go through it.

[Eideren]

There we go, this commit should fix those issues. PR ready for further review/merge.

[Gawidev]

Hey sorry resident "I-break-stuff" worker here, a bit of extra testing done and I've run into a similar issue where hidden faces are being treated strangely by the crack detection, this case particularly when there are hidden faces with different shadow-receiving and shadow-casting settings.

Should be reproducible by creating a box brush, then setting one surface to non-visible, and another one to non-visible + non-shadow-casting.

They seem to get merged into the same generated render mesh, which shouldn't be the case, iirc there should be up to 5 possible generated render meshes for the same material. (vis/receiver/caster, vis/receiver, vis/caster, vis only, invis/caster) (This is cause rcsg assumes hidden faces should only be taken into consideration if they cast shadows)

[nukeandbeans]

Any updates? Would love to get around to merging this.

[Eideren]

I should have some time to take a look at this again this week end, I'll keep you posted