Navigating to different scenes

General Discussion
#1

Hi,

I would like to check whether any tutorial or reference available for implementing navigation to different scenes (Scene transitions) using ZapWorks Studio.

Thanks!
Latha

1 Like
#2

Hi @pl.latha.sg!

I believe that I have answered your support ticket, but just in case this helps anybody else - we have a great article about Controllers and States here!

You can activate states with actions or script. You can find the Z.State scripting reference here :grin:

You can have one active state per controller, so if you want to have multiple states show at the same time, they should be under separate controllers.

Have a great day!
Francesca :blush:

#3

[half-SOLVED]

For totally-beginners like me (skip if you don’t need the context)

Hi, I too have been looking for a long time a way to move/navigate between “scenes”. That is a word used in Designer but not present in Studio documentation and is possible that Latha (@pl.latha.sg), as me, was intending something like PowerPoint slides and transitions. I found time consuming and messy to work scenes with Controllers and States as suggested by @Francesca: imagine 3 or more scenes, each with many elements (i.e. nodes/objects), and then having to go scene by scene (i.e. state by state) manually deactivating all the objects belonging to the other scenes. A little mistake might make it appear things where you don’t want. In Designer, once you are in a scene, you just don’t mind about the objects of the other scenes or “slides”. I found another suggestion, by @margaux: create different ZPP projects, each one being one scene, and then import them as Screen Symbol into a main project. I think this is bulky plus you need to figure out how the other scenes keep tracking the tracking image.

half-Solution

It turns out that Francesca is right (surprised? She works at ZapWorks haha!) OK but I dare to suggest:

  1. In the Hierarchy, create a group per scene and insert all the nodes that belong to that scene. Example of group name: assetsSceneHome.

  2. Create a Controller where you will store your scene states. I called it “Scenes”.

  3. Create a state, let it empty and name it (I called it “blank”). It works better if this is the first thing you do in the project, to avoid the complication of seeing objects in the screen that do not belong to the scene.

  4. Duplicate your blank state and give it the name of the scene (e.g. sceneHome).

  5. Be sure that the newly created state is selected, not the blank one, and start adding your objects to the Hierarchy placing them on the screen.

  6. In your controllers panel (bottom left) click on base (if you don’t, you won’t be able to add objects to your state to further modify them).

  7. In your Hierarchy panel select the group that contains the objects of the first scene, and then select the + sign in the properties panel for these properties: enabled, visible. (I prefer to click first “enabled” for esthetic and order reasons, as it will be shown in a table below the screen). (I suspect that you might have an object invisible and still can click on it… I don’t know if that is the reason a previous project of mine was not working, since the button object was exactly in the same position of another button object from another scene. I still have not figured it out).

  8. To create a new scene, click on the blank state (it will make your screen empty again) and repeat steps 4, 5, 6 and 7. Name it for example scene2. Once done, uncheck the enabled and visible properties of the group containing the objects of the other scene (e.g. sceneHome).

  9. If you want to have more than two scenes, repeat steps 4, 5, 6, 7 and 8 but be sure that the enabled and visible properties are checked/true just for the group of objects you want to be in that scene, and it is unchecked/false for the other groups.

  10. Now you can add navigation interactivity. Click to the state you want the user to be as a scene and click on the object you want to behave as a button. In the properties panel, you can add an action on tap > Activate State and then select the controller and state you want the user to go. I cannot resist telling how messy things could have been activating/deactivating-other-scenes if you have not done the previous steps. You can also use script for the navigation, using a function for the button each time it is pointerdown i.e. clicked/tapped. Having done the previous steps results in just two lines of code to move the user to the scene you want him to go, by activating the corresponding solely state. Here is an example:

    symbol.nodes.MyButtonToGoToScene2.on("pointerdown", (e) => {

   symbol.controllers.Scenes.elements.scene2.activate();

   // if you had not done the previous states, imaging having to deactivate the other states here.

});

symbol.nodes.MyButtonToReturnToSceneHome.on("pointerdown", (e) => {

   symbol.controllers.Scenes.elements.sceneHome.activate();

});

