MeshGroups. (Again)

[ArcturusEmrys]

This is an extension of #103 as the original author confirmed they are no longer interested in continuing their version of the PR.

Most of my additions are work-arounds for various error states caused by the output of Inochi Creator's exports. Specifically, if you do not add a mesh to a MeshGroup (which I do a lot), Inochi Creator will create incomplete mesh information for that MeshGroup. Inochi Session will ignore the information but Inox2D will complain and panic.

I'm not sure if this is 100% accurate, but it seems to work for what I'm doing so far. I may have to come back to this with more stringent tests.

[ArcturusEmrys]

So, for some reason it turns out most of me works with this PR, but not all. More notably, none of the maths stuff added by the MeshGroups PR appears to actually be used? I habitually apply all my deforms to MeshGroups, so I feel like I should be way more broken than I am without MeshGroup deforms actually applying to their children. Either that, or it's just the "dynamic" deforms that are unimplemented (which the magic circles in my eyes use, and which don't work) and the "static" ones just so happen to work by some other mechanism?

Either way, I'm marking this as draft until I figure out what's up with that. Probably will need to trawl the Inochi2D source as well...

[ArcturusEmrys]

I think I have a working implementation of dynamic deformation. (For context, the magic circles in my eyes used to float around aimlessly in space without dynamic deformation active.)

A couple things to note:

1. There's a literal edge case we're not handling yet: verts on the edge of a deforming triangle DO get treated as being in that triangle; the math code in this PR treats that as "undefined" according to its comments. I triggered this behavior by mistake making a test case for deforms and had to remove it, but I probably should actually support this.
2. Static deformation appears to require no runtime support; all the deforms are precalculated (which is why most of me worked just by parsing MeshGroup nodes). Of course, this is going away in 0.9 anyway soooo
3. I still need to add the aforementioned test case to Inox2D, which means I need to write a framework to load an INP and assert things about it

[mikz30]

A Part with Mesh doens't impose a deform but their transform on their chirldren how I understand it. Otherwise it would make any Part behave like a Meshgroup. It currently triggers

/// deform_stack.rs L100-117
if let Some(foreign_render_ctx) = node_comps.get::<TexturedMeshRenderCtx>(*source_node) {
								let foreign_offset = foreign_render_ctx.vert_offset as usize;
								let foreign_len = foreign_render_ctx.vert_len;

								let Some((my_deform, foreign_deform)) = split_ranges(
									result,
									vert_offset..(vert_offset + vert_len),
									foreign_offset..(foreign_offset + foreign_len),
								) else {
									eprintln!(
										"They're disjoint?! {:?}, {:?}, {:?}",
										vert_offset..(vert_offset + vert_len),
										foreign_offset..(foreign_offset + foreign_len),
										*source_node,
									);
									continue;
								};

								Some((my_deform, &*foreign_deform))

which often gives boundary checking error inside split_ranges because vert_offset is 0.

/// render.rs L231-234
if let Some(deform_stack) = comps.get::<DeformStack>(node.uuid) {
					let len = deform.len();
					deform_stack.combine(node.uuid, nodes, comps, &mut deform, 0, len);
				}

Would you mind sharing what kind of scenario this is supposed to handle?

[ArcturusEmrys]

So, a couple days ago, I was adding art to my model when I realized I'd made the mistake of applying a param deform directly to a Mesh. Inochi Creator doesn't have a way to convert a Mesh to a MeshGroup (that I know of) nor a way to copy the mesh data and deforms over to a new MeshGroup; so I'd have to re-rig all the art just to add a second layer to it. In desperation I just put the new art as a child Mesh of the original one and... it worked exactly as you'd expect a MeshGroup to act.

Granted, I haven't made a test case for this yet, it could just be a bug in Creator 0.8. I also don't know if it is applying static or dynamic deformation, if it's the former we technically don't need to account for it (and if so, that part of my model will probably break when 0.9 comes out).

[ArcturusEmrys]

After further testing with my deform test I don't actually think this behavior actually happens and I'll be removing the code to support it.

The thing I saw happening in Inochi Creator had nothing to do with deforms and I confused the two things. Sorry!

[ArcturusEmrys]

@Speykious @mikz30 Ugh. It turns out I've hit a bit of an architectural problem. MeshGroups not only deform mesh vertices, they also deform node translations. The natural place to put such code would be in DeformStack::combine, unfortunately we can't take &mut World inside of an ECS component.

In #116 I added a partitioning scheme specifically to allow multithreading param application, but it would also work in this case: you could partition the world into "just DeformStacks" and "everything else," then give the DeformStack you're combining the "everything else" partition. So I'm going to cherry-pick that part of #116 over, and hopefully the inevitable rebase will remove the duplicate commits later.

If you don't like this idea please tell me now.

[ArcturusEmrys]

...actually, to make matters worse, we're computing deforms AFTER the transform context is updated, which is too late to change transforms! Deforms have to be computed BEFORE the absolute transforms are calculated. So I have to move deform processing out of RenderCtx and into TransformCtx too.

This also has some performance implications: deforms will get computed twice (on my model they take several ms alone), and since deforms can influence physics now moving them over to GPU compute (something I wanted to do eventually) is going to be way more difficult, if not impossible.

(For context as to why it's difficult: moving work from the GPU to the CPU means the CPU has to wait, and GPUs aren't great at finishing things quickly. Ideally you only ever send work to the GPU. So I'd either have to move all the physics to the GPU, which is overkill, or download the deforms back to the CPU and hope the performance hit is less.)

[ArcturusEmrys]

I have the MeshGroup "translate children" behavior ostensibly implemented, but it doesn't actually work because all the MeshGroups in my face that have it enabled in the .INX get exported with it disabled in the .INP. It just happens to magically work in Session.

I don't know what the hell is even going on anymore 🤪 All I know is that I have magic circles in my eyes that deform correctly, until they rotate, and then moving my head left or right makes them fly wildly off course. It's like their center of rotation doesn't move along with the mesh, which is why I looked at the translation children behavior - but it CAN'T be translate children, because Inochi2D turns that off on export.