Hey @tuf, Thanks for brining up this issue. We managed to get it fixed, should be deployed to PROD in the next few days.
5 Likes
Textures donāt automatically tile and instead stretch. Having the textures automatically tile to fit the shape would immensely help development.
Hey Folks,
My team and I spent the whole week prototyping a version of our service using the editor and I thought youād like to hear our feedback (or even correct some of our assumptions on development process)
First, a bit of background:
Our team is 7 developers with a broad range of experience building with game engines and other real-time 3D libraries. We include designers, engineers, and artists whom all are used to working with each other on large game and service projects. We were interested in utilizing PlayCanvas as an answer to simplifying our current multi-sku Unity development process for web and mobile devices.
Hereās feed back from the team after spending a focused week using the PlayCanvas editor.
What we really enjoyed:
- The real-time collaboration in scenes and script editing was an experience that my mostly remote team appreciated and embraced on certain collaborative tasks
- The speed of deployment and delivery of builds to the team (1-click deploy to all devices was an amazing experience) - it was this iteration speed alone that hooked the team initially.
- Simple and Intuitive scene construction and components was easy for our design team to incorporate scripts and modify properties quickly
- Awesome community support and interactions from the developers
- turn key VR and touch controls
- amazingly fast to product āfirst playā
What we found frustrating
- Lack of a dedicated (nested) template editor
- Templates are not nearly as robust as prefabs (but theyāre arenāt that bad) The team simply wanted a more direct method of editing things without having to open a separate scene to make edits.
- Template variants seemed like an āall or nothingā approach to applying variations (so you couldnāt apply just one variation if the system detected 2 or more.
- Lack of a runtime editor state to see what the editor was doing at run time (this was one of the major let downs of the process and heavily slowed our development efforts when working with additive scenes and dynamically instanced objects
- Lack of full GLB support for scene management (we needed to invent a hybrid system to get dynamic scripts and properties to be applied)
- API documentation lacked examples of implementations (although community support here helped immensely)
- Integrated source control lacked individual file reverting, stashes, or reliable merge conflicts (this really hurt our confidence in the editor) - there was no perceived way to integrate a 3rd party source control due to the online nature of the editor.
- No offline editor support (we must develop with an internet connection, and for some remote team members this is a non-starter)
Takeaways
- The team is a fan of this community and the future of this engine and editor - many of us want to use this tool for personal projects. This product will certainly mature to be something special with additional time and resources (and the dedication Iāve seen from the core development team)
- As it stands today, we do not feel this editor would be the best fit for the way we prefer to develop our tools and platform, it would require too many process adjustment to remain as productive as we are today with Unity.
Hoping you all find this feedback useful as you continue to build out the future of PlayCanvas!
2 Likes
Thought I share some of the workarounds/workflows for some of the issues you and your team ran into to help the personal projects 
Dedicated Template Editor
A common workflow is to have all the templates in a separate scene. And because you have can multiple scenes open at once with the PlayCanvas Editor (two different tabs), that becomes the ādedicatedā template editor.
Easy to open too from the scenes modal
Or was this something you tried and it was still more friction than it should have been?
Runtime Editor State
Iāve created my own tool set for this. Rough around the edges but gets the job done for the most part: https://github.com/yaustar/yaustar.github.io/tree/master/playcanvas-devtools
GLB support for scene management
Is this related to the other thread about saving scene changes? I would probably have gone the way of reverse engineering the scene runtime JSON format which should be straightforward. The only caveat is that template instances wouldnāt be supported as thatās only known at Editor time
5 Likes
Thanks for your response. I want to thank you and the other PlayCanvas team members ( and forum community) for making PlayCanvas an amazing option for building 3D content for the web. I can see the commitment and passion present in these forums, the video series and work over the years ( Iāve been following since 2019) - Iāll be cueing up some personal projects in PlayCanvas to stay on top of the latest updates and hopefully raising more awareness.
Iām eager to try and dabble with some Quest 3 passthrough AR ideas I had.
3 Likes
I would like to propose a new feature that would greatly improve the management of packages, particularly for users with extensive package libraries. This feature would enable switching between versions directly within the editor.
Currently, our approach relies on the āversion=ā query. However, this method has its limitations and necessitates keeping track of each packageās original engine version. I believe that incorporating this feature would bring several benefits:
- Simplified package management: Users would no longer need to manually change/manage package versions, also eliminating the need for the āversion=ā query and its limitations.
- Enhanced Compatibility/Support: The editor would not only keep track of the chosen version and automatically ensure compatibility between exported packages and the target engine but also provide extended support for packages created in previous versions. This ensures that packages remain functional and exportable even when the original version has been superseded.
- Improved user experience: The overall package management experience would be streamlined and more intuitive, reducing time spent on manual version management and potential errors.
I would appreciate your thoughts on this proposal. Do you think its implementation would require significant development efforts?
Thank you very much,
@Change2 - could you please go into more details of what you do here currently? With some specific examples if possible, to better understand your current workflow and its complexities / limitations.
@mvaligursky thank you very much. Yes, sure. We have a number of packages, each created to display a specific scene. Some packages include custom shaders and scripts that may not be compatible with subsequent pc versions. Also, it can happen that between one version and the next, some details (colors, lights, materials, settings, etc.) change. These packages are exported and uploaded to various storage services for later use on different websites. We manually eliminate redundant files that donāt vary between packages (like the pc library, start.js, etc.) or those irrelevant to our needs (such as index.html, css, etc.). In the editor, we can select a specific version when previewing (version=) or downloading the package, but the latter only from a -limited- list of recent versions. If we need to re-export a package with code not guaranteed to run on newer PlayCanvas versions (like certain scripts/shaders), or with some details changed, we canāt choose the original/approved/tested version used for creating it. This limitation forces us to review/test/update all packages and scripts rapidly, a process thatās challenging to maintain and error-prone due to the limited time available. Ultimately, we wish to be able to choose, from the editor, the specific version we prefer to use and pick a new one only when ready to do so.
We had many internal discussions of allowing any engine version. We understand how this would be useful to our users. But it would require large amount of work on our side to maintain this. Typically for each engine release, we need to do few updates to do the Editor to make it backwards compatible, and in some cases where this is not possible, we update the Editor to only work with newer versions.
One thing we currently allow with the version is to use older engine version as part of the launcher. So the Editor itself runs on the latest engine, but the project can be launched on an older version. In the UI we only allow one older version, but from command line we allow any version, including a custom engine build. But again, even here we do not guarantee all older version, as the launcher uses the engine and occasionally it breaks. This is one of the main reasons we do not allow any engine version to be specified using Editor Settings - as we do not guarantee they all work, and cannot afford to fix older engines to work with the newer launcher.
We would like to allow to build with any version though, and have a ticket for this: Allow Engine Locking (Launcher + Build) - UI Ā· Issue #1071 Ā· playcanvas/editor Ā· GitHub
Perhaps this would help you with the most annoying part here.
Thank you, @mvaligursky. We understand the challenges and greatly appreciate your efforts. Weāre aware that there are other priorities and also recognize that not all users might directly benefit from this. However, to maintain consistency and allow more time to adapt to pc development changes, we believe we can find a balance that minimizes the workload compared to full backward compatibility for all engine/pc versions. Would it be possible to add one or two more options, like the latest minor versions of the previous two major releases? This could extend our development timeframe from weeks to months. For example, we could currently have the option to select versions 1.65.5 and/or 1.64.4, what are your thoughts?