Clipping inside game object

Questions
#1

Hello,
I have an animation that I manage to do with a GUI node, but it would need to be done with a game object, so I can create and load them dynamically.

Basically I’m trying to do a card flip animation, with a spine animation inside the card. I’d like the animation to be clipped so I can move it around a bit inside the card. I would also need for this clipping to support the rotation around the Y axis when I run the “flip” animation.

Can anyone give me some pointers? Ideally some simple examples that I can get me started. It seems it will need to be done through render script, if anyone has a simple example of a clipping/mask inside a game object I would glady take it. Thanks

#2

You’ll likely have to use render targets until we have multi texturing support for sprites or native clipping support for spine scenes.

For render targets, you’ll want to pre-setup a bunch of slots, then you draw to the slots based on setting the slot’s material on what you want to draw. You will want a render target slot per unique card you want to draw. There is room for optimization here on your part to use special slots that use a slot and just normal card draws. There may be things I don’t know about that could optimize it further too.

go.property("my_material", resource.material("/material.material"))
function init(self)
  go.set("#sprite", "material", self.my_material)
end

Then you draw each slot to a quad which corresponds to it. Now if you have a 3d camera you can freely rotate the card with clipping. You can even exchange data from the state of the card in the world to the initial render target render to do things like parallax offsets while rotating.

That’s skipping some details but it is the general idea. What you want to do should be possible currently though a tad annoying to initially setup.

There are full screen render target examples but afaik nothing specific to this situation using multiple for rendering things like this. It’s something I’ve wanted to make an example of for a while, an easy way to do it with 3d models and GUI is needed too.

2 Likes
#3

Hmm, isn’t this question based on the idea that you can’t create GUI nodes at runtime? But you can. You can just make one card and then use gui.clone_tree() to make more of them, right? And I know you can do 3D stuff in GUI, you just need to adjust the Z range in your render script so it doesn’t get cut off.

2 Likes
#4

That’s a useful insight! Or rather a revelation (which I forgot about). Based on that it seems like 3d models could be added as able to be drawn in GUI as a first class GUI component.

Here’s a test based on your snippet. There are some oddities to it maybe someone else can improve.

3DGUICards.zip (137.7 KB)

Another version. Setting the GUI material to highp for positions is necessary for the z values to look right. Still obvious room for improvement. Enabling the mips but adjusting the bias would help make it smoother.

3DGUICards2.zip (224.2 KB)

Another test with perspective camera, but that may be going toward breaking territory best used with render target method. Maybe there is a way to get it to reliably work within the GUI system. I also remembered an important texture thing that is to allow enough transparent pixels around sprites so they have enough room to blend soft edges, and in this case it means the edges as it rotates looks smoother. Some of the edge looks bad because both front/back is visible at the same time, but that can be corrected.

3DGUICards3.zip (224.4 KB)

6 Likes
#5

Thanks for the input.

The reason I turned away from using the GUI, is because I want to be able to load the spines dynamically. I don’t believe it’s possible to do this with GU (where I can use factories with game objects). Am I mistaken?
Basically, imagine my game having 200 possible cards (with 200 spines), but only 10 are used during a battle, is there a way to select which one I will load at runtime by using GUI? If yes then I could use it instead of game object.

3 Likes
#6

No I’m afraid that is not possible.

1 Like
#8

I’m struggling a bit to get that implemented. Do you have any simplistic example project that I could use
by any chance? Thanks

#9

Thinking about this again, GUIs are components, so you can make one GUI for each card, and one GO with each GUI, and spawn them as you wish. It’s one more thing to set up for each card, and the GUI won’t inherit position from the GO, so it’s a tiny bit more communication effort, but it should work. If you’re only using 10 or so then you won’t have any problem with cache limits or anything.

#10

Hmm yes that’s clever, I think this could become quite tricky after a while though, I don’t think the engine is designed to have 20 GUIs in the same collection.

#11

You can have a single GUI in a single collection proxy and then load/unload as needed. Setting it up in an easy to use way is possible so the loading/unloading is done by helper scripts and dummies may be used if you want to to be super dynamically loaded.

The default GUI component max is 64 but might be safe to raise, which means having a few hundred loaded at once may be reasonable even, though it would also mean most likely 2-4 or even more draw calls per GUI which may be more of a concern. It would be interesting to debug a game like Hearthstone and see how many drawcalls it uses generally.

About the render target example, search the forums there do exist samples. For a card slot version, I do not have a sample project like that made currently.

#12

Bumping on this topic. I’m about to give it another try (failed last time!).
If anyone has tried something similar in the past, I welcome any information/tips.