Global Z-,Draw-,Render-Order Window

[JoelMayer]

Okay, this is going to be a longer proposal.

I think one of the biggest painpoints in Moho is having characters interacting with their environment. Or to put it more simple: putting things behind or in front of other things.

Usually that means creating a lot of reference layers and getting confused about which one is turned on or off, having stuff break because the patch layer you use doesn't show up in the reference because you had to hide another body part, re-linking layers breaking things etc. etc.

@arglborps did an excellent video recently that highlights the problems that happen in complex scenes: https://www.youtube.com/watch?v=pH5QtSL1nqw

Now, my experience is limited to Harmony so i can only say how it is working there: you want an arm going behind another character? Alt/Opt + Up arrow. Done. You basically nudge things in the Z axis of a 3D space but cutters (masks) and everything stay intact. This can still lead to problems sometimes but it definitely goes much faster than how it works in Moho.

Now, i think an even BETTER solution would be to do it like most game engines: have a global Z-Index for every layer that doesn't really nudge anything in Z-Space but simply renders the layers in a different order. This tag is completely independent from the actual layers an object is on.

Example in Construct 3, an HTML5 game editor:



Documentation: https://www.construct.net/en/make-games ... -order-bar

Now in principle it's the same thing in Unity, Godot or any other engine, i'm just using Construct as an example here because it's the most visual. The Z-Order Bar is NOT the same as their layer view.

If we had this in Moho and could basically just animate the Z-Order of every single layer and have it keyed, we didn't need anymore references or moving actual layers or anything. All would stay within one rig and make for so much less headaches, a cleaner layer and timeline view, etc.

I think Rive does this basically as well, so here's an example of how an animation software is handling this concept:

https://help.rive.app/editor/animate-mo ... draw-order

They call it "Draw Order". So nothing's really moved, you just tell the renderer to render stuff in a different order so things appear on top or on the bottom but do this on a GLOBAL scale so you can put elements behind other rigs or layers in a scene at will at any point.

I think this would be something to seriously consider and it would make animating in Moho so much more enjoyable and fast even with complex scenes.

Thanks!

[Daxel]

I would also love to see this in Moho. Basically, an alternative way of layer ordering that is just visual and doesn't break or interfere with the existing hierarchy or the grouping, bone layers etc. It could be called compositor.

At the same time I think Moho has some tech debt already so I would love to see improvements and bugfixes to the things we have first. In this particular case references need a lot of attention to be better at this and other tasks.

If references didn't get corrupted we wouldn't have 80% of the post that complain about performance problems and I wouldn't have to remake references constantly to fix them.

If reference updating was complete we wouldn't have to remake references each time we change something in the original that is not supported by reference updating.

And I would still like to have a compositor of course, but I wouldn't need it so bad.

[JoelMayer]

Yea fix the existing stuff first goes without saying Also the brush stuff just has to be rock solid without any strange AA artifacts. And yea if Reference Layers were improved upon it would already be a great first step.

[Panha]

I wish to see that kind of dynamic of ordering in the future of Moho. It would make life easier, and bring the software to the next level.

[hayasidist]

Example in Construct 3, an HTML5 game editor:...
Documentation: https://www.construct.net/en/make-games ... -order-bar

I think Rive does this basically as well, so here's an example of how an animation software is handling this concept:
https://rive.app/community/doc/animatin ... cFeifDob4o [link updated to more recent version]

I'm broadly in favour of the idea.

But there are a few things that, IMO, need to be considered.

The z-order-bar in Construct 3 appears to work on "whole groups" (and if I'm wrong, please correct me); but if this is the case, then Moho already has Animated Layer order - and that provides the visual effect of this z-order ("z" as in render order rather than z as in distance form camera) both in viewport and render. And the same appears to be true in Rive.

My opinion: in this simple scenario, where all that's wanted is whole groups changing order, within the document or within their parent, Moho already has it nailed.

------

Now moving on to the situation where we have two (or more) groups that each have sub-groups, and the requirement is to present these subgroups in a visual order which is not the order in which they are stacked in their parent group.

I can readily see how valuable such a render-order could be when considering just two simple groups, e.g.:

Character [A/B]
> arm 1
> arm 2
> body

giving the user freedom to render in an order such as
A: arm1
B: arm2
A: body
B: body
etc

Obviously, this would need to be an animated order.

My view is that this could be done as long as the subgroups are wholly "self contained" (i.e. they neither rely on nor have a dependent group that relies on their rendered content) [e.g. masking or blending]. That, IMO, certainly applies within their (moho) parent group; and places some interesting opportunities when considering how masking etc might need to defined (or prohibited?) in the render-order "supergroup".

And I'm now wondering if there is an efficient mechanism to make a "render group" (that can make use of Moho's animated layer order) by doing a "copy by ref to include parent transforms" of layer sub-groups.
IOW, in the above thought-experiment A:arm1 is not just the arm layer and its layer-level animation, but it has the (bone etc) animation from its parent applied. >>> THIS IS NOT how copy-by-ref currently works, but IF such a "copy-by-ref++" could be implemented in a performant manner, IMO this will offer a path to achieve dynamic render-order using otherwise existing Moho functionality.

