Abelius

10th March 2017:
Please, read final post at the end of the thread instead
---------------------------------------------------------------------------------

Well, I don't know if this is expected behavior or not... but it's a major pain in the royal back. :(

Please, be advised that I'm using version 3.4.02 because I'm waiting for 3.5.x to stabilize a little.

I have a toon with a lot of render separators (23). I need so many because my game will have... ahem... bodily interactions between characters and I really need to control which parts are drawn on top of each other. As you may imagine, life was already a living hell trying to organize that number of render separators, but now I've just found out a problem that seriously messed up my sorting order...

Some of the separators point to a skirt, blouse and other attachments that I want to switch on/off. Well, if I execute the game and then disable those attachments, then the separators that pointed to them skip them on their own and select the next available part. And not only that, the next separators also decide to change their parts for the next available ones in the list.

I've been banging my head about half an hour until I realized what was happening. :p

Thing is, if I cannot disable an attachment without losing my separator sorting order, then I'll resort to not disable any and change their alpha channel to 100% so they don't show in the scene... but that would be a real shoddy work, you know.

Is there any way to tell the render separators to not change their designated elements, even if they're missing?

If not, I really would like that you could choose that behavior in future versions of the Unity runtimes.

Thank you for your time!
User avatar
Abelius
Posts: 123

Pharan

I'll try to replicate the case you have.
Can you list how your slots are arranged? (which slots are used as separator slots)? And which slot has a hidden attachment?
User avatar
Pharan

Pharan
Posts: 4502

Abelius

Hi Pharan,

Thank you so much for taking your time looking into this. :)

This is what I had in my game...

Separator Slot Names


Slots/Attachments in the model


Playmaker commands that disable 'Blush', 'Skirt' and 'Top'


So when I start the game those three attachments get disabled immediately and elements 12 and 13 stop pointing to 'Top' and 'Skirt' and start pointing to 'R_Arm' and 'Head'. And the following elements 14, 15, etc., point to the slots assigned to 16, 17 and so on. In fact, elements 20, 21 and 22 end up by pointing to no slots at all. I suppose due to element 19 getting the rest of them.

However, one thing I didn't realized after writing this thread was that 'Blush' didn't get me any problems even if it's also disabled at the game start. But that slot is included in a render separator along with other slots... so when it got disabled, its parent element must have ignored that fact because it still had other slots to render.

In the light of this discovery I've made some tests and yes, it's confirmed...: even if you assign a slot to be hidden to an element, but it also "owns" other slots before the next part, you can click on the skeleton parts renderer and still has the remaining mesh/es drawn and it keeps from assigning itself to the next non-disabled slots.

So, my understanding is that as long as you don't create a separator that ends up with no slots to paint, then all will be fine and your sorting order will not get messed up.

Now... is this a desired behavior? In my humble understanding I'd say no. I'd very much prefer to be able to have render separators that only have one slot to render, and have the peace of mind that even if I disable their only child they will refrain from messing up my carefully set up layer sorting order. :think:

The only workaround I can think of, short of resourcing to not disable them and getting them transparent, would be to create a fake slot in Spine and put it "inside" of the separator with the slot to be disabled. But it also would need to be a transparent mesh and it would complicate my workflow even more.

So, could it be possible to prevent those renderers to think on their own? :D

Thank you!
User avatar
Abelius
Posts: 123

Pharan

I didn't read the whole thing yet, but can you describe the reason why you need 22 separators?
User avatar
Pharan

Pharan
Posts: 4502

Abelius

Hehe... actually I don't think I need so many in the final version, but I'm in the initial phase of ordering the model parts around and I prefer to have maximum flexibility.

This is how it looks like for a specific animation I'm working on now:



The numbers on the center are the 'order in layer' and the numbers on the extremes are the corresponding element. As you can see there a lot of them that could go in only one group. 15 and 18 are exceptions but yeah, I could do much better than this. :p

-- 10 Mar 2017, 17:49 --

Hi there,

Not wanting to be an ass necroing old posts, but I never got a solution for this and I humbly think that this is a HUGE problem in the Unity runtimes. At least from my point of view.

In short...: if you assign a given slot to a skeleton renderer separator element, and that slot end up with no active attachments at some point (which could happen with slots for clothing, jewelry, weapons, etc) the whole sorting order scheme gets pretty messed up, because that element loses its assigned part renderer, being effectively skipped. So the 'Order in Layer' value you did set for the original (skipped) renderer "overwrites" the next one in the list.

I don't know about you but I strongly believe that one should be able to configure a separator slot name to any slot, regardless if it could be either have active or inactive attachments at some point in the execution.

And why this is a problem? Because I'm making my characters interact with each other. Hence the need for renderer separators and so many elements that could be sorted out in a fairly complex way (adult game). :p

Well, I think the way it works now is ok if you're assuming your characters will always be separate entities. I also think that its been assumed that a slot will always be populated with an active attachment... and IMHO that's assuming too much. For me it's only normal wanting to have a special slot for clothing pieces that can perfectly go over an existing body part... being "can" the key word here. That's the point of this...: if I have a bracelet image that I want to activate for some characters but not for others, I want enabling/disabling them to be a seamless process.

The only thing that comes to my mind to resolve this is to, instead of enabling/disabling attachments, get them transparent or not... but... man, that would be so awful and inelegant that I'd want to cry as a baby every time I see my code... :S

Mmm, another "solution" would be to create placeholder slots in between the real slots I want separated, and put in them a transparent pixel attachment that I never disable and then assign that slot to the separator... another dirty fix.

So, any chance to get a proper solution instead? ;)
User avatar
Abelius
Posts: 123

Pharan

This should have been fixed in the latest version. It was a problem that the number of renders would be unpredictable based on draw order, as you've described. Sorry for not updating the thread about it.

Just to confirm, you've updated to the latest 3.5, right?
What behavior are you currently seeing if you have the latest?
User avatar
Pharan

Pharan
Posts: 4502

Abelius

I'm on 3.6.09-beta! :D Also, the runtimes are more or less from ten days ago, I think.

But... now that you're saying that it's supposed to be fixed in 3.5... mmm, maybe I need to do some more testing because now I'm working in another game from the date of the original post, and I'm not actually sure if what it's happening to me reproduces exactly as I mentioned in my last post.

Man, it would definitely be shameful if I misinterpreted what I've seen in my own game... :p

Will update this with my findings. Thank you for replying.
User avatar
Abelius
Posts: 123

Pharan

Well, it should be fixed in the 3.6 runtime too if you got the latest version from git.

Best of luck on your stuff!
User avatar
Pharan

Pharan
Posts: 4502

Abelius

Hi Pharan,

Sorry for taking so much time on checking this, but today it seems it's SkeletonRendererSeparator issue party. :p

I only wanted to mention that it seems I still have the problem described above, even with 3.6-beta runtimes.

In my current project I have a model that has a drooling (saliva) image and a pelt over his head and frontal arm. Both images are meshes inside their own slot each. 'Drool' is disabled by default. 'Pelt_F' is present only in one skin (Chieftain).

For sorting purposes I've put both of them in one Part Renderer. And the last Part Renderer covers the whole frontal arm.

Now, if I select the 'Chieftain' skin, all works as intended...:




But if I select another skin that doesn't have 'Pelt_F' enabled by default, this happens...:




The script parses the attachment list, and when it sees that one Part Renderer doesn't have any enabled attachments, it skips it altogether and I end up with the last one not rendering anything, and what it's far worse: with a different 'Order in layer' value.

This issue adds more grief to the one I've sent today, and sums to my understanding that maybe I'll be better off if I generate separators at runtime, because right now SkeletonRendererSeparator is not capable of being as flexible as I need.

But you also mentioned before that this was supposed to be fixed in recent runtimes, so I don't know what to think (?).

Is this working as intended or I have a bug on my hands?

Thank you for your time!

-- 10 May 2017, 15:53 --

Update: I've returned to my previous workaround...



Adding a transparent 4x4px image to the 'Drool_' skin placeholder, I manage to guarantee that the Drool slot will always have an active and "visible" attachment, so its associated PartRenderer never gets "orphaned" and skipped.

I'd prefer to avoid doing this, but if there's no other way...
User avatar
Abelius
Posts: 123

Daniel Swinney

@Abelius This is exactly where I am right now :/ And yeah, I had individually reached the idea that maybe I would need to add a transparent graphic for all of my slots that have a "None" option.

Some of the slots in my character template have clothing items that are optional, such as pant legs (you might just be wearing short trunks) so those slots have a "None" placeholder that just has no image attached.



This results in the separators being inconsistent before and after pressing the play button. When I'm just in editor mode, you can see that slot #9 is attached to the trunks/waist separator:
https://photos-2.dropbox.com/t/2/AADusYU-rUrdmVv63QoV4DyJGP_xCm_n9bYYnuF9of_noQ/12/9387525/png/32x32/1/_/1/2/Screenshot%202017-09-01%2011.44.07.png/EOrT_wYYiKEUIAcoBw/Hse0hzr92Eg1v6h_YEekCiX2IdqjY9f-l8M0kt2F-ME?size=1600x1200&size_mode=3

When I press play, perhaps because the character that gets loaded does have those pant leg slots enabled, things get pushed down and slot #9 is now the "far foot" separator.
https://photos-6.dropbox.com/t/2/AAB594bAGOSnLuA3XQijD0GOwQ9vS5YLr_qY8zUP7ewBdg/12/9387525/png/32x32/1/_/1/2/Screenshot%202017-09-01%2011.45.33.png/EOrT_wYYiKEUIAcoBw/JvlbFnutlq54aQSatq87BmYMdH59sosnV2TcRbbnS3k?size=1600x1200&size_mode=3

This obviously is a problem as far as setup and naming the gameobjects. I guess for now I'll try the transparent image workaround, but if anyone has a "real" fix, that would be fantastic.
Daniel Swinney
Posts: 4

Pharan

Your image links are broken. I don't think dropbox allows you to hotlink.
Anyway, this should have been fixed since that last post. I'll check it again next week.

-- 04 Sep 2017 10:37 pm --

There seems to be a bug.
It's not when the slots between two separators are empty. That should work fine. The bug is where a slot immediately after an empty separation is empty.
I'll see if it can't be fixed.

-- 04 Sep 2017 10:47 pm --

If you replace your SpineMesh.cs with this code: https://raw.githubusercontent.com/EsotericSoftware/spine-runtimes/3.6/spine-unity/Assets/spine-unity/Mesh%20Generation/SpineMesh.cs
That should fix it. This fix will also be included in the next unitypackage update.
User avatar
Pharan

Pharan
Posts: 4502


Return to Unity