[Lemur] Coordinates

Troubleshooting gui
1

After falling trap to too many misunderstandings with that, here’s my best effort at a writeup how Lemur handles coordinates.
Corrections, gross misunderstanding cleanup etc. vastly appreciated. (This is mostly towards @pspeed.)
I phrased this as a Javadoc for Panel so it can be patched in if it happens to be correct.

[java]/**

  • A GUI element.
  • <p>
  • Its local translation determines the position of its top-left corner.<br>
  • Its visible area extends to the right (positive X coordinates) and down
  • (negative Y coordinates).<br>
  • The layout code for {@code Panel}s assume that rotation and scale are at
  • their default values.
  • @author Paul Speed
    */[/java]
2

I think this is good. I may add something about all three axes since it’s only the Y axis that behaves “strangely”.

It seemed a reasonable compromise between a +y up world and UIs that want to be +y down.

3

By the way, thanks for helping with this stuff.

4

You’re welcome :slight_smile:
… anyway, doing what I can to give where I received.

On the choice of coordinate system: I think it’s the best approach to seamlessly mix GUI components and scenegraph elements. I see some situations where that can help, e.g. when displaying equipment models inside the GUI, or when displaying a GUI on an in-game panel. Of course that’s always possible, but I think it’s conceptually easier by a lot if the GUI simply uses the same coordinate system.
Oh. You don’t want to (ab)use the Z coordinate if the GUI is on an in-game object, since players can then look at it from an angle and the Z order becomes visible. So you’ll want to sort explicitly. (Not an immediate concern to me anyway, just something to look out for if I ever place a Lemur display inside a scenegraph.)

5
<cite>@toolforger said:</cite> You're welcome :-) ... anyway, doing what I can to give where I received.

On the choice of coordinate system: I think it’s the best approach to seamlessly mix GUI components and scenegraph elements. I see some situations where that can help, e.g. when displaying equipment models inside the GUI, or when displaying a GUI on an in-game panel. Of course that’s always possible, but I think it’s conceptually easier by a lot if the GUI simply uses the same coordinate system.
Oh. You don’t want to (ab)use the Z coordinate if the GUI is on an in-game object, since players can then look at it from an angle and the Z order becomes visible. So you’ll want to sort explicitly. (Not an immediate concern to me anyway, just something to look out for if I ever place a Lemur display inside a scenegraph.)

Lemur elements need not be “flat”… so in a real 3D scene then I’d expect objects to be solid/3d things. In Mythruna, I have flat pages that move around but the camera angle is relatively fixed so that you don’t see the layering if you look at it edge-on.

Sorting can already be done explicitly with the “layer” user data but it won’t fix z-buffer issues… so things still need to be offset slightly not to z-fight.

Edit: and note… for the crafting “mini games” that I will add later, those will be real 3D objects in 3D space. It’s nice that I can keep using the same UI classes, though.

6

Very small Z distances it would be then…

7

Note: I did finally kind of update the docs of this class just now.

Full Panel.java javadoc as of this last commit:
[java]
/**

  • A panel is the most basic GUI element consisting only

  • of a background and insets. This is a convenient base class

  • for every other GUI element as it sets up the proper relationships

  • between Node, a GuiControl, and style attributes.

  • “Panels” are often thought about in 2D terms but the

  • Lemur default Panel is not limited to 2D. It’s behavior depends

  • entirely on the background component, which could be a simple

  • 2D quad using a QuadComponent or something more complicated that

  • is fully 3D.

  • By default, Lemur GUI elements are setup so that their local

  • translation determines the position of their top-left corner in

  • x/y space. In other words, the y-axis acts a little differently

  • than other axes in that it grows down instead of up. Within

  • an element, the coordinate system is still the standard JME

  • coordinate system. It’s just how the elements are are arranged

  • relative to their own local translation that is different. This

  • makes multi-element layouts more sensible or consistent with other

  • GUI libraries.

  • Note: the layout code currently assumes that rotation and

  • scale are their default values.

[/java]

May not go far enough but hopefully it helps others who run afoul of similar confusion.

8

Also note, our lovely forum has decided to interpret the paragraph markers literally and I can’t be bother to hand-encode them.

9

Sorry for being silent for so long, I’ve been sidetracked by another project.
It will take me a few more weeks, but I’ll be back.

10

No worries. Side-tracks have a way of stacking up anyway.