So I've looked into implementing other texture types in jME and it looks like it won't be all that hard (just some grunt work mostly) to add support for all four gl types. The catch is, the changes I need to make will force everyone to make a few changes to their code, and will possibly break any textures currently saved in .jme format. Because of this, I would like to get some feedback on WHEN the new texture support should go in. Should we release .12 jME first? Should we just do it and get it over with? I can't list all of the changes or estimate how much work it will be to comply with the new code, but I think it could be significant.
Thoughts?
There's a little more to it than that (eg. you have to support 3D texture coordinates, wrap mode system has to be changed). I did most of this already (except Cubemaps), except it still needs to be cleaned up and finished where needed (model loading indeed is one). The problem is I barely have time at the moment to post this message, because I first have to finish some work for Real Money™ here.
However I should have more time in about a month or so. And it is really nr. 1 on my list of things TODO for jME. It would have been done a long while back (I think I even posted "in about a week or two" if it weren't for the fact that in that week I got this job).
If you need this stuff right now, feel free to take it over (indeed, it's not that huge of a job, but lots of little things), but it does break a few things… so maybe it's best to wait till after .12
i'd say mail your code over to renanse as a first step. then check it in as soon as everything is working(all jme-tests comply and work with the new code)…i think these features outweigh the time it takes to make those changes to your code.
and why would regular 2d texture usage be that much different other than changing Texture to Texture2D etc?
@llama: Wrap modes, tex coordinates, etc. are exactly what I am talking about by grunt work. I'm not concerned about getting code for it, it's not that hard really. My concern is completely on legacy support.
@mrcoder: Porting code over probably will consist of switching to a per axis wrap (S/T) and renaming to Texture2D. That's not a big deal… What I am more concerned about is people like ncsoft, three rings or anyone else who might be using the binary format to store lots of game data already. Shifting the Texture classes around will likely break anything stored with a Texture object in it.
create deprecated delegates. it's ugly but you will be able to make the changes and they will most probably detect the deprecation warnings. you might also try to contact
them and ask/warn them 
edit: typos
first of all, great work! i know both mojo and renanse have been putting spare time into this, and it's a great thing… applause
secondly, my personal view only…i don't think we should focus that much on backwards compatibility if the gains from the new code is high enough(just code-clean wise or performance wise). the change which is killing old binaries are offcourse substantial for big productions, BUT, if not beeing totally stupid, they should not rely on the binaries and should have tools or easy ways of regenerating the binaries from the originals…also, upgrading to a new release or using the cvs version, is optional, and i believe most people are prepared that changes will have to happen…
again, only my personal view, and not a fact 
i agree to mr coder.
i think i didn't express myself correctly in my post above. i meant you should deprecate the "old" texture class and delegate all calls to the new one
Well it's grunt work mostly, but not just a tiny little bit… but hey if you have nothing better to do 
Some of it is design though… most escp. how you intend to provide data (2d texture != cubemap != 3d texture) for the different texture types (I choose to make the split in Image rather Texture after some experimenting)
As for breaking, it's gonna break eventually, and BinaryImporter will have the same problem still. Maybe some type of versioning should be added to it? It's not so bad if it breaks (dare I say, it's designed to break when your code breaks too ;)), as long as it gives a nice clean warning it's not so bad (rather than another 100 "Binary header doesn't match" threads)
Well, no big if you guys feel you have it covered, I don't have to work on this. I don't really need it myself at this point.
- renanse, pleeeeease do it or it won't happen!
- llama, do you think you will have time to finish the things you started?
Well don't get me wrong…
well then, lets set the deadline to "end of year", i don't think renanse really have the time to do this(even if he wants to).
it's not critical for me at least, even if i can see good use of cubemaps in just about every effect possible