Comments???

[Daxel]

Comments???

I'm not sure I understood the last part.

I think your example is what we usually do with references. If we have a scene with Tom and Jerry interacting, we may have, for example, from top to bottom: Tom 2, Jerry 2, Tom, Jerry. Where Tom and Jerry are the original rigs, they are at the bottom and have all their layers and shapes visible. Then, the parts of them that we need to put on top are the references, where Jerry 2 (ref) may only have one arm visible, and Tom 2 (ref) may only have one leg visible and a ball. Usually layer visibility is enough to achieve the composition we need, but sometimes we need to also make a shape invisible while keeping the other shapes we have in that layer visible. In that case, we use alpha to make only that specific shape invisible. Saved styles don't let you animate from that colour to invisible without affecting all the other shapes that use that saved style, which is why we avoid using saved styles.

Because References have those two problems (corruption and incomplete updating), we use actions (sometimes smart actions) that contain the modifications each reference need, like "Tom leg and ball ref" so we have this changes "documented" and ready to be applied quickly each time we need to remake the references to update or fix them.

We can use after effects for composition and we usually do, but we like to see how things look like while we are animating in Moho, specially if we don't have a very detailed and well timed animatic or if we are introducing or testing changes to the animatic in a flexible way, something we usually only do when using Moho and rigging animation because of how easy it is to animate with it.


So ideally, the compositor would be able to order all the elements of the scene, the elements being any kind of layer, including groups, mantaining all their effects like they were originally grouped. And yeah, ideally this order could be animated. That would allow us to not use the references for composition when we need to make layers or groups invisible, however we would still use references when we need to make a shape invisible, which seems like too much for this compositor to handle, I'm guessing. So yeah, at the end we really need better references for composition anyway.

[JoelMayer]

For me it's really very simple:

Render-Order: Tell Moho/Computer which layers to render first and last including all the things that affect the look of said layer (i.e. patches, masks). It's just render thing and has nothing to do with any sort of hierarchy whatsoever.

This order is animatable.

In it's simplest form it's simply a large list of every layer available in the scene (perhaps even similiar to the Action window) that you can draw things around. Maybe there's some indication as to which parent group a layer belongs to just to make things clearer. But the minimal viable product would simply be a list of all layers that i can drag stuff around in on a global level and that doesn't influence the hierarchy or rigging of anything but simply tells Moho when rendering what's being rendered in what order.

The tricky part would be probably to make sure stuff like patches stay intact (hassle with reference layers atm as well if the part that the patch is applied to is hidden).

[hayasidist]

For me it's really very simple:

Render-Order: Tell Moho/Computer which layers to render first and last including all the things that affect the look of said layer (i.e. patches, masks). It's just render thing and has nothing to do with any sort of hierarchy whatsoever.

This order is animatable.

In it's simplest form it's simply a large list of every layer available in the scene (perhaps even similiar to the Action window) that you can draw things around. Maybe there's some indication as to which parent group a layer belongs to just to make things clearer. But the minimal viable product would simply be a list of all layers that i can drag stuff around in on a global level and that doesn't influence the hierarchy or rigging of anything but simply tells Moho when rendering what's being rendered in what order.

The tricky part would be probably to make sure stuff like patches stay intact (hassle with reference layers atm as well if the part that the patch is applied to is hidden).

not just patches, but masking and blend mode where the essential render order is implicit in the layer hierarchy and the effect can be destroyed by rendering layers in the wrong order? IMO simply to present a list of _all_ the layers in a doc and allow them to be rendered in an arbitrary order is to overlook render-time (hierarchical / sequential) dependencies. Sure, can be fixed by forcing groupings such that groups _can_ be independently rendered.. which is more or less where I was headed with the copy-by-ref++; and then the list of (independently renderable) render groups can be held in a structure that allows them to be dynamically re-ordered... (i.e. a group layer with animatable layer order.) IOW exploit the Moho functionality that we have and enhance copy by ref such that it is possible to copy just elements of a rig rather than having to copy the whole rig and having to fiddle with "making invisible" the bits you don't want in the duplicate.

[JoelMayer]

That could be a solution as well yea! If i at least just have to move an arm reference layer around (esp. outside its rig) and not the whole thing it‘d already be a huge improvement.