playcanvas
UI/UX - Device types and Engine version
This issue is to be used for discussing a cleaner and more informative device type management and editor engine version.
Device types
Current solution
The current state is as follows with an ordered multi select for the project device types which is project scoped
The launcher has two flags which are non persistent that can be used to override the project settings for quick testing in the launcher
Proposed solution
The ordering for project device types seems unnecessary as you would never want to fallback from an older device to a new one (eg. WebGL1 to WebGL2 or WebGPU). We can define the order as WebGPU -> WebGL2 -> WebGL1 -> Null with each arrow denoting the next device to fallback to. The user can then choose which devices to enable with two toggles Enable WebGPU and Enable WebGL2. With both of these disabled the graphics device will fallback to WebGL1 on the old engine and NullDevice otherwise.
For the launcher itself the two choices Prefer WebGL1 and Prefer WebGPU options will be replaced by a Launch Device option which branches off to a submenu of radio buttons one for each device. The default device selected will match the project setting on load but can be changed here to affect which device is used for the launcher.
Engine Version
Given the devices shown now depend on the engine version this should be modified as such. The engine versions will now be displayed as follows:
- beta (release candidate)
- stable (current stable release)
- previous stable (last stable release)
These versions will force update the user to use those versions relative to the current stable release. This with the exception of previous stable which would cause the user to be doubly force updated to the latest stable engine. As such better UI is required to signifiy the current engine version you are on, when there was a force engine update and which version it was updated from (maybe do not need the last part).
The main difference is one is for project settings. This affects the build and other users on the project.
The launcher options just affect your launch tab. This allows you do things like test the app under WebGL 1 (for compatibility/you get get a bug report) without changing the project data itself.
Having a single option between WebGL 1 / 2 / WebGPU makes sense. The launcher tickboxes were probably stacked for ease at the time while WebGPU support was still considered 'beta'. It made sense when we just had WebGL 1 and 2 😅
One option with highest GAPI is the way to go. With easy way to force a specific GAPI for testing purposes in Launcher. Need to have apparent UX and some UI to ensure developer is clearly aware of forced GAPI to prevent accidental frustration of forgetting an option there. Also would be great to highlight an force option in Editor if it is supported or not.
Although there is a scenario where developer wants to support only WebGPU, and not WebGL, and would need a nice solution to provide UI to user in such case.
Handling app launching without ending up with barrage of exceptions.
One option with highest GAPI is the way to go. With easy way to force a specific GAPI for testing purposes in Launcher. Need to have apparent UX and some UI to ensure developer is clearly aware of forced GAPI to prevent accidental frustration of forgetting an option there. Also would be great to highlight an force option in Editor if it is supported or not.
Although there is a scenario where developer wants to support only WebGPU, and not WebGL, and would need a nice solution to provide UI to user in such case.
Handling app launching without ending up with barrage of exceptions.
Yes I agree the launcher force option should be clear that its an override of the existing project device settings.
With regards to the setting WebGPU I mean the way createGraphicsDevice works itll fall back to WebGL if failing WebGPU even if not directly specified because otherwise theres nothing to render with. I guess I can just overlay with a splash screen saying WebGPU required or something along those lines
We could add an noFallback option to createGraphicsDevice in which case it would only try and create a device from the provided list. We could also add a NullGraphicsDevice as the ultimate fallback, so the app would still work but the user can detect the type and inform the user.
Providing UI to the user that no GAPI is available should be down to the user with probably default behaviour (if not provided by user) with very minimal UI by the engine (not an alert please).
Okay so ive added some UI examples for the proposed UI/UX. The one area that isnt covered yet is setting a device without wanting to fallback e.g. WebGPU. In that case I was thinking of adding a Disable Graphics Device Fallback toggle in project settings to handle that case
The launcher override makes sense, but users should be able to explicitly set the the fallback where necessary. As @Maksims mentioned, they may only want to support WebGPU and we shouldn't force fallback to WebGL.
The launcher override makes sense, but users should be able to explicitly set the the fallback where necessary. As @Maksims mentioned, they may only want to support WebGPU and we shouldn't force fallback to WebGL.
Yea thats why having a disable fallback flag will be useful
Maybe we need to go a similar way to what I've suggested for the examples. In the Editor settings, have two options:
- Enable WebGPU
- Enable WebGL
That will dictate where in this chain we'll start using the devices: WebGPU -> WebGL2 -> WebGL1->Null
I guess the default would be Enable WebGL only. WebGPU would be opt on for now. But when we're out of beta with it, we could by default enable both of them.
Okay sounds good ill add those and then for the launcher is the proposed submenu for device better?