PS 1 Wow, it took me a lot of time to write this. Now I understand why experts write concise. The problem is that with concision you lose context, and without context we beginners lose time guessing. Have a good day dear reader. God bless you. Thanks again @Francesca!

edit: PS 2 why it is not a perfect solution/ feature request
So, after writing all this I returned to the project and realized that if a button needs to be present in different scenes (like MyButtonToReturnToSceneHome)… I cannot insert it into a new scene/state by enabling and making it visible also in the new scene. I think this is because it belongs to a group that is disabled/invisible. I might need to duplicate the object and I didn’t want, to reduce weight to the project. Also, I may try creating a group with global assets, i.e. assets recurrent in different scenes. I thus humbly request to the Zapworks Team to consider adding something like Designer’s scenes but in Studio. Thanks!

Recommended related links:
suggestion of creating a new project per scene
https://forum.zap.works/t/button-to-go-to-next-state-how-to/1032/2
https://forum.zap.works/t/creating-a-button-to-toggle-between-two-states/711

2 Likes
#4

That’s ace :slight_smile:

Random thoughts in random order:

Subsymbols and tracking: You can, if you want, create your different scenes as subsymbols (so you could create them separately and then import them, or create new empty ones directly in your main project, then dive in and add all the content). Then you can drag those subsymbols over into your hierarchy.

If you’re using image tracking and want all your scenes to stay tracked to the same image, don’t add target images within the subsymbols (which probably won’t work properly anyway). By default, if the root node inside a subsymbol is set RelativeTo “- - -”, that whole subsymbol will end up being parented to whatever it’s parented to in the main project. So if you have:

  my_image_target_node
      scene_one_subsymbol
      scene_two_subsymbol

then both those subsymbols will stick to your tracked image… but only if the root node inside each subsymbol hasn’t been set to something other than “- - -”.

This does mean that when you’re inside a subsymbol adding content, you can’t see the tracked image, but in practice that doesn’t tend to be a problem; you can always drop a copy of the image into the subsymbol just to get the positioning of things right, then remove it (or hide it) when you’re finished.

PS2 - global navigation buttons: It’s incredibly handy how all the things inside groups inherit the visibility of their parent – you can turn a bunch of stuff visible or not with a single state or line of code. I don’t think you need to worry about adding weight to your project with duplicated buttons, though; it’s not the nodes that take the space up, it’s their content. So a dozen buttons all using the same bitmap or 3D object aren’t going to take much more space (relatively) than having one single one. But yep - if you can keep the ReturnHome button in a group separately from your scene groups then you can switch it on and off independently.

Duplicated objects and project size: If you use the same object in multiple subsymbols, Zap’s smart enough to spot it, and will only include the object once in the final uploaded project, even though it gets used in various places. So if you have a number of subsymbols all using the same big bitmap, say - which means that you’ll have “imported” that bitmap several times - only a single copy will actually end up as part of the project. It needs to be exactly the same file each time, and if you’ve played with the compression settings (right-click an image in your Media Library and choose Properties to tweak things), then you need to make sure you use the same compression settings for all instances of that image. It’s well worth playing with those settings, though, and looking at the project’s Final Download size (on that funny little Zap menu next to the Commit button) - I’ve managed to get my current project down to a third of its original size, without losing any visual quality, just by playing with the compression settings.

PS1: documentation is hard, isn’t it :slight_smile: Got a lot of admiration for the people who wrote the Zap reference docs and tutorials, cos it’s incredibly tough trying to describe all these buttons and parameters sensibly. So thanks for writing this up, it’s really handy.

1 Like
#5

Oh wao! @howiemnet you made me smile several times while reading you. Thanks.

  • I didn’t know that subsymbols’ positions were relative to their parent target image. @margaux said in her post that then you navigate via a pointerdown script that displays the scene. She didn’t write an example, but I assume that it’ll need a line to activate that scene plus also lines to deactivate the other scenes.
  • I thank you a lot for explaining how ZapWorks deals with objects and duplicated object file sizes. And what I enjoyed the most of your comments were the tips to optimize project weight. Thanks! Have a good one!
