Engine 2.0.0 (Root ticket)

[mvaligursky]

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_v1 branch.
• V2: This version is contained in the main branch. 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:

• WebGL1 is getting removed, and only WebGL2 and WebGPU is supported. If your project still requires WebGL1, you will need to stay on V1.
• The AudioSourceComponent is removed as it has been replaced by the SoundComponent a long time ago. [BREAKING] Remove deprecated AudioSourceComponent component #6407
• 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. [BREAKING] Remove support for legacy scripts #6584
• Older deprecated functions providing backwards compatibility with replaced APIs will be mostly removed. [BREAKING] Initial cleanup of deprecated functionality #6690
• Shapes: [BREAKING] BoundingBox and OrientedBox copy parameters in the constructor #6691
• HDR rendering: [BREAKING] Changes to the HDR rendering #6702 and [BREAKING] Colors of lights, fog and materials are always supplied in sRGB space, for both LDR and HDR #6714
• support for hardware sRGB textures: Use gamma textures format (WebGl2) #3715
• support for hardware sRGB framebuffers: Support for sRGB framebuffer on WebGPU #6838
• remove support of Phong lighting by standard material, which is there for backwards compatibility only [BREAKING] Remove long time deprecated PHONG specular model #6755
• remove the option to turn off energy conservation for materials (only there for backwards compatibility) Remove energy conservation flag in standard material #4970
• Remove tint parameters from StandardMaterial, the tint is always applied:
  • [BREAKING] Remove StandardMaterial.diffuseTint and simply always apply it #6759
  • [BREAKING] Remove StandardMaterial.emissiveTint and simply always apply it  #6762
  • [BREAKING] Remove StandardMaterial.ambientTint #6805
  • [BREAKING] Remove StandardMaterial.sheenTint #6809
  • Remove opacityTint internal flag #6812
  • specularTint & specularityFactorTint
  • [BREAKING] Remove StandardMaterial.sheenGlossTint #6841
• Remove XrDepthSensing
• more generic version of hardware instancing, as the current solution is simplistic and limited [BREAKING] More general instancing #6867 and [BREAKING] Instancing no longer ignores the model matrix #6883
• replacement for the BasicMaterial Remove BasicMaterial and allow better ways to create custom shaders using ShaderMaterial #6835 [BREAKING] BasicMaterial has been deleted #6857
• [BREAKING] Remove support for Layer.renderTarget and some callbacks on the Layer #6888

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
• 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
• Create DrawHelper module in extras for more advanced 'debug' style rendering #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.

Small changes:

• Expose intensity of the Ambient Occlusion on the StandardMaterial #6866 was added to the engine and should be exposed in the Editor: Expose StandardMaterial.ao in the Inspector editor#1180
• [BREAKING] Remove no longer needed drawTexture #6886
• [BREAKING] Adjusted the alpha part of the normal blend used by the Materials #6889
• [BREAKING] Skydome shader chunk changes + updates to FirstPerson example #6991

[marklundin]

#6666 ticket of the beast 🤘

[yaustar]

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.

[mvaligursky]

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).

[albertvanveen]

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.

[Maksims]

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.

[mvaligursky]

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.

[mvaligursky]

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.

[SashaRX]

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.

[heretique]

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.

[SashaRX]

What are the plans for the materials system, will there be master/instance materials?

[mvaligursky]

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.

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.

[mvaligursky]

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.

[cognitiveplus]

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.

[cognitiveplus]

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)

[renegadels]

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.

[sjmueller]

Will 2.0 support svg rendering?

[willeastcott]

Will 2.0 support svg rendering?

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?

[mvaligursky]

This has been added to the still being discussed list and unless objections are raised, this will most likely be done for V2.
#6835

[sjmueller]

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.

[willeastcott]

@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.

[mvaligursky]

Closing as all done to level we're happy with at this stage.