Experiemental: Game GUIs

[Hoikas]

This adds EXPERIMENTAL support for Game GUIs to Korman. Currently, only baseline modal GUI dialogs are supported with simple GUI buttons. All other functionality will come later after we let this experimental set of functionality soak a bit. Disclaimer: experimental means that I retain the right to change, add, remove, or break functionality without regard to backwards compatibility.

Here's how it works in general... An artist will create a GUI Page in the Plasma Age panel containing any objects they want to appear in their GUI. The GUI Dialog Modifier optionally accepts a camera that looks at the GUI. If this is not specified, Korman will automatically generate a camera that fills a 4:3 screen with the GUI. The direction the camera faces is determined by calculating the area-weighted normal of all GUI polygons and inverting it. If the artist wants, they can click on the camera operator button on the GUI Dialog Modifier to generate the camera in the scene and tweak the result from there.

In the interest of ease of use, a new Note Popup Modifier has been added. This modifier is not experimental and is guaranteed to remain stable. This will automatically show a popup GUI and provide appropriate click-off geometry like Cyan's standard popup GUIs. Like full-fat GUIs, all GUI objects are expected to be placed in a GUI page. Then, the Note Popup Modifier is applied to an object in a standard Room Page and specifies the GUI Page of interest.

Feedback welcome at this time.

Note Popup Modifier Sample

[DoobesURU]

Not sure why my last comment didn't post (I'll just chalk it up to me being "busy" and accidentally closing the tab before I actually posted). I actually found a few potential gotchas with GUIs while I was working with them yesterday.

1. Not sure if this is just because of one of the other issues I found, but having a Visibility Set tied to an object in a GUI Page seems to cause the client to crash.
2. This isn't consistent as Varia used them, but flat planes as clickables may also be causing client crash.
3. This one I can definitely confirm: if a GUI camera on one PRP/page is used, but the mod's "GUI Page" references another GUI PRP...crash! Alternately, this might be when a GUI page is referenced twice, once each in two or more separate objects.

Anyway, I hope this helps (and posts this time!). :D

[Deledrius]

Here's what I've found so far, experimenting with the GUI Popup modifier:

• When using my own camera, adjusting the PlasmaCameraProperties FOV appears to have no effect. I have to use the Blender Render FOV option. This still doesn't allow me to adjust the aspect ratio, so my popup appears squished.
• The "Clickable" option can't be the clickable object itself, as the object needs to be in the GUI page and the clickable modifier must be in a room page. This was unclear (and using the in-world object as the visual works fine, as long as the "Clickable" is a separate mesh/region).
• The auto-created camera is not enabled as a Plasma Object, and is not assigned to any page. Additionally, it appears to be under my clickable facing its backside (but I suspect this will always be a best-guess no matter what).

[dpogue]

• The auto-created camera is not enabled as a Plasma Object, and is not assigned to any page. Additionally, it appears to be under my clickable facing its backside (but I suspect this will always be a best-guess no matter what).

GUI camera transform are weird and I remember when I was playing around with them in pyprp that I had to do things like face the camera away and upside down from what I wanted to be visible.

[Deledrius]

GUI camera transform are weird and I remember when I was playing around with them in pyprp that I had to do things like face the camera away and upside down from what I wanted to be visible.

Indeed, in this case however, my pre-created camera is facing the object properly and works fine. The auto-created camera is underneath the object facing its backside (from behind another object, no less). Rotating it 180° around the Y so it faces the object properly makes it work. So this isn't an instance of the camera transform being wonky, I think it's just the heuristic for how to determine what to face doesn't like my single-face page (the normals are correct, I checked). In-game is matching the Blender camera fine. It's just generating the wrong camera.

Edit: Looks like this is mostly user-error; I included more than just the visual object in the GUI page (such as the Clickable Region) and this threw off the calculation. The camera is facing the correct way when the visual object is the only thing in the GUI page. It might be useful to warn if this is happening, but I'm not sure there's a good way to detect it given all of the stuff one might put in a complex GUI dialog.

[Hoikas]

This one I can definitely confirm: if a GUI camera on one PRP/page is used, but the mod's "GUI Page" references another GUI PRP...crash! Alternately, this might be when a GUI page is referenced twice, once each in two or more separate objects.

I am having trouble following this and may need a sample blend file.

When using my own camera, adjusting the PlasmaCameraProperties FOV appears to have no effect. I have to use the Blender Render FOV option. This still doesn't allow me to adjust the aspect ratio, so my popup appears squished.

Working as intended. The Plasma camera properties FOV won't actually change the FOV of the camera in Blender's viewport, so you need to switch to Blender Render mode and adjust the angle of the camera. A future pull request will nuke Korman's misleading FOV option and replace it with the Blender option. For now, work within this limitation.

The "Clickable" option can't be the clickable object itself, as the object needs to be in the GUI page and the clickable modifier must be in a room page. This was unclear (and using the in-world object as the visual works fine, as long as the "Clickable" is a separate mesh/region).

Working as intended, clickables are part of the room page, not the GUI page. This will be one of those RTM moments 😉

The auto-created camera is not enabled as a Plasma Object, and is not assigned to any page.

Working as intended. The GUI camera should never be a Plasma Object.

Additionally, it appears to be under my clickable facing its backside (but I suspect this will always be a best-guess no matter what).

and

GUI camera transform are weird and I remember when I was playing around with them in pyprp that I had to do things like face the camera away and upside down from what I wanted to be visible.

The Blender camera is supposed to face the GUI so that you can view your GUI from inside Blender itself.

Looks like this is mostly user-error; I included more than just the visual object in the GUI page (such as the Clickable Region) and this threw off the calculation. The camera is facing the correct way when the visual object is the only thing in the GUI page. It might be useful to warn if this is happening, but I'm not sure there's a good way to detect it given all of the stuff one might put in a complex GUI dialog.

I'm not sure how we can realistically detect such a thing. The code is supposed to reject any objects that aren't visible, but there's still nothing preventing stray visual objects from throwing the calculation off. Even if we did somehow detect that some weird objects got in, how do we know which ones are good and which ones are bad? As I say IRL, all technology is an "idiot box" it only does what you tell it 🤣

[Deledrius]

When using my own camera, adjusting the PlasmaCameraProperties FOV appears to have no effect. I have to use the Blender Render FOV option. This still doesn't allow me to adjust the aspect ratio, so my popup appears squished.

Working as intended. The Plasma camera properties FOV won't actually change the FOV of the camera in Blender's viewport, so you need to switch to Blender Render mode and adjust the angle of the camera. A future pull request will nuke Korman's misleading FOV option and replace it with the Blender option. For now, work within this limitation.

👍🏼 Sounds good.

The "Clickable" option can't be the clickable object itself, as the object needs to be in the GUI page and the clickable modifier must be in a room page. This was unclear (and using the in-world object as the visual works fine, as long as the "Clickable" is a separate mesh/region).

Working as intended, clickables are part of the room page, not the GUI page. This will be one of those RTM moments 😉

Yup, I think it's a question of getting the right wording. I interpreted "the object the player will click on" differently. It's hard to be general here (since GUIs can be so many different things) without losing important specificity.

The auto-created camera is not enabled as a Plasma Object, and is not assigned to any page.

Working as intended. The GUI camera should never be a Plasma Object.

User error (it was still improperly placed when I tested this). Never test multiple variables at once, kids!

The Blender camera is supposed to face the GUI so that you can view your GUI from inside Blender itself.

👍🏼 I'm really glad. This works great.

Looks like this is mostly user-error; I included more than just the visual object in the GUI page (such as the Clickable Region) and this threw off the calculation. The camera is facing the correct way when the visual object is the only thing in the GUI page. It might be useful to warn if this is happening, but I'm not sure there's a good way to detect it given all of the stuff one might put in a complex GUI dialog.

I'm not sure how we can realistically detect such a thing. The code is supposed to reject any objects that aren't visible, but there's still nothing preventing stray visual objects from throwing the calculation off. Even if we did somehow detect that some weird objects got in, how do we know which ones are good and which ones are bad? As I say IRL, all technology is an "idiot box" it only does what you tell it 🤣

True. We can probably only detect extreme cases, and even then, who knows?

[Hoikas]

After some discussion with @DoobesURU, "the best feature is DONE" - merging. We'll deal with any fallout at a later time.