#6

:slight_smile: This forum is great for making you smile. Nice folks here. Plus it helps that AR is fun to play with…

Just wanted to clarify one thing you said:

I didn’t know that subsymbols’ positions were relative to their parent target image.

Their positions are relative to their parent in the hierarchy, so that can be a target image, but it can be any other node or group (or Z.screen or Z.camera etc) you like as well. And to make things even more flexible (or complicated!) there are two ways to override it: you can either dive into the subsymbol and set its root node’s Relative To property to something specific instead, or out in the main project you can set the subsymbol node itself to be Relative To something different.

If I’m making a subsymbol that’s got some 3D stuff in it, I’ll leave its root node set to “- - -” so that when I drop that subsymbol into the main project, I can put it where I like.

If I’m making a subsymbol that’s going to be 2D - maybe a menu on the screen, or a score display for a game - then I’ll set its root node to “Z.screen” instead. It won’t matter where I drop it into the main project; even if it’s under a Tracked Image, it’ll override all that and show up relative to the screen instead.

Once it clicks how all the Relative To stuff works, it’s incredibly powerful and logical, but it took me a while to understand why things weren’t working how I wanted at first.

The priorities - how Zap decides what an object is “relative to” - works from the bottom up. So any child node can override its parent if it likes, or they can say “- - -” which means OK, I’ll be relative to whatever’s just above me in the hierarchy.

Which is the opposite to how the Color / Visibility / Enabled parameters work - parents are always in charge. If you set a node’s colour to, say, [1,1,1,0] - white, but completely transparent (that last zero!) - then all child nodes under it will end up transparent / invisible, regardless of what Color they have set, and regardless of what their position is relative to.

For some things the children are in absolute control, for some things the parents have the final say… sound familiar? :wink:

#7

update on duplicating object method: it doesn’t seem an improvement

Before anything, yeah @howiemnet I know what you mean about children in control haha. And thanks for all the other inputs. The funny thing is: I understood :smile:

Just wanted to mention that I tried not using a group of “global assets” but instead duplicated the object MyButtonToReturnToSceneHome and placed each instance inside the correspondent scene groups. You know that when you duplicate an object, ZapWorks automaticaly assigns a number to the name to differentiate it from the original. You end up with object, object0, object1 and so on. Given that the abovementioned script makes reference to this object by its exact name, I renamed the duplicated objects to call them all the same: MyButtonToReturnToSceneHome, by deleting the added numbers. Not having done so would have required me to create a new function to go home for each new object: MyButtonToReturnToSceneHome0, MyButtonToReturnToSceneHome1 and so on.

I expected that different objects having the exact same name would trick the script and each would have behaved as the single function commanded… it didn’t work. I mean, one of the objects sent me home, the other not. To discover what was happening, I switched the object that work/didn’t-work from their scenes, and the one that works was working, in the new scene I placed it. Conclusion: Even though you call an object with the exact name of another, ZapWorks will internally know they are different (makes sense, if not there would be conflicting issues).

Bottom line

So, my feeling about the 4 methods discussed to navigate to different scenes:

  1. Just controllers and states: becomes messy the more scenes and objects you have.
  2. Make a project for each different scene and import them as screen symbol: many steps.
  3. Create subsymbols: you lose handiness/easiness to move between scenes, is not a PowerPoint-like experience. You said “to dive”: is exactly like that, imagine to jump in and jump out, and every time you jump in, you don’t see what’s in the other scenes.f You need a trick to see the tracking image and assets of the other scenes are not at hand if you are creative and suddenly want to try move one in the scene you are currently working. (To be fair this is an assumption, I have not tried this method).
  4. Create groups per scene and a global assets group: Is the closest PowerPoint-like editing-UI (you can see the scenes you are editing as fast as just clicking in the scene state); need less lines of code; and you can move objects easily through groups, which is great for creative people like me that prefer a What-You-See-Is-What-You-Get editing experience.

A hug to eveybody. God bless you dear readers.