I’ve modified the jME3-core, jME3-niftygui and nifty libraries used by jMonkeyEngine3.0 to allow for the use of custom materials on any NiftyGUI element. You can download these new libraries along with documentation and source code here: jME3_CustomNiftyMaterials.zip - Google Drive
Using these libraries is pretty straightforward, just remove the jME3-core.jar, jME3-niftygui.jar and nifty.jar libraries from your project and replace them with the three libraries included in the above download, jME3-core_CustomNiftyMaterials.jar, jME3-niftygui_CustomMaterials.jar and nifty_CustomMaterials.jar and you’re set to start writing your own NiftyGUI materials.
Basic usage is also quite simple, once you’ve loaded your NiftyGUI Element, be it a panel, button or any other Nifty Element, just obtain a reference to the Element, such as with Element.findElementByName(“MyElement”) and call Element.setImageMaterial(Material) or Element.setPlainMaterial(Material).
There are several other methods and such so I encourage you to check out the included README file and documentation. Specifically I would check out the documention for the NiftyGUI de.lessvoid.nifty.elements.Element, the de.lessvoid.nifty.elements.render.ImageMaterialRenderer and de.lessvoid.nifty.elements.render.MaterialRenderer classes.
It should be noted that if you want to use nine-part resizing for the textures on the material you’ll need to use the ImageMaterialRenderer and associated Element.setImageMaterial(Material) or Element.setImageMaterials(List) methods. To use this you must ensure that the Element you are applying the material to already has an image set through the XML image attribute or via the backgroundImage() method through ElementBuilder before you call one of the setImageMaterial methods otherwise a MaterialRenderer will be used.
I didn’t really have to put it in the core package, but I did just to keep things organized properly. I modified the way nifty nine-part images were drawn.
In the original release nine-part images were drawn nine times using a single quad for each part. I added a sixteen vertex mesh used to draw those images just once and placed that mesh in the com.jme3.scene.shape package. It’s the NinePartQuad
Instead of modifying the UV coordinates of and drawing a single quad nine times for each nine-part image I just modify the UV coordinates and vertex positions of and draw the NinePartQuad once for each nine-part image.
So the only addition to the core package is the NinePartQuad.
That makes it harder for anyone using your code since now they won’t be able to upgrade regular JME which changes way more frequently than Nifty. Just saying.
I don’t think the 3.0 libraries are going to be updated anymore so anyone using this with 3.0 probably won’t run into that issue. This probably won’t work with 3.1 since 3.1 uses NiftyGUI 1.4 and 3.0 uses Nifty 1.3.3.
I haven’t looked at the 1.4 source, but I imagine if one were to want this functionality in jME 3.1 it’d need to be rewritten for Nifty 1.4 anyway.
I was kinda hoping jME 3.1 might support Nifty 2.0, but it looks like Nifty 2.0 development is moving along at a slower pace and wouldn’t be production ready by the time jME 3.1 is.
Going forward, JME will be publishing maven-style artifacts to jcenter soon. At that point, it’s possible that nifty could evolve at a different pace.
I understand why you did things the way you did but still, if you hadn’t required the jme3-core change it’s possible that your stuff would work fine with 3.1 and the even the older nifty. Not sure.
Nifty 1.3 might work with jME 3.1, haven’t looked at the 3.1 sources, but even still I don’t think anyone would want to downgrade to Nifty 1.3 just for this.
I’ll download the Nifty 1.4 source and jME 3.1 source tonight or tomorrow and see about making a download available for 3.1 users. I’ll be sure to stick the NinePartQuad in the jME-niftygui package
Okay I updated the original post with a link to the jME 3.1 Alpha 1 version and I did move the NinePartQuad to the jME3.1-niftygui package
I have NOT tested this as I do not have jME 3.1 Alpha 1 installed. Moreover I used Eclipse to build the jars rather than Gradle so I’m only pretty sure that I put all the necessary resources in the right places. If anyone wants to test this and let me know if it works…
Actually it was probably a lot faster. My connection tops out at 75KiB/s, but usually sees about 30-50KiB/s.
According to DNF, Fedora, installing Gradle would be about 108MB, so probably fourty minutes to an hour, plus apparently the dependency libraries are no longer included with the zipped jME source download and are instead downloaded by Gradle while compiling so…
Now my mobile connection is 4g up to 2GB per month, but apparently T-Mobile found a way to throttle it when tethering to a computer because starting earlier this month when doing so my laptop only sees 15KiB/s while downloading the same on my phone sees 1MiB/s.
So I downloaded the Nifty and jME sources on my phone and transferred them, but obviously I could not do that with Gradle through DNF or with the dependency libraries through Gradle.
For any who were using the jME-3.1 package of this I have uploaded a new version at the same link. While the original works when running your game through the SDK, an error prevents your application from compiling when using build or clean and build.
Apparently this is due to a bug in java when compiling a class that contains an enum with certain types of annotations using Eclipse or Intellij. A bad signature is generated and this is the error you’ll get when building with the SDK. 388314 – @javax.annotation.Nonnull triggers bug in javac
I re-compiled nifty1.4.1-CustomMaterials.jar with ANT and I am no longer encountering the error myself.
