I know there are some old posts about this pertaining to jme3, but no final answer on it’s use. Has anyone ever managed to “port” TWL to make it compatible with jME3? (While still allowing the use of shaders - not using shaders isn’t an option for me.)
Okay, so given the current state of jME, what would the (known) challenges be in making TWL compatible? And would the general strategy be to modify (contribute to) jME to accommodate TWL, or to modify (branch) TWL to accommodate jME?
Twl modify to fit jme and contibute I suppose, however this will be really difficult since twl directly modifes the states opengl uses, wich is kinda against all jme principles. I tried once but failed, i wish you more luck tho.
TWL allows you to write a graphics renderer implementation. A skilled Java programmer could take a look at how the Nifty GUI renderer for jME3 was built and then take the learned lessons and apply them to construct a TWL renderer.
So, it sounds like you’d need to be fairly good w/Nifty anyway. In that case, and also in light of what Empire said above, it might make more sense to simply contribute to Nifty’s improvement. But is NiftyGUI maintained by the “jME team” or an outside group (and simply compatible with jME)? It seems to be a separate ‘project’.
Nifty is a separate project. There is a layer where JME implements the necessary interfaces for Nifty to “paint” to JME. It’s these interfaces and their implementation that you’d have to look to for inspiration when porting TWL… assuming their “plug-in” rendering interface was similar.
I don’t think you’d necessarily have to understand much about nifty to do that.
Okay - so does anyone think it’d be worth doing? (port TWL) I’m not saying I’ll commit to attempting anything at this point but this could be a potential “next” project I suppose - if people think it’s worth doing.
@EmpirePhoenix - When you tried this before did you use the strategy the others are describing here?