add the option to use a placeholder mesh in the WallMeshShaper

[GGAlanSmithee]

fixes #15 by adding the option to set a placeholder mesh, which can be toggled to be used while editing to greatly improve the performance and developer experience.

I also took the opportunity to address the point raised in #8 by copy-pasting (with formating) the information you provided in that issue (which I followed for great results btw).

See #15 for context

OBS! the image for the MeshWallShaper editor block needs to be updated in the README.md, but it requires you to upload a new image to github

• closes #8
• closes #15

https://github.com/user-attachments/assets/5c3aeb30-914f-4031-9551-d11246e80791

[GGAlanSmithee]

the attached video is a poor showcase for the usefulness of the proposed change. See https://github.com/daleblackwood/goshapes/issues/15#issuecomment-2308165227 for a more realistic usecase.

[GGAlanSmithee]

I added a top menu option to toggle on/off all placeholder meshes, which makes it easy to

1. toggle on all placeholder meshes
2. edit your scene
3. toggle off all placeholder meshes

https://github.com/user-attachments/assets/a81700eb-10fd-47ec-9b38-8a667307cc0d

[daleblackwood]

Thanks for the contribution!

While I don't mind this idea in principal, it's glossing over some bigger problems that I'd like to resolve first. I've got an is_async flag in the Job.gd file, I've flipped it on by default in 1.2 onwards, I'd be keen to know how that performs in your testing.

With that flag set to true, it should be non-blocking, and render the curve in realtime, then the cap, then the walls, giving a clearer picture progressively without bricking performance or requiring a substitute mesh.

I'm also planning on refactoring the mesh wall building to prevent it from copying and combining too frequently which should help.

[GGAlanSmithee]

@daleblackwood I agree 100% that this is not a proper solution, but only a work-around. I have been using the v1.2 branch, does that include the change you are referring to, or is there a commit or branch I can test with to see how it affects the performance?

[GGAlanSmithee]

I see it @https://github.com/daleblackwood/goshapes/commit/3ddbc7819bb796a5119358f97cefb2f00f12b9a8 exciting! Will test it when I get some time after work.

[GGAlanSmithee]

@daleblackwood I have been trying out the v1.2.1 branch, and I cannot see any significant performance improvement from my initial tests (all thought, I think the actual shape of the wall is better for rounded paths).

Some things I've noticed:

1. The time it takes to build a WallMeshShaper is directly related to the length / number of segments of the shape, and by extension, the number of vertices which makes perfect sense.
2. I does not seem like the number of points along the curve has any significant impact on the build time, even though a more complex (curvy) path, probably takes a little bit longer, but it's barely noticable from what I can tell

Here is an interesting screenshot. In the back row, I have static meshes, and each ten is raised higher than the others, for visibility. A you can see, the front row is of equal length of 10 meshes, but it is made up of 19 segments (see log output - I put a print statement in the MeshUtils.mesh_clone_to_length function:

[GGAlanSmithee]

Ok, yeah the way the algorithm works, it needs that segments count otherwise it gets stretched (and it does not handle shard corners as well, even though it's not that bad tbh)

[GGAlanSmithee]

It's probably just in the nature of this operation that it's costly, I imagine that, in order to be able to optimize it with more complex meshes, you would need some really smart stitching logic that only considers edge verticies with special handling of corners / bends, but that will become tricky quickly.