Idea for a new mechanic

[ImpMontezuma]

Hello, I'm new to moho scripting. And I have several ideas of things to create. I'm still reading the documentation. But anyway, I wanted to ask the more experienced people if some things are possible and have been tried before. The first one is to try to separate the rendering from the position of the layers. I think the advantages of this are pretty obvious. Which makes me believe it must be either very difficult or impossible to do. Anyway, which one ^^?

[Lukas]

The first one is to try to separate the rendering from the position of the layers.

Could you be more specific? I have no idea what you're trying to achieve.

[ImpMontezuma]

When you render a frame, moho renders each layer based on its order, like a queue, right? Where a layer in the later position sits on top of the earlier ones. If I'm not mistaken, the layer ID is actually the position of it in that queue. But anyway, I'm thinking of finding a way to "force" moho to render each frame, not based on the order of those IDs, but on a "random" order defined by the user. I believe Unity has a similar mechanic.

[hayasidist]

the immediately obvious solution is to use moho's capabilities to reorder the layers using a script (or, of course, manually) -- there's no scripting access _within_ the render engine..

take a look at GroupLayer:GetLayerOrdering()

Moho uses Layer UUIDs - unique identifiers - so the layers are ordered using those ...

e.g. if you create a table of uuids and you start with layer uuid[0] above uuid[1] to swap them at frame f use the animstring set value function

GroupLayer:GetLayerOrdering():SetValue(f, uuid[1] .. "|" .. uuid[0])

[Lukas]

Moho's biggest problem with rendering layers in a particular order is how rigging/masking/animation are all in their own way tied to the layer-order/nesting in the layer panel. If you'd change layer order by script, you will definately also mess up your entire moho file (unless it's a very simple file with no rigging or nested animation of course).

I agree Unity's approach to stacking sprites would be a good match for Moho and it would get rid of a lot of duplicate rigs in a lot of situations.

It's not really doable by script. Unless you somehow manage to render each layer as a .png and stack those images with automated compositing elsewhere I guess, but there's a lot that could - and will - go wrong.

Scripting layer order is doable (I've scripted a few ways that I still use a lot), but it has its limitations, so unless you have a specific example of what you want to do I won't recommend it.

[ImpMontezuma]

the immediately obvious solution is to use moho's capabilities to reorder the layers using a script (or, of course, manually) -- there's no scripting access _within_ the render engine..

take a look at GroupLayer:GetLayerOrdering()

Moho uses Layer UUIDs - unique identifiers - so the layers are ordered using those ...

e.g. if you create a table of uuids and you start with layer uuid[0] above uuid[1] to swap them at frame f use the animstring set value function

GroupLayer:GetLayerOrdering():SetValue(f, uuid[1] .. "|" .. uuid[0])

I see, well, changing the order that moho renders the layers was the easy way to solve this. But I'll think of alternatives here. Also, thank you for the information, I'll look at that method

Moho's biggest problem with rendering layers in a particular order is how rigging/masking/animation are all in their own way tied to the layer-order/nesting in the layer panel. If you'd change layer order by script, you will definately also mess up your entire moho file (unless it's a very simple file with no rigging or nested animation of course).

I agree Unity's approach to stacking sprites would be a good match for Moho and it would get rid of a lot of duplicate rigs in a lot of situations.

It's not really doable by script. Unless you somehow manage to render each layer as a .png and stack those images with automated compositing elsewhere I guess, but there's a lot that could - and will - go wrong.

Scripting layer order is doable (I've scripted a few ways that I still use a lot), but it has its limitations, so unless you have a specific example of what you want to do I won't recommend it.

I agree, changing the actual layer order would probably do a mess. that's why changing the rendering order would be the easiest solution, which wouldn't influence the hierarchical structure of the layers. But, after giving the problem a little more thought, I'm sure it can be done somehow. As you said, we can do this even manually, without any script. But that would solve only half of the problem. Which is, the final render of the animation. There is still the pre-render shown in real-time to the user of moho. Although for that one, I thought we can force moho to hide from editor view all layers, except the one selected. Then, we create images of the other layers, in front, or behind that layer, outside the main structure, in the order the user chooses. If I understand correctly, that could be done with the method "LayerAsImage". Also, I believe that's how moho does it behind the curtains. Since we can see the other layers as bitmaps after you select a new one. Anyway, I'm just not sure if that would make the selection of a new layer be too laggy. Since moho would have to make the image of the previous layer selected every time the user selects a new one... at least if he changes it... ... Also, I didn't give much thought to how that would influence the other frames of the timeline. Well, I'll do some tests here. Also, If anyone wants to it try too, be my guest ^^, I'm don't care about credits or recognition, I just want to see those things working XD.

[hayasidist]

well, yes, layer order if misused can cause chaos! even moving bone can cause a mess if you don't think about what it will influence...

So, assuming I understand what the unity sprite orderer does: you have a set of objects that themselves are independent of other sprites. You can put them in a sorting group and assign them "depths".

If so, it's already built in to Moho.

The "sorting layer" is an overarching group layer with sort by depth enabled. within that group layer, you have groups of independent objects, and you set their layer z to the order required. By using a sufficiently small step (say .01) any scaling parallax resulting from a large z separation is avoided.

see also http://lostmarble.com/forum/viewtopic.php?f=12&t=33324 which adopts a different approach to depth sort...