Hello, I think would be extremely helpful for most developers in here to get illustrations in a tutorial (or likewise API-reference) in regards to the ‘Pipeline overview’
What is loaded first (webserver -> DOM -> JS), handle times of scripts vs handle times of other ressources and especially how the ‘initialize’ functions.
This will also come in handy in regards to external references (have had my CORS-challenges over time and lately in regards to glTF as well).
As such: The motivation comes from this topic: [SOLVED] Trouble accessing children in a glTF-imported file (load externally)
Near the end of it, I write:
“Ok, works like a charm … will write a feedback to the relevant team about a “pipeline-model” etc in relation to “How things load” {might also be able to solve myths and mystique regarding the app.fire/time events}”
PS: I did see YauStar’s latest answer, within it … but most-to-all details please >> in an elaborated presentation.
What do you mean by handle times?
Ok, for instance, there is calculations of light at early runtime:
- You have a material that is about to load [at initialize] a complex set of submaterials (f.i. large dimensioned normal map + other asset textures). This is one material of many.
- This is then handled (at least precalculated … I guess) by the PC-renderer but with a complex set of light sources, multiple cameras with each their layers, effects, individual settings etc.
- Another layer of lighting is then put into the mix; Lightmapping plus a heavy cubemap environment. Times passes (microseconds … milliseconds), and then/only now the first frame/update is executed.
It might sound straight forward, but if it is too heavy to execute smoothly, I/developers might run into trouble.
I can use the Profiler to see some of it, but it seem too confusing (with 6-8 yellow lines of progress in realtime) to get a real overview in regards to optimizing 1-to-3 above. I cannot console.log those parts of the startup as they lay too early (the console/network helps some though [SOLVED] Trouble accessing children in a glTF-imported file (load externally)).
Yes, the whole page of https://developer.playcanvas.com/en/user-manual/scripting/anatomy/ is quite helpful (including the lines about ‘initialize’), but a better PlayCanvas-team elaborated ‘console output’ -clustertext in regards exact “what-does-what-and-when” within early calculations like 1-3 above can detail the processes (this option can be a button for optional use within the Profiler -> a text that can be copied/saved for the calm and analytic developer).
In my case I am seriously considering a JS-GPU performance splash-redirectingpage before the PC-preloader page, as so many platform-GPUs performs differently (tried a PC-project on a 6 year old Smart-tv … did not go well (mostly due to non-tick of preloads I presume, but could not find the GPU-perf. or timeout specs on the platform anyway)).
“Pipeline overview illustrations” would still be very helpful regardless 
… such as this (had similar illustrations at my uni/BA):
http://15462.courses.cs.cmu.edu/fall2015/lecture/pipeline/slide_046
PS: I hope that your team will pursue ‘a higher end’ in these regards of more/better info-pages … I had, for instance, a good experience with using the guidelines within [SOLVED] Physics mimic lighter than air gas particle, but afterwards I could not debug the physics part of the profiler properly -> should I lower update rate at physics/XYZ-translation script to render ‘my particles’ more smoothly? [please dont answer this now -> cluster-output text and/or pipeline illustrations would help]
// on before hand thanks …
I agree that having some high level event flow chart like Unity has here will be very useful and is actually on a todo list of mine https://docs.unity3d.com/Manual/ExecutionOrder.html#FirstSceneLoad
Adding console output of each of calculation on startup (eg shader compilation) could be useful (please add to the GitHub engine repo as a feature request).
If you are interested in this kind of thing, please consider making a PR to the engine as it undoubtedly help other developers too.
Super - helpful feedback indeed (I can make this one [SOLVED] … but do we do that within this category?)
