Hey all,
I have a problem at hand that I would like to solve and was looking for any opinion on the matter.
So in my case there is a state that an entity in the scene can enter where it shows up with some actions to be performed on it for example, move, rotate, delete.
There is 2 ways to go about it:
- I create a script component on this and every other entity in scene (could be a count of 50) and enable/disable that component to show/hide these controls.
- I create one separate entity just for the selection menu in the scene that reparents one of the other entities from the scene as it’s child and does the manipulation. Once done, it reparent the entity back to where it belonged.
I see advantages and disadvantages in both the approaches as the first approach can be taxing at startup since all of the entities now need to be initialise this script component, which could be expensive (good thing is that all the raycasts and input events are handled by a separate script so these won’t all be running on these at all times + the component would be disabled). On the other hand, the second approach runs the risk of multiple heirarchy changes very quickly in the scene which I am not too sure about, but could affect performance or even break the whole experience suddenly if even a single event of call is missed for any reason (I will try my absolute best to make it bug proof though but the time is very short)
Does anyone have any feedback or suggestions regarding which approach you would personally pick and why in this case? I would love to hear all your thoughts.
Regards
I’m not sure you have to do either.
I’m not 100% sure what you are doing but it sounds like you could have this script on the scene root object. And then give it the entity that you want to perform these operations on.
2 Likes
Hey @yaustar
So think of this implementation as a context menu for a character in the application. There could be 100s of characters and when the user selects one of them, this floating menu shows the transform gizmo for that specific character. Adding it to the root, is what I was going with but it just make the transformations a little more complicated since now it would need to update the target entity (selected character) along with it’s transforms, which is fine but I have noticed tick misses with that in the past when users move to quickly.
I am heading in the direction you recommended as well but was wondering if just adding this transform gizmo to each character could be more reliable since the character would be now a child of the gizmo and transforms with it at all times. But this comes with the gizmo being initialised for each character, which could be an overkill
Sorry for not being clear the first time. Did I manage to clarify a bit more this time?
I would still go with what I suggested but take into consideration the update order/order of operations so that entities are not 1 frame behind.
tick misses shouldn’t happen as logic is running at the same rate as rendering by default.
I definitely wouldn’t add a gizmo entity per moveable entity
Example with the engine gizmo handler https://playcanvas.github.io/#/misc/gizmos
1 Like
Now I feel like I am touching playcanvas for the first time 
I am not sure why I didn’t see that example. Thank you so much for sharing that. Really Appreciate it as always.
1 Like