ok, but can we agree that âsome things within the HTML is being precompiledâ before the actual render?
(hope this thread isnât simplifying the details too much - the compiled HTML-output is namely/for instance wrapped into structures like this in order to work like an ordinary HTML-page rendering:
// create STYLE element
var style = document.createElement('style');
// append to head
document.head.appendChild(style);
style.innerHTML = this.css.resource || '';
// Add the HTML
this.div = document.createElement('div');
this.div.classList.add('container');
this.div.classList.add('body');
this.div.classList.add('myIframe');
this.div.innerHTML = this.html.resource || '';
// append to body
// can be appended somewhere else
// it is recommended to have some container element
// to prevent iOS problems of overfloating elements off the screen
document.body.appendChild(this.div);
)
If we had a pipeline overview diagram (have debatted @yaustar on that matter), it would be easier to rule out if some fallback is taking place CSS-versionwise/anyway (CSS - Wikipedia)
once a project is published/exported, one cannot alter the Vanilla JS above in a separate script/file â as such âthe project is undergoing some sort of transformationâ from editor to a functional webpage (I really donât care if I am totally wrong here â again; if pipeline diagrams were available it would help me, but properly also many others ⌠in other words; everytime I test, the âPlayCanvasâ logo still prompts/the engine executes the entire project-scene, and once in browserstate, the Vanilla-script above is not visible in devtools {?} )
If you would like to keep altering your Javascript script assets after you publish a build, then you can deselect âConcatenate Scriptsâ in the publish new build dialog.
Your JS scripts will remain separate script assets which you can find in the assets folder of your downloaded zip bundle.
I wonder if I should try and merge it into a PlayCanvas project (?)
Regarding the canvas part, I have not had the best experiences with fitting that in PC already.
Obviously it would be a wild shot, if all such libraries functioned within PC. On the other hand, as I have experienced some trouble with image-manipulation within PHP, the Sass-approach above would be quite helpful ⌠so what does your gut feeling say? Should I try and push it for the devs? (or let is pass, due to norms/strategies/habits on their side)
No browser supports SCSS, and as such the PlayCanvas code editor doesnât support it. You will have to compile your SCSS to CSS yourself before using it in the browser.
hmm ⌠ok, nice to know about SCSS - they (who post such examples) must âlive in their own worldâ (al though the example page did seem to execute some of the content)
I donât know about them, but most likely itâs not they live their own world, they will have implemented a SCSS preprocessor in place.
If it works in the browser, it will work in PlayCanvas. PlayCanvas doesnât mess at all with HTML/CSS elements. So yes, it will work.
But if you have trouble, I would first suggest some DOM manipulation tutorials so you get some experience on how Javascript can be used in that context. Later on you will feel much more comfortable implementing those kind of code examples, either on PlayCanvas or in the browser directly (even in the browser console).
ok, great and thanks for the âpath/approachâ ⌠final thing (in case you have the time/skimmed the save-image part)
â if you remember the Screen capture tutorial: Capturing a screenshot | Learn PlayCanvas
Can I use that effect to save serverside? {I have been across this issue, but a little desperate in relation to a current project}
[All in all: my goal is to let people upload a photo to be used in the project; where HTML-layer is ok, it is best for me with used-as-texture (upon 3d environment objects - the backlayer content)]
Yes you can, as youâve guessed this isnât PlayCanvas related. You will need to use a Rest call to your PHP or other kind of server to save the file.
Do a search on the subject and you will find a lot of material to get started on this, useful search terms:
âhow to save a base64 image to serverâ
âhow to save a canvas image to serverâ
As Leonidas mentioned, PlayCanvas is not responsible for HTML/CSS rendering. It doesnât do any processing on HTML or CSS code during builds or in the launch tab.
ok, now it is - for sure - [SOLVED]
{had lines of â.container >â in front ⌠maybe that was the err}
yet in regards to âtop layer renderingâ, the community points to solutions with âHTML/CSSâ above as an âexpanded and useful approachâ (but I know; greyzone )
yet in regards to handling the total web solution ( a. 3D content as background and b. HTML/CSS as a top layer within the total render layers), the PlayCanvas community (including its tutorials) points to solutions with a âHTML/CSSâ-layer at the top layer. As the layers can communicate, I consider it an âexpanded and useful approachâ (still, The PlayCanvas admins + community does not have any responsibility for the âHTML/CSSâ-tutorialsolutions etc â I guess the emphasis is on the lower layers; greyzone )
Some of the older tutorials use HTML/CSS for the UI (which is a valid solution as it gives the developers and user a lot of features from the browser DOM and allows them to use React, Vue etc).
Since then, PlayCanvas has itâs own UI system implemented which can be used instead/as well that renders in the WebGL context: User Interface | Learn PlayCanvas
You can use either or both depending on needs and requirements.
The forums/tutorials generally donât provide support for HTML/CSS as quite frankly, that is better served elsewhere (Stack overflow, etc)
I consider the User Manual | Learn PlayCanvas (+ User Interface | Learn PlayCanvas below it) quite ok, but if PlayCanvasâ main introductory and more complex info-pages, should be enhanced/optimized ⌠become improved, diagrams could be used, to explain all (or close to all) the possible âexternal contact surfacesâ (PHP and MySQL can f.i. communicate ⌠plus React, Vue etc (as mentioned)).
I acknowledge this from user-interface: âFor some use cases using the HTML, CSS and the browser DOM are a good fit for your user interface.
The primary downside of using the DOM is performance. âŚâ
But even though PlayCanvas has main emphasis on âgames and 60+ fpsâ, my current projects lay within Configurators | PlayCanvas and the like, where 30 fps seems adequate.
For the moment I work on a video-project, where the â30 fps-MPEGâ standard is adequate.
Here are some pipeline-examples from Unity and OpenGL (for diagram inspiration):
Could be fun to create such diagrams myself (or at least try and/or start to), but as I am sitting with my own projects (+ not being on the PC payroll ;-p ), I cant find the time for it ⌠all I am saying @yauStar; we talked about this before, and in case you agree that some members (me included) could benefit (plus; it could save you from some explanations for other forum low+medium-level users), such diagrams could refine the - already good - knowledge sources
Again; if you dont have the time yauStar, âweâ should/could be able to make it challenge, for one of the better ânon-admins/non-devsâ (I guess @Leonidas donât have time, but maybe challenge one/some at that level).
" ⌠HTML/CSS ⌠better served elsewhere (Stack overflow, etc)" â I totally understand, but how can newcomers to the forum get that information + grasp those admin-strategies/ownerâs visions? ⌠maybe on a minor âPC-Atlasâ (with some good diagrams below)