pc.Application.getApplication().scenes.loadSceneHierarchy() broken?

Help & Support
#1

There is unexpected behavior in my project. I am new to PlayCanvas and the problem certainly can be a fault in my code. The full code is included below.

Questions

  1. How can I change my sourcecode to meet my expected behavior?
  2. Does this demonstrate a PlayCanvas bug? If yes, when will it be fixed?

Demo

I created a demo project to test reloading the current scene. I attempt to use the recommendations I see on the forum.

Expected Behavior: During ONE session, it works the first time and EVERY time after the first.

Actual Behavior: During ONE session, it works the first time. Then breaks the 2nd time sometimes. It breaks the 3rd time always.

https://playcanvas.com/editor/scene/919848

Image

Log showing a) expected, b) expected, c) not expected

2020-05-11_18-35-06
2020-05-11_18-35-06690Ɨ522 33.7 KB

#2

Here is my fixed fork: https://playcanvas.com/editor/scene/919880

When listening for events on object whose lifetime is not the same as the listenerā€™s, it has to be removed at some point (in this case, the listenerā€™s entity destroy event).

As it wasnā€™t removed, it was calling the callback twice the second time round.

1 Like
Model not loading on app.loadSceneHierarchy
#3

Excellent. That workaround performs well.

It is unmanageable to handle a complete game this way.

As a core API request, I recommend a few mutually exclusive features

  1. API allows to load new scene non-addititively where nothing in runtime persists except the new scene (Unity calls this ā€œSingleā€ https://docs.unity3d.com/ScriptReference/SceneManagement.LoadSceneMode.Single.html)
  2. API treats destroy as a first class citizen of script (e.g. like ā€œinitializeā€ and ā€œupdateā€) and does not require manual listening.
  3. API allows for a version of observing events [e.g. "blah.on(ā€œblahā€, this.handle, this)] which will release the event subscription from blah if ā€˜thisā€™ is destroyed.
  4. API allows for app.Restart() or similar which mimicks the first-run of the application which is somehow faster for developers than refreshing the page (takes about 5 seconds for me)

Thanks!

#4

Thanks for the feedback!

  1. Iā€™m currently looking at the scene loading API as there are some parts that are causing issues for developers.The issue is unlike Unity, all of the assets and resources are currently been served over the network which adds itā€™s own set of complications and potential delay in getting the JSON data. Iā€™m currently thinking of separating the load of the JSON data of the scene itself to the creation of the entities and it being added to the scene graph. This is still in discussion internally (you may see it be a draft PR on GitHub) so I add a simplified loadSceneSingle call to the discussion as I think it would be good to have too.

  2. Have to defer to @will on this one. Iā€™m sure there was a reason for it but it was before my time :sweat_smile:

  3. This one is difficult. It does often trip up developers new to PlayCanvas. The issue that that the this object may not be a Script Instance (bearing in mind that the Engine can be used independently to the Editor platform). It can be a plain Javascript object that which would require manual removal of the listener. We could potentially have check of the type of object this is when it subscribes and listen for a destroy event if it is a Script instance :thinking: This could add some complexity as the whole of the engine is pretty much using this event system (every PlayCanvas class has an instance of the event system so they all can fire events and have listeners added to them). Not entirely ā€˜happyā€™ about having different behaviour based on the type of object passed though.

  4. This is difficult as so much can happen at runtime including the application changing global data, assets, materials etc could be added/loaded at runtime. 5 secs does sound pretty long though as the preloader should take into consideration of the local browser cache. Anything beyond that I would assume be shader compilation and scripts initialisation :thinking: . Dumb question: are you reloading with Devtools open and Disable cache is ticked?

#5

Great info per 1/2/3. Per #4ā€¦I donā€™t know how to answer the question. Here is a video of my (relatively small?) project as I refresh the browser.

#6

Interesting. As you are using physics, that delay could be due to the Ammo physics library being parsed and started (it is a pretty hefty file and using WASM) :thinking:

Edit: Doesnā€™t seem like it using my own project. I would look into the Chrome Devtools to see what could be causing it to take so long after a standard refresh. This a recent example project with Physics

#7

Great info.

Yes, this is a physics project using Ammo. In the video I shared, its about 5 seconds from clicking refresh to scriptā€™s initialize(). That was the latest firefox. I just tried in the latest chrome. Its about 4 seconds.

Iā€™m very jealous of your < 1 second refresh :slight_smile:

Iā€™m new to JS & browser development. What can I disable in Chrome reduce the refresh time?

#8

Is the project public? It be interesting to see if I can repro it on my local laptop. That will help isolate if itā€™s an engine issue vs maybe something to do with the local setup.

Edit: I do recommend looking at using the browser devtools as they are pretty awesome: https://developers.google.com/web/tools/chrome-devtools

They are able to give full breakdowns of CPU time, load time etc as well as the usual code debugging (breakpoints etc). :slight_smile: