I wouldn’t say it was tough, jME already uses an unshaded material for rendering NiftyGUI Elements so I just added in a means to change that material.
I added in ImageMaterialRenderer and MaterialRenderer classes to Nifty and modified the Element class with methods to add/remove these renderers with materials and textures. I also modified the RenderDevice interface and RenderDeviceJme with methods that allow the new renderers to set a custom material on the RenderDevice and then swap it back to default when the Element is done rendering.
I also happened to notice that the rendering of nine part resize images seemed rather inefficient. Nine part images are split up into nine sections so they can be stretched only in certain areas, my game makes extensive use of nine part resizing. Anyway I noticed that jME renders each of the nine parts independently of one another with a quad, so each Nifty Element using a nine part resizing scheme for drawing the texture requires nine draw calls.
I went ahead and added in a new 16 vertex Mesh and use that for drawing nine part images with a single draw call. I had to modify the NinePartResizeRenderStrategy class in Nifty with a new class to pass to RenderDeviceJme so that all of the information was present for the new Mesh, NinePartQuad, to modify UV coordinates and vertex positions for each Element.
Anyway I’ll add in some comments, build the libraries and post up a link later tonight. Possibly tomorrow, I have to ride my bike out to the post office to return some bad RAM to NewEgg tonight, stupid restocking fee
I created a new thread linked below with a link to a zip file containing the new libraries, source code and documentation that way if anyone has questions or concerns I can address them in that thread. Happy monkeying
Thanks for sharing! Would be cool if someone could integrate that code into the original jME / nifty project or even into other GUI libraries. Otherwise it’s a fork and maybe not so easy to maintain.
The screen shots I posted above feature a five pass render for nifty elements. Each element has five materials attached to it. Blur vertical, horizontal, vertical, horizontal then overlay the texture.
Well, in the end, every Lemur GUI element is just a stack of GuiComponents and they can literally do whatever they want. The built in ones all create standard Geometry + Mesh (OrTbtQuad similar to your Nine patch thing) and use materials created by GuiGlobals. But really you can have any GuiComponent you want, it just has to implement the sizing and reshape methods.
I haven’t done a tutorial on custom components yet but you can read what there is here if you are ever curious:
But for example, a Lemur Label is just an empty Node… it’s the stack of GuiComponents that give it its geometry and stuff.
I’m sure I’ll give Lemur a try with a future project. I only went with Nifty this time around because it’s my first jME project and thought I’d stick with the default UI package.
Fail of the day:
There is no way to run away when something goes completely wrong while changing how density field is passed to Marching Cubes mesh generator :chimpanzee_closedlaugh:
Notice anything different? Heh, not a whole lot visually, I just finished ripping out NiftyGUI 1.3.3 and sewing in NiftyGUI 1.4.1.
The main benefit of this, for me, was a bug in 1.3.3 that was fixed in 1.4. In 1.3 clipping didn’t work on an element if any of the parent elements were clipped so in the shot above you can see I was finally able to get rid of those ugly black bars in the mini-map button area that were there to hide the fact that the map itself wasn’t clipped
I didn’t have to rework a whole lot of my code, just tooltips and ListPanels, apparently 1.4 no longer allows setting the scrollposition immediately after building an element, so I had to delay it a bit.
I completely revised my sector map system, much better now IMO. So when you want to travel to another star system you open this view that shows all of the sorounding systems (the names are currently just poorly generated placeholders and the risk level is tied to the enemy spawn rate):
So then you just point your ship at the system you’d like to go to and hit warp. The system registers that you have the map open and sends you to the system instead of engaging local slow warp.
And possibly the sort of final version of the tier 1 engine models:
Would be cool if someone could integrate that code into the original jME / nifty project or even into other GUI libraries. Otherwise it’s a fork and maybe not so easy to maintain.
