Roadmap for 0.9.0

Engines, Libraries and Tools Xith3D Forums
#21

[quote="<MagicSpark.org [ BlueSky ]>,post:20,topic:28006"]
Qudus : How do I do if I want images to have correct width and height whatever the resolution ? I need that to implement more sophisticated buttons, defined by a image divided in 3x3 rectangles (see attached image). So that the background image isn’t distorted and everyone’s happy.
[/quote]
Should be possible with the getXithPixelSize() method of the WidgetContainer (HUD).

What about the height/2 thing in the Slider? Will you change that (or already have), or can I do that without causing CVS conflicts?

#22

[quote="<MagicSpark.org [ BlueSky ]>,post:9,topic:28006"]

  • CelShading : Well I forgot to commit when I posted this message. Look again, I now put again Java Cool Dude’s model it’s not working properly : outline is OK but white/gray shades are wrong… Goliat, any idea ? I compared with previous version and nothing has changed apparently…
    [/quote]
    sorry … haven’t followed this one
    that problem can’t be related to my stuff … the ‘old’ assembler style shader stuff that jcd is using there is totally unrelated to the ‘new’ glsl ones
    (at least i think so)
#23

I think, I’m having the problems that you had, Amos, when you were thinking, the Slider didn’t move. Sometimes it actually doesn’t move. I’ll trace, why this is like it is.

#24

[quote="<MagicSpark.org [ BlueSky ]>,post:20,topic:28006"]
Qudus : How do I do if I want images to have correct width and height whatever the resolution ? I need that to implement more sophisticated buttons, defined by a image divided in 3x3 rectangles (see attached image). So that the background image isn’t distorted and everyone’s happy.
[/quote]
Forget, what I said about getXithPixelSize()!!! I’ve just implemented two new methods in WidgetContainer named getEqualWidth(float), getEqualHeight(float).

Try this:


Widget w = new Image(100, hud.getEqualHeight(100), "mytex.png");
#25

I think, we should rename the Slider Widget to ScrollBar to stay as close to the Swing naming as we have with the other Widgets. What do you think?

#26

That’s ok.

#27

I traced the problem with the unprecise picking and scene cut…

Seems like there’s a problem in the JOGL implementation. When I create the Canvas3DWrapper by the Xith3DTestStarter the Window will have the exact size I chose and a instets of size xyz. When I create the Canvas3DWrapper directly in the main method of the HUD3DTest with exactly the same parameters, the window eill have a size of (chosen_size - insets) and the drawing area will have a size if (chosen_size - insets - insets). This behaviour is reproducable, but I can’t see how to avoid it.

Well, that’s why you’ll sometimes have scene cutting and unprecise picking. In fullscreen mode (undecorated windowed in JOGL) this roblem seems to never appear.

Deas anyone have an idea?

#28

So… another quite huge bunch of work is done:

  • We now have a WidgetContainerBase and a Panel.
  • The Slider is complete now and works great. But I still think, we should rename it to Scrollbar because of Swing naming similarity (before someone uses it).
  • The Slider is equipped with a listener now.
  • I’ve updated the HUD3DTest to demonstrate all this.

In the HUD3DTest I’ve linked a Panel and a Slider through a ScrollbarListener to scroll the Panel. An implementation of a “ScrollPanel” should be quite easy and streight foreward.

Now we desperately need clipping!!! How can we do this? Is stencil test the right tool for it?

Marvin

#29

Great ! You can rename Slider to Scrollbar, your’re right it’s clearer. For clipping yes stencil test would do the trick I think but hee it’s pretty complicated you have to :

  • Add a quad with transparency = 1 (invisible) and stencil function adjusted… properly ^^ Take a look a the StencilTest, it’s self-explanative. The thing I don’t know is how to do several level of stencil cause we need multiple clipping (panels on panels on panels,e tc…)
#30

Arggh stencil is a nightmare : I did thousands of tests and didn’t succeed into clipping properly these objects. I began to make a clipping function that takes a TriangleArray and two Point2f (topLeft, bottomRight) as arguments and return a clipped TriangleArray (not necessarily the same vertex count). It’s not finished yet, but I think it could be useable. I just hope it won’t be too slow.

#31

[quote="<MagicSpark.org [ BlueSky ]>,post:30,topic:28006"]
Arggh stencil is a nightmare : I did thousands of tests and didn’t succeed into clipping properly these objects. I began to make a clipping function that takes a TriangleArray and two Point2f (topLeft, bottomRight) as arguments and return a clipped TriangleArray (not necessarily the same vertex count). It’s not finished yet, but I think it could be useable. I just hope it won’t be too slow.
[/quote]
Wow, that’d be great. But wasn’t it more logical to take some kind of clip-quad as the clip-definer. Of course it’d be absolutely the same, but I think, it would be more clear to the user. There could be several constructors to define the clip-quad: two points, a point and a normal, etc… Of course one could reuse the clip-quad for each clipping operation.

#32

Wow, that’d be great. But wasn’t it more logical to take some kind of clip-quad as the clip-definer. Of course it’d be absolutely the same, but I think, it would be more clear to the user. There could be several constructors to define the clip-quad: two points, a point and a normal, etc… Of course one could reuse the clip-quad for each clipping operation.
[/quote]
Yeah of course it’s easy to do. I’ll do that.

#33

Hi,

you could use glScissors to do clipping on the GFX card.
The current scissor state can be saved with glPushAttrib(GL_SCISSOR_BIT)

Ciao Matthias

#34

Hmm… interesting… But this means a change in the renderer… Do you know how to integrate that ?

I’m afraid we should render UI a whole different way than traditional 3D scenes… Order is important.

#35

It’d be nice to have a callback from the renderer that gave you access to a glOrtho display so you could render simple UI using normal GL commands - this would of course be renderer dependent so a big sign saying “USE AT YOUR OWN RISK” should be applied.

It would however be amazingly useful and flexible.

Kev

#36

Mmyeah sure but say for our HUDwe don’t want to be renderer-dependant and anyway in “glOrtho” you have “gl”, what if someone implemented a DirectX renderer ? And aren’t displays handled differently by JOGL and LWJGL ? Which means different classes, and run-time type detection (and cast) and alt that stuff. Pheww not easy.

#37

I’ve updated the HUD in the following points:

  • The Button can take 9 images now
  • The GTK-Button is much nicer now
  • Added a Border Widget
  • The Border- and Button Widget each have an inner class called ButtonDescription / BorderDescription. They’re used to first describe the Button or Border easily and then create a new Button or Border Widget passing this BorderDescription instance to the constructor. This has to be done for the Scrollbar Widget, too. Would you do that, Amos? I don’t know, if I have too much time, the next days.
  • Improved the WidgetTheme to support the new features
  • Added a class named WidgetZIndexGroup. It can logically group some Widgets to set the last clicked Widget in the group the group-local-maximum-z-index.
  • Added an easy mechanism to link a Panel and a Scrollbar < scrollbar.link(panel1) >
  • Added many, many constructors to take Tuple2f intead of (width, height).
  • Fixed some bugs

Marvin

EDIT: Maybe someone could draw / find :wink: a nicer border texture than I used in the HUD3DTest.

#38
  • Fixed the SwingOverlayTest : it works again, and fast, besides !
#39

No, I don’t think it has to be like that. The thing thats passed back could be a OrthoContext on which you can call some small subset of the commands you need to draw 2D images. Then within Xith the context could be handled however the renderer desires. Just seems way more flexible than all this pushing 3D into 2D to me.

But, since I’m not will to contribute the code myself, I’ll just shut up now :slight_smile:

Kev

#40

No please don’t shut up it’s really interesting. What commands would be needed in OrthoContext (and BTW why not contribute ?)