Is there cube map support?

Hey i was looking around the jme source code, and i didn't see any cube mapping support, is there any? I thought i saw it when i noticed "setEnviromentalMode()" but that only has support for linear and sphere mapping… so i'm assuming there is no cube mapping support in JME yet?

No, and that's kinda my fault… I had it almost ready at some point and then (to this day) have had no time to finish it. At one point renanse even offered to do it…


well, then, if I'm able to come up with anything… I'll see if its jme community worthy…



Would it be smart to have the Texture class also support cube maps textures… or was there something else in mind?



edit: well from looking alot more into the jme, i'm kinda lost on how to implement cubemapping to jme, since everything seems to use2d textures. Should there be a cube map object, that holds the cube map, and a node specified. Then the cube map object gives a 2d texture that can be mapped onto that node?

Yes, the support I was working on included different Texture types (3D/1D/rect aside from Cubemap) and made them updateable as well. In my I made different types of the “Image” class (Image3D, CubemapImage, etc), but the same could be done for the Texture class (matter of taste I guess).



Unfortunatly I don’t even have the code anymore, except on an IDE hard disk (and currently I only own only a laptop). It’s not incredibly much work or anything, I just feel stupid though for telling Renanse to wait for my implementation :’(

Yikes llama, you seem to be talking about a complete overhaul of the system… :frowning:



What if i made a cube map class that extended texture… i'm not sure how much sense that would make… i'm trying to find the best way for jme to handle cubemapping…



also it makes a lot of sense to make cube maps updateable…



how much sense would it make to create the cube map object as an object that could be added to a texture state, but not something that extended texture, since cube maps and textures work so differently? Or would it just make more sense all together to just have the cubemap object, and have it specify a 2d texture that is basically a culmination of the sides of the cube and can be applied to an node…? sigh so many ways to skin a cat

Cubemaps, 3d textures and all of that will be important features to have, but as I've already had my hand slapped once for trying to add features now that we are in release candidate mode I'll suggest we brainstorm on this for post 1.0.  Personally I like keeping all texture derivatives logically together in some way, so I like llama's approach at first glance… but I also think that if we put together a few ways to approach it, the best one will float to the top.

fair enough renanse, its just that it seems funny that there isn't any support for textures other than 2D :frowning:

So i'll just have to implement my own hacky method until 1.0 rolls around?



And llama's approach does seem to be the best, the idea of having different texture types all extended a main abstract 'image' type class would be good way to get things done while keeping everything pretty simple.



guess i'll just wait around for 1.0 :slight_smile:

Personally I found it less work to extend Image (after making it abstract) rather than texture.



It makes no sense for CubeMap to extend Texture (as it is), basically that's saying that Cubemap is an extention of a 2D texture… (which afaik it's not).



What I was further working on is making an "ImageBuffer" as a proper class of it's own, that could handle updates to the texture (A CubeMapImage would naturally contain several of these). This was still in the very experimental phase though.

i think we should make Texture an abstract base class and have extensions Texture1D-3D and TextureCube

yes, MrCoder!  :smiley:

Additionally to splitting up Image or instead of?



Splitting it from "AbstractTexture" would mean either having double code for a lot of methods (eg texture translation) or having not much unique code at all (all the "texture type dependent" code is mostly in TextureState after all). I suppose you could split up only Texture, and let TextureCube have several Images or something?



To me a Texture is a texure, with a type attribute, that's determined by the type of data (the kind of Image you put in).



Sure, you can set some different parameters for different types, by which you could split up Texture into different subclasses, though to me the split is hard to make. What methods would be different between Texture1D, Texture2D and Texture3D?



Also, let's not forget RectTexture :slight_smile:

Hmm llama brings up an good point.

A texture in jme should be anything opengl assigns a texture unit for, whether it be 1d texture, 2d texture, 3d, or cube map. So with that said i think that there should be an abstract Texture class that is implemented by GL_TEXTURE_1D, GL_TEXTURE_2D, GL_TEXTURE_3D, or GL_TEXTURE_CUBE_MAP. Now i would think that Texture class would have a good amount of meat to it, since all of the textures do have a WHOLE LOT in common. (i doubt that anyone could debate other wise). And all of the subclasses would have very little specific code, probably for parameters, like llama said.



The reason that i think that each texture type should have its own class is because the three are all used very differently, and texture-type specific methods could be added easily. Also i can't imagine any case where a 1D texture could be used interchangeably with a 2d or cube map texture, and visa-versa. Having them all be of the same class could become in an issue. Also having all of the different types of a textures would mean that the Texture class representing a 2D texture would have methods that are meant for 3D textures and such, which could cause also cause confusion.



Then, having each type be in a seperate class extending texture allows cube maps to be handled easily, even though they act so differently from the rest of the texture types.



gasp ok, i think that's all i have to say for now… phew