Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

UI/UX - Device types and Engine version #1147

Open
kpal81xd opened this issue Apr 24, 2024 · 13 comments
Open

UI/UX - Device types and Engine version #1147

kpal81xd opened this issue Apr 24, 2024 · 13 comments
Assignees
Labels
area: editor interface area: launch tab feature request requires: discussion It isn't clear what needs to be done requires: ux Requires UX advice, design or input

Comments

@kpal81xd
Copy link

kpal81xd commented Apr 24, 2024

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

image

The launcher has two flags which are non persistent that can be used to override the project settings for quick testing in the launcher

image

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.

image

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.

image

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

@yaustar
Copy link
Contributor

yaustar commented Apr 24, 2024

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 😅

@Maksims
Copy link

Maksims commented Apr 25, 2024

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.

@kpal81xd
Copy link
Author

kpal81xd commented Apr 25, 2024

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

@mvaligursky
Copy link

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.

@Maksims
Copy link

Maksims commented Apr 25, 2024

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

@kpal81xd
Copy link
Author

kpal81xd commented May 8, 2024

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

@willeastcott
Copy link
Contributor

I would drop the .0 from the WebGL names for brevity.

@marklundin
Copy link
Member

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.

@kpal81xd
Copy link
Author

kpal81xd commented May 9, 2024

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

@mvaligursky
Copy link

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

@kpal81xd
Copy link
Author

kpal81xd commented May 9, 2024

@mvaligursky So by default both are set with the ordering implied?

@mvaligursky
Copy link

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.

@kpal81xd
Copy link
Author

kpal81xd commented May 9, 2024

Okay sounds good ill add those and then for the launcher is the proposed submenu for device better?

@kpal81xd kpal81xd changed the title DeviceTypes UI/UX UI/UX - DeviceTypes and Engine version May 16, 2024
@kpal81xd kpal81xd added the requires: discussion It isn't clear what needs to be done label May 16, 2024
@kpal81xd kpal81xd changed the title UI/UX - DeviceTypes and Engine version UI/UX - Device types and Engine version May 16, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area: editor interface area: launch tab feature request requires: discussion It isn't clear what needs to be done requires: ux Requires UX advice, design or input
Projects
None yet
Development

No branches or pull requests

6 participants