Using Spine GameObjects as animated portraits

[RGV]

Hi.

We're struggling with Spine animations in order to embed them on DSfU.
We watched, downloaded and looked around the Spine example — that one with two space-guardian-looking NPC.
We had our system already working before, with static portraits. There were 4 subtitle panels (two on each side), one image and name panel each one, and also actor GameObjects. It was working but now it's time to implement the new step: animated portraits.
As I said, we animated actors through Spine, so we have Spine GameObjects we may use to. Subtitle panels' images are now useless, a we need to instantiate Spine GameObject related to characters. But the subtitle panels' image workflow was pretty easy and out-of-the-box, so we don't fathom how to accomplish the new flow.
What the Spine example does is merely have 2 NPC in scene, but a real use case may have dozens of different actors, few of them interacting in one conversation, in concrete positions of the screen.

To add context, we work with one independent scene called Dialogues, which is loaded when a dialogue is to take place. That scene contains all the dialogue system — It might works as a single scene as well, for example if anyone is testing a dialogue. Besides, the dialogue layout of our game is much more of a visual novel one, but no player-responses here. Think in usual RPG games with conversations where the player isn't capable to choose.
Dialogue flow is as the following:
—Anyone appears at some of four available positions in the screens, with any available emotion.
—Maybe other actos appears as well in other positions.
—That first one says something.
—Maybe that actor could leave scene, maybe stay in.
—Another actor appears in other available position.
And so on, 'til conversations ends.

There are many games using this flow, as you have already thought for sure, but I'm currently playing June's Journey in my phone and that is one perfect example!

[Tony Li]

Hi,

Are you using the Dialogue System's Spine integration?

If so, you can involve as many actors as you want in a conversation. Add a SpineDialogueActor component to each actor's GameObject. (The integration's example scene involves 3 actors.)

The Dialogue System Extras page has an updated version of the integration package that makes the SpineDialogueActor's Show and Hide methods virtual so you can override them -- for example to programmatically determine positions where you want each one to appear based on who is currently visible.

[RGV]

Oh yes, I'm using Spine Dialogue Actor as the example does.

Besides I have downloded the last extras update and now it's integrated on my repository branch.
By the way, importing the example it's logging:

Broken text PPtr in file(Assets/Pixel Crushers/Dialogue System/Third Party Support/Spine Support/Example/Animation/ExampleLeftSpineAnimatorController.controller). Local file identifier (110287092) doesn't exist!

The problem I was refering to has to do with that: http://esotericsoftware.com/spine-unity ... hic-and-ui. We don't want Spine Gameobjects in world space, but in UI. Sorry if I wasn't so clear — as English is not at all a language I properly manage with.
How is the suitable process to use it?
Thanks!

[Tony Li]

Hi,

You can make copies of the Dialogue System's Spine integration scripts and change them to use SkeletonGraphic instead of SkeletonAnimation. This will allow them to be inside UIs. They will otherwise work exactly the same.

Or you can simply edit the existing scripts and change SkeletonAnimation to SkeletonGraphic.

[RGV]

Ok! I'm trying tomorrow. If I successfully make it work, then I will post here my solution.

[RGV]

Hi there again!
Anyone who has come here finding Spine-DSfU-UnityUI combo interaction: you may interest this.

I kinda managed to reach something like that by the following:

• Actors will act as a portrait replacement, visually, so you can use Spine-portaits, so to speak.
  • Any actor needs a SpineDialogueActor script.
  • Any actor needs a SpineSequencerReferencesUI script — we're creating this script later.
  • Any actor has as a children a SpineGameObject. See NPC in Spine integration DSfU third party example scene.
    • Such a SpineGameObject needs SkeletonGraphic instead of SkeletonAnimation script.
  • So, we're creating SpineSequencerReferencesUI script. It's the same as SpineSequencerReferences but it references a SkeletonGraphic script. Hierarchy references maintains as in example scene. Don't forget update the missing references, as well as the new ones.

• Now we need update SubtitlePanel scripts, since they are not talking to our new SpineDialogueActor components.
  • Just replace them using SpineSubtitlePanel and fill properly all references.
  • Tip: this is a hierarchy structure you can see in example scene. If you had DSfU already working with Spine, this is completed by the time.
  • One last step. We need tweak SpineComponent sequencer controller, so it's using the new SpineSequencerREferencesUI instead of the default one.
  • You better DIY, to your taste.
    • You might copy the current SequencerCommandSpineAnimation and bring forth a new SequencerCommandSpineAnimationUI, so it's more cohesive to you. But then you will use something like SpineAnimationUI(test) in the sequence field within your dialogue entries.
    • Perhaps you want adapt the actual SequencerCommandSpineAnimation so it's able to use standard or UI component when needed! It brings transparency for whoever will use dialogue editor.

Hope it's helpful!

[Tony Li]

Thank you for sharing!

[RGV]

As we improve reaching a complete, working dialogue system with Spine in UnityUI, new doubts raise up.

The Dialogue System Extras page has an updated version of the integration package that makes the SpineDialogueActor's Show and Hide methods virtual so you can override them -- for example to programmatically determine positions where you want each one to appear based on who is currently visible.

That's such a good improvement in the integration package. But, how could we know who is currently visible?

The main new problem we're facing is that, now, every actor who speak is using the first subtitle panel, while before using Spine, the portraits system was doing well. For example, if two actor talked each other, it did put each one in different subtitle panels. As in visual novel example. New, every new dialogue entry, actor replaces the last one in default subtitle panel, regardless what subtitle panel number that actor has attached in its DialogueActor component.

[Tony Li]

I just updated the Spine integration package on the Extras page. The signatures of the SpineDialogueActor.Show and Hide methods are now:

Code: Select all

public virtual void Show(StandardUISubtitlePanel subtitlePanel)
public virtual void Hide(StandardUISubtitlePanel subtitlePanel)

This way you'll know which subtitle panel to show the Spine actor in. For example, you can position it in the same place as subtitlePanel.portraitImage.

[RGV]

Aligning actors to subtitle panel working really fine! Thanks for the fast update.

UPDATE: I'm editing this post from here, because of misunderstanding.

The only problem remaining from the last question is what I remark in the following:

The main new problem we're facing is that, now, every actor who speak is using the first subtitle panel, while before using Spine, the portraits system was doing well. For example, if two actor talked each other, it did put each one in different subtitle panels. As in visual novel example. New, every new dialogue entry, actor replaces the last one in default subtitle panel, regardless what subtitle panel number that actor has attached in its DialogueActor component.

That was happening in due to actor's components default subtitle panel. It was respectively pointing two different subtitle panels.
Now, how is the proper way to accomplish a conversant appears on a subtitle panel? For example if you want actor and conversant appear in screen while just actor talks. It is what happens in Visual Novel example. From the beginning, the conversant is shown. But it's managed through Visibility options in subtitle panels, and that is not what I'm aiming, but a way to control them from the dialogue design itself.