I would like to know if it is possible to see how the objects’ hierarchy changes in real time in the editor when you create/add/remove objects from scripts.
This is something that it is possible in Unity, but I do not see how to see my changes reflected in the PlayCanvas editor when these changes are performed through scripts (they are reflected if the changes are done from the editor).
It is really important for us, since it would allow us to speed the debug process. Right now it is hard to actually get a clear picture of the state of the hierarchy if you perform several actions to the scene tree from the scripts.
I’ve debugged this in the past via printing out the scene hierarchy in console log via a key press. I’ve been tempted to print it out to the scene so it could be seen in real time. It’s expensive though. Another solution is to only update the debug output when add/remove is called via Monkey Patching.
Yes, I would like to see the changes I made reflected in the editor hierarchy (the actual tree of entities).
It would be very very useful. Much more useful than writing it to a console.
In fact I think it’s the most important feature missing in the editor…
I guess the answer is that it’s not possible at the moment.
In Unity you play your game in editor. So your profiler is right there.
Playcanvas has separated editor and game, and I think it’s better.
And, as you can see, we have independent profilter. Since that, you can extend it by your own.
That does not explain why if you add objects in PlayCanvas (using the editor) while playing/debugging, the object is shown in the hierarchy, but not if you do it with code.
If you perform changes (via script) while playing, they are shown in the editor, but when you stop the player, the editor returns to the original hierarchy.
Therefore, I think it is perfectly possible…
… and strongly desirable IMO.
No, Unity created this problem. You used to use this instruments and workflow and now you feel uncomfortable with other tools.
PlayCanvas is little bit more low-level that Unity, so you have to be more programmer than designer.
When you play your scene in Unity it keeps your state and you can change it in runtime, but in this moment, your editor is profiler. And its wrong. I dont know how to say in in English, but there is a russian idiom for that - “it makes your hands crooked”.
I agree with @Sergio_Casas that in some situation would be really useful to have the editor to reflect the changes applied by code at runtime. Or, if not the editor, another kind of viewer that allows inspecting what is where, and what attributes the objects have at runtime.
This is very needed when you create script the procedurally generate or place objects, and you need to see where they are. Because most of the time you don’t get it right on the first shot and you simply don’t see them in the game view.
This applies to 3D and 2D too.
For example, I was creating a horizontal layout script to distribute 2D elements side by side at intervals automatically calculated based on element sizes.
I hit play, and I don’t see them. Then the only way to see what is going on is to use breakpoints and “see” the coordinates to understand what is going on.
Would be much easier if I could just use the editor camera to see the scene, select elements and read their properties in the inspector.
There are many more examples I could give (shader coding - that now can’t be seen at all in the editor, inspecting physics behavior, etc…) that would be much simpler by having a scene viewer with hierarchy and values inspector.
Of course, allowing to edit runtime values for testing and debugging would even better, because now you can only edit at runtime values int the editor for objects that are already there from the start and not for objects added by code.
I think you are missing the point. We are not speaking at all of profiling to test speed or memory allocation.
We just need to see the objects with an independent camera, allowing us to select an object (by clicking on it or selecting it from a hierarchy) and see/change all its values with the same visual panel of the editor.
About using only one monitor, nothing prevents the debug mode to have an additional camera and UI to see the hierarchy and the inspector. These elements could be just enabled/disabled by some key combination, so you show them only when you need.
Of course, this could be coded but is a lot of work, and having the editor already implementing all these features, could be much easier to start from it.
