engine
engine copied to clipboard
playcanvas
Engine 2.0.0 (Root ticket)
Overview
This is the main ticket to communicate the plan and major changes for Engine 2.0.0.
Over the years, the engine has introduced many new features and deprecated several obsolete ones, often maintaining them to avoid disrupting existing projects. This maintenance carries a significant cost and slows down the development of new features, as time and resources are diverted to supporting deprecated functionality.
The plan
The plan is to release Engine 2.0.0 (V2), where we will address and remove multiple deprecated features. While many of these changes are breaking, there's no need to worry. Teams that depend on these features can continue using Engine V1, which will remain available. Both Engine V1 and V2 will be supported by the Editor, and by default, your projects will stay on V1 unless you choose to switch to V2 after confirming compatibility. The Editor will maintain backwards compatibility with Engine V1 for as long as necessary.
What do these engine versions mean?
- V1: This is the engine as you know it, with the latest version being 1.71.4 at the time of writing, containing all existing features. We will primarily release fixes for this version, although occasional larger changes may be included. However, no new major features will be added; for those, you'll need to switch to V2. The code for this version is in the
main_v1branch. - V2: This version is contained in the
mainbranch. We will begin by removing some deprecated functionality (see list below) and will also add all new major features here.
V2 changes
Major confirmed changes in V2:
- [x] WebGL1 is getting removed, and only WebGL2 and WebGPU is supported. If your project still requires WebGL1, you will need to stay on V1.
- [x] The AudioSourceComponent is removed as it has been replaced by the SoundComponent a long time ago. https://github.com/playcanvas/engine/pull/6407
- [x] Legacy scripting system is being removed, as it has been deprecated in 2016, and has been in the read-only state for few years now. https://github.com/playcanvas/engine/pull/6584
- [x] Older deprecated functions providing backwards compatibility with replaced APIs will be mostly removed. #6690
- [x] Shapes: https://github.com/playcanvas/engine/pull/6691
- [x] HDR rendering: https://github.com/playcanvas/engine/pull/6702 and https://github.com/playcanvas/engine/pull/6714
- [ ] support for hardware sRGB textures: https://github.com/playcanvas/engine/issues/3715
- [x] remove support of Phong lighting by standard material, which is there for backwards compatibility only https://github.com/playcanvas/engine/pull/6755
- [x] remove the option to turn off energy conservation for materials (only there for backwards compatibility) https://github.com/playcanvas/engine/issues/4970
- [ ] Remove tint parameters from StandardMaterial, the tint is always applied: https://github.com/playcanvas/engine/pull/6759 https://github.com/playcanvas/engine/pull/6762
Changes that were discussed but are NOT changing in V2:
- model component - this is staying for a long time as it is used by many projects
- animation component - this is staying as it's still popular and widely used, even though the new anim component is more powerful
- detail maps - not exposed in the Editor, as we're aiming at better ways of exposing those custom shaders to the users, but useful currently
- json mesh format - keeping it, but will likely start deprecating it in the future
Changes that are still being discussed:
- parallax mapping support by the Standard Material - the implementation is very obsolete, and could be removed or better replaced by a more modern implementation
- more generic version of hardware instancing, as the current solution is simplistic and limited
- handling of the way canvas resizing is being handled
- deprecation of the PostEffects. Those will still work but the functionality will be in deprecated state
- https://github.com/playcanvas/engine/issues/6024
New major features in development for V2 only:
- WebGPU - This is already functioning pretty well in V1, but new features / polish / official support will only come to V2
- RenderPass based frame architecture. This has been in development for a while, and we're hoping to make this available for general use, including some new post-processing effects
- ESM scripts - modern javascript support using modules. Note that this will work together with the current scripting system, and both types work together without problems.
A bit surprised with the following:
- model component - this is staying for a long time as it is used by many projects
- animation component - this is staying as it's still popular and widely used, even though the new anim component is more powerful
- json mesh format - keeping it, but will likely start deprecating it in the future
This is probably the best time to remove these with a clean break and like WebGL1, those users can continue with v1.
This is probably the best time to remove these with a clean break and like WebGL1, those users can continue with v1.
There is so many projects using these, that removing them would force people with existing projects to stay on v1 for ever (or invest a lot of time moving to newer components), which is not ideal for the users (they want new tech), and also for us (we want most people to move to v2 and eventually when v1 is no longer needed, have a chance to remove it without much pain).
I agree with @yaustar. This will be the perfect moment to remove old components.
Especially new users don't know the difference between old and new components and the confusion will continue. The risk of users starting new projects with old components also remains, perhaps because they are easier to use in some ways.
If users want to use the new features they need to take some effort to make their projects future proof.
If there is a switch to a new system, removing model and animation components would be beneficial to engine indeed. Although there is a big difference when working with animation. Old system is way easier, and there are a few things that you can't do easily with a new system, e.g. changing animation speed per node or for a whole component. There should be at least a feature parity and preferably decent QoL improvements in Editor and code features for making users to switch.
Also, worth mentioning that now there are three scripting systems:
- Legacy Scripts - has been long deprecated, and easily can go.
- Scripts 2.0 - the current system, and definitely wont go for some time.
- ESM Scripts - a new and recommended scripting system.
Creating a project in Editor, by default would still recommend engine v1 with scripts 2.0. But if users use engine v2, then it would be beneficial to default to ESM scripts.
Through history, playcanvas engine never broke or forced changes, and provided backwards compatibility while introduced new alternative/better systems. This will be a new shift in the way things are done, and will lead to some docs, api, github, codebases and other segragations. Hopefully through better QoL of new systems and nice gradual migrations devs can more to v2 sooner than later.
Creating a project in Editor, by default would still recommend engine v1 with scripts 2.0. But if users use engine v2, then it would be beneficial to default to ESM scripts.
Yep exactly our plan, but we'll see how we go as we discuss it more.
The risk of users starting new projects with old components also remains
Yep, we'll definitely look at hiding some of the older tech in the Editor for newly created projects, as have in the past, but details are unclear at this stage.
I find the model component to be extremely convenient for props models. It provides a more streamlined appearance and takes up less space in the editor, making it easier to manage and organize assets.
Nice, looking forward for v2 🚀
One other change I would like to suggest is the refactor of the Texture API. There's an issue discussing that #4290.
What are the plans for the materials system, will there be master/instance materials?
Nice, looking forward for v2 🚀 One other change I would like to suggest is the refactor of the
TextureAPI. There's an issue discussing that #4290.
I think / hope we can do that one without breaking the API (perhaps by adding the API). We really want to avoid breaking too many APIs as that would make it harder for people to move larger projects to V2. But definitely on a TODO list.
What are the plans for the materials system, will there be master/instance materials?
There are no plans for this. We're still considering changing the API of the StandardMaterial, to simplify it a bit, a lots of changes under the hood in a way the shader then gets generated, but nothing regarding to what you suggest, even though I do see a value here. Please open a separate issue for it, it could be a good discussion.
This is probably the best time to remove these with a clean break and like WebGL1, those users can continue with v1.
Still using Model and Animation exclusively since Anim state machines are too overkill to set up for simple loop animations, and Render components don't work will old Animation components. I wish Anim would act / appear as an old Animation by default and then user could opt in to add extra states and complexity to it if needed.
Overall happy with the plan, can't wait for finalized HDR pipeline and render passes! And WebGPU compute shaders are going to open so many new possibilities. Would also vouch for better shadowing techniques (i.e. shadows become softer with distance from the occluder) and built-in standard postprocess passes (AO, DoF, TSAA, HDR + tonemapping, color grading, vignette, etc)
There is so many projects using these, that removing them would force people with existing projects to stay on v1 for ever (or invest a lot of time moving to newer components), which is not ideal for the users (they want new tech), and also for us (we want most people to move to v2 and eventually when v1 is no longer needed, have a chance to remove it without much pain).
Just adding my thoughts on this, particularly on the model component - I definitely agree with the above, having access to these components would allow us to migrate otherwise compatible projects to V2 without issue, since otherwise migration would be a very large task and would more than likely need a large development spend, for example on projects such as ones with lots of models utilizing vehicle physics using model components.
Perhaps it would be possible to hide these for users unless they want to specifically access them, so that new users don't use these to create projects, but older projects can still access them in V2, at least initially?
The rest of the plan seems great and I wish the team the best for the continued development of V2, can't wait to try it out.
Will 2.0 support
svgrendering?
v2.0.0 is largely about shipping breaking changes to the engine (e.g. removal of WebGL 1, AudioSourceComponent and more). There will be a small number of new features (e.g. render passes, ESM scripts), but that's secondary. Since we're making breaking changes, semantic versioning dictates that we must do a major version bump. Long way of me saying that SVG rendering isn't something that'll come with v2.0.0. Out of curiosity, what do you want to do with SVGs exactly, and is there already an open issue about what you need?
This has been added to the still being discussed list and unless objections are raised, this will most likely be done for V2.
https://github.com/playcanvas/engine/issues/6835
Out of curiosity, what do you want to do with SVGs exactly, and is there already an open issue about what you need?
For everything web related, all of our assets are svg. On our native iOS and Android apps, everything is svg. When building casual 2d games for the web, all of our assets are svg. PlayCanvas is one of the remaining fronts that doesn’t allow us to use our assets in their most ideal format.
- our dev team pays the small cost of conversion / optimization
- our users pay the small cost of larger game bundle sizes
Eventually it adds up.
If you are modernizing PlayCanvas with 2.0, we were curious if you were considering modernizing asset capabilities too.
@sjmueller OK, fair enough. So no, it's not part of 2.0, so I recommend opening an issue requesting this feature if it's something you need.