@normen said:The bad thing is these GUIs cannot be edited if you are not the programmer. If you're not like Paul and don't do *everything* yourself its much better to edit external description files. So its kind of normal it instantly appeals to programmers but without that feature its definitely nothing for the core engine, so nobody needs to worry about his nifty guis :)
Lately I found more and more that the main point of the SDK (collaboration) is still its strongest point It was very possible to edit gui and sound files in an external project. In a jME project was created with another IDE it was the pain!
Though I never used it, I do agree that the XML defines where a cool aspect of Nifty. I had three major qualms with Nifty (and some of these may have changed… /shrug)
Lack of mouse input support (I spent days almost in tears when something in JME would change and my custom mouse support would break again)
Lack of consist naming conventions for common methods.(without documentation, this one drove me to abandon all controls past Labels and Panels and build an entire library of controls just using these)
The number of hoops you have to go through to a) Get something working in Nifty and then b) Get what you have working in Nifty to play nice with JME.
@normen said: The bad thing is these GUIs cannot be edited if you are not the programmer. If you're not like Paul and don't do *everything* yourself its much better to edit external description files. So its kind of normal it instantly appeals to programmers but without that feature its definitely nothing for the core engine, so nobody needs to worry about his nifty guis :)
Lately I found more and more that the main point of the SDK (collaboration) is still its strongest point It was very possible to edit gui and sound files in an external project. In a jME project was created with another IDE it was the pain!
A GUI nifty builder would definitely be a big win for nifty. Hand editing the XML for nifty is not much different than coding, though. Between the way styles interact and how you have to be thinking of the object code to make attributes work, it’s some of the most complicated kind of XML to edit. Not like just messing with HTML. And I found it trivial to get to the point where the SDK preview didn’t work anymore. I really think you already have to have a programmer’s mind to edit nifty XML.
@yang71 said: But, yes... I would be glad to test this new menu framework. Reinventing wheel is not that good! And your work seems very well thought & built.
Every thing I read in this thread makes the waiting more difficult! Thanks for this!!!
Just a note: the “menuing” script that I presented above is specific to Mythruna. Though it really wasn’t hard to write the groovy layer to do it. It also has its own internal abstraction.
I may write a small groovy wrapper as a separate plug-in because it is pretty convenient and would bridge the “I’d rather have an external config for my UI” gap a bit.
Oh, and since this GUI is just JME objects, you could theoretically use it to make 3D GUIs right in the scene editor… once app state support is added to the editor. Given that, I guess it wouldn’t be a big step to add some kind of ortho scene view to the scene editor to support 2D gui building.
@yang71 said: Hum... Sorry, may be a bit tired, but I stopped undestanding...
the “menuing” script that I presented above is specific to Mythruna"
And then, you speak about a separate plugin, integration in the SDK editor, and so on…
Do you think your system will be usable for new projects, or not ?
In the first or second post in this thread, I described the different pieces that are at work here. There is the base layer with things like Button, Label, etc. that are built right on top of JME classes. This is the part I plan to release. There is a mythruna-specific bit that lets me script my menus in groovy. I don’t plan to release that since it’s Mythruna-specific… but I may still write a simpler groovy wrapper as a separate plugin.
@pspeed Can I pick your brain for sec? This inspired me to try a bit of this just to see whats involved and I was pleasantly surprised at how easy it was to put together an element that handles different mouse states, drag/drop and resizing. What really peaked my interest was the ability to use lighting, shaders and particle emitters as part of the GUI.
So, given that I spent a total of 30 minutes playing with this and aside from being extremely pleased with how easy it would be to put something usable together… I came across a few things I’m not sure what to do with.
Using JME’s ActionListener and Analog Listener, how would one stifle events from filter down to objects lower in the z-order? Or are you using a different event system?
Have you gotten as far as implementing clipping layers? And what approach did you (or were you planning on) using? Haven’t really given this any thought yet… but would love to hear what approach you were considering!
One aspect of Nifty that I liked (though, I hate the implementation because I could never remember what order the info was supposed to be entered) was the 9 part resizing. I gave that a bit of thought and came up with about 6 different approaches to handling this. How are you handling the image portion resize events?
This last one is semi-related… where can I read up on JME’s vertex group support? And does it require meshes with an associated skeleton? I’d like to try implementing 4-corner-drag resizing using a 3d mesh and it would be a heck of a lot easy if I could just define vert groups on the imported model and go from there. If not… I guess I could use a simple custom mesh and track indexes.
Anyways… you know you have done a good thing when you inspire other people to try it as well! I’m really impressed!!
@t0neg0d said: @pspeed Can I pick your brain for sec? This inspired me to try a bit of this just to see whats involved and I was pleasantly surprised at how easy it was to put together an element that handles different mouse states, drag/drop and resizing. What really peaked my interest was the ability to use lighting, shaders and particle emitters as part of the GUI.
So, given that I spent a total of 30 minutes playing with this and aside from being extremely pleased with how easy it would be to put something usable together… I came across a few things I’m not sure what to do with.
Using JME’s ActionListener and Analog Listener, how would one stifle events from filter down to objects lower in the z-order? Or are you using a different event system?
I use a raw input listener that casts a ray into a list of scene roots… viewports basically. It detects whether to treat it as ortho or perspective and does the appropriate thing. It delivers the events in closest to farthest order, stopping if the event is consumed. I also track which spatial has the “capture” and deliver that information as part of the events and make sure to continue delivering mouse motion events and button release events to the captured control even if the mouse is not over it.
This is code I’ve been using for a while. It has no external dependencies and is one app state, one control, and an event listener interface. I could probably just post them separately.
2. Have you gotten as far as implementing clipping layers? And what approach did you (or were you planning on) using? Haven't really given this any thought yet... but would love to hear what approach you were considering!
I have found no good way to do clipping layers in JME. The Nifty gets to use open GL clipping but JME doesn’t expose that to us. So none of my UIs need it. In Mythruna for some of my existing UIs, I’ve cheated by giving my gui bucket depth (hacked JME) and then do some z-buffer tricks for clipping.
3. One aspect of Nifty that I liked (though, I hate the implementation because I could never remember what order the info was supposed to be entered) was the 9 part resizing. I gave that a bit of thought and came up with about 6 different approaches to handling this. How are you handling the image portion resize events?
You mean the way you can have a 3x3 grid image and stretch it nicely, leaving the sides the same size and only stretching the center?
Yeah, I have a TbtQuad (Three-by-three quad) that acts like a regular quad except that it has 9 squares and handles texture coordinates in a way that allows the above. At least a subset of it. I used it for the borders in the menu stuff I’ve posted. The same border around the giant Mythruna is the same one used around the slider ranges, is the same one used around the button and frames. It’s a small square texture with a hand-drawn-looking box at the edge.
Again, that class is completely independent of anything else so I could probably just post it.
4. This last one is semi-related... where can I read up on JME's vertex group support? And does it require meshes with an associated skeleton? I'd like to try implementing 4-corner-drag resizing using a 3d mesh and it would be a heck of a lot easy if I could just define vert groups on the imported model and go from there. If not... I guess I could use a simple custom mesh and track indexes.
I’ve never looked at any of that and it doesn’t have much to do with a GUI to me, either. GUIs tend to have layouts and so on… child components must move and/or resize as their parent resizes, etc… and that’s sort of part the layout functionality already.
@nehon said: idk since that's JME objects, and controls and so it could be edited like any other j3o.
Same basically, creating a j3o isn't much different from compiling. Sure, that counts for scenes and models too then but there is a reason its not Java but AJAX :)
I don't want to diss this as its certainly useful for many people but @pspeed is eloquent enough to display the advantages of his system, so I'll just remind of the larger context, apart from lone programmers ;)
I use a raw input listener that casts a ray into a list of scene roots… viewports basically. It detects whether to treat it as ortho or perspective and does the appropriate thing. It delivers the events in closest to farthest order, stopping if the event is consumed. I also track which spatial has the “capture” and deliver that information as part of the events and make sure to continue delivering mouse motion events and button release events to the captured control even if the mouse is not over it.
This is code I’ve been using for a while. It has no external dependencies and is one app state, one control, and an event listener interface. I could probably just post them separately.
Ray casting + raw input listener… awesome idea for how to handle this!
@pspeed said:
I have found no good way to do clipping layers in JME. The Nifty gets to use open GL clipping but JME doesn't expose that to us. So none of my UIs need it. In Mythruna for some of my existing UIs, I've cheated by giving my gui bucket depth (hacked JME) and then do some z-buffer tricks for clipping.
One thought for this, though it is essentially a bad hack, it would give basic functionality for scrolling… is to scroll by height of object. It wouldn’t be the prettiest solution, but would work for dropdowns and text areas.
@pspeed said:
You mean the way you can have a 3x3 grid image and stretch it nicely, leaving the sides the same size and only stretching the center?
Yeah, I have a TbtQuad (Three-by-three quad) that acts like a regular quad except that it has 9 squares and handles texture coordinates in a way that allows the above. At least a subset of it. I used it for the borders in the menu stuff I’ve posted. The same border around the giant Mythruna is the same one used around the slider ranges, is the same one used around the button and frames. It’s a small square texture with a hand-drawn-looking box at the edge.
Again, that class is completely independent of anything else so I could probably just post it.
This was the exact idea I had… and what led me to the question of vertex groups and more complex 3d objects for displaying panels.
Thanks for such detailed responses!
One final question… are you strictly using recursive calls for updating children objects for events like resize & dragging? Or are you mixing this with the encapsulation of spatials?
i.e. recursive notification allows for updating resize events… which can get as specific as… I resize from the NW corner of a panel… childX is set to only resize in width, not height…etc, etc, blah blah. On the other hand, a drag event doesn’t really have the need to notify it’s children if all positions are relative to their encapsulation. --hope this made sense.
@normen said: There is a *huge* difference between code and description files, lol. Starts at compiling the code to change the UI ;)
I don’t have to compile code to change my GUI. It’s only three lines of code to run something in groovy… and that includes giving the Application as a binding. And at this point, the nifty XML is a bunch more complicated than code. So far it seems like the real nifty users build their UIs in code anyway.
@pspeed said:
One final question... are you strictly using recursive calls for updating children objects for events like resize & dragging? Or are you mixing this with the encapsulation of spatials?
i.e. recursive notification allows for updating resize events… which can get as specific as… I resize from the NW corner of a panel… childX is set to only resize in width, not height…etc, etc, blah blah. On the other hand, a drag event doesn’t really have the need to notify it’s children if all positions are relative to their encapsulation. --hope this made sense.
When a top level component is resized then it lays itself out again… so all of the children get potentially relayed out and resized, etc… they control what size they end up as basically. If something about a child changes then it invalidates the tree forcing some parent to lay itself out again. It’s very much like swing, actually.
I don’t know if that answers your question or not.
@normen said: There is a *huge* difference between code and description files, lol. Starts at compiling the code to change the UI ;)
I don’t have to compile code to change my GUI. It’s only three lines of code to run something in groovy… and that includes giving the Application as a binding. And at this point, the nifty XML is a bunch more complicated than code. So far it seems like the real nifty users build their UIs in code anyway.
Also, as mentioned before, since these are just regular JME objects then you can theoretically already edit GUIs right in the scene editor. It would just be easier with some additional facilities added.
@normen said: There is a *huge* difference between code and description files, lol. Starts at compiling the code to change the UI ;)
I don’t have to compile code to change my GUI. It’s only three lines of code to run something in groovy… and that includes giving the Application as a binding. And at this point, the nifty XML is a bunch more complicated than code. So far it seems like the real nifty users build their UIs in code anyway.
@normen said: There is a *huge* difference between code and description files, lol. Starts at compiling the code to change the UI ;)
I don’t have to compile code to change my GUI. It’s only three lines of code to run something in groovy… and that includes giving the Application as a binding. And at this point, the nifty XML is a bunch more complicated than code. So far it seems like the real nifty users build their UIs in code anyway.
Also, as mentioned before, since these are just regular JME objects then you can theoretically already edit GUIs right in the scene editor. It would just be easier with some additional facilities added.
@nehon said: idk since that's JME objects, and controls and so it could be edited like any other j3o.
Same basically, creating a j3o isn't much different from compiling. Sure, that counts for scenes and models too then but there is a reason its not Java but AJAX :)
I don't want to diss this as its certainly useful for many people but @pspeed is eloquent enough to display the advantages of his system, so I'll just remind of the larger context, apart from lone programmers ;)
@pspeed Ya know… clipping could be handled by a custom shader. It would just need a vec4 - clip layer x,y,w,h and vec4 - current layer x,y,w,h, the discard any pixel outside the clipping area. Not sure how that would effect the ray casting however.
EDIT: What am I saying! You could just give us access to OpenGL clipping! /hint /hint … you know… while you’re working on instancing /hint /hint /hint
The problem with custom shaders is that unless you do it as some kind of second pass, you can’t just clip something that’s rendered. That rendered thing would have to know it is being clipped. So in my case, both lighting and unshaded would have to be aware of some kind of clipping rectangle. Also, if your shader was otherwise shared then now you need to split it across different sets of clipped objects.
These are surmountable problems… just not at all convenient. And JME-nifty will break without clipping… though it’s stateless nature at least makes setting clipping rectangles in a shader more feasible.
This kind of thing makes me (again) wish for per-spatial uniforms that inherit down the tree. In-shader clipping would be a snap in that case. I suppose it could be emulated with a control, custom user data, and an extra scene graph pass… ie: all in user code. I do a similar thing to manage sorting layers already.
In ortho projection, when there is still depth, you can also simulate clipping by filling the z-buffer with the current layer except where you want things rendered. I was doing this by drawing transparent inverse quads. Some update in JME broke this and now I have to use a really alpha instead of 0… otherwise the inverse quad doesn’t get drawn at all.
In my new UIs, I will handle clipping at the object level… basically only drawing things if they can be fully seen. So text entry clips at the character boundry and list boxes clip at the row boundary. It’s functional enough, hardly noticeable, and 1000x easier.
I’m a bit confused, I’m not sure of what you mean by “clipping” here? could one of you explain?
I thought you guys were talking about a clipping rectangle on screen (for UI), and Normen is talking about an arbitrary clip plane in a scene.
If that’s rendering into a sub part of the screen in a rectangle that you want… that’s a viewport .
We do support this kind of clipping (if I get it correctly)
It was very possible to edit gui and sound files in an external project. In a jME project was created with another IDE it was the pain!
