Any time soon?
This is on a list.
Yuri
dear santa . ;D …sorry got lost for a sec…my vote for this feature as well
[quote]dear santa . ;D …sorry got lost for a sec…my vote for this feature as well
[/quote]
;D
/me is f**** happy to announce that he’s got TextureCubeMap working 
Demo coming up soon
now that is great news - this woke me up from my prolonged post-Xmas-hibernation …good stuff JCD!
Texture CubeMap (yay):
http://www.users.xith.org/JavaCoolDude/JWS/Xith3D/TextureCubeMap/texturecubemap.jpg
Mouse: left drag for rotation.
Keys: S to switch NORMAL_MAP and REFLECTION_MAP
Source
If you’ve been using OpenGL long enough you’d notice that the default texture coordinates generation through the NORMAL_MAP extension works the way it should.
However a hit on the S key would switch to REFLECTION_MAP and reveal a rather mysterious bug where the Textures are upside down ???
Now I have no clue on why this is happening and I’m defintely turning to Yuri asking for help on this one.
PS: Here’s a Java3D version that shows the correct result
Link
[quote]Texture CubeMap (yay):
and reveal a rather mysterious bug where the Textures are upside down ???
[/quote]
I don’t know the reason but it remembers me to the thing you’ve to do when going the direct OpenGL way via JOGL: once you’ve loaded a PNG texture (for example) into a BufferedImage you’ve to flip it vertically and then give it to Jogl (because OpenGL has another Y-origin then PNGs).
In Xith you don’t have to flip the BufferedImage because it’s a nice blackbox and does it for us, I think.
Maybe there’s something similar with your Xith extension for this nice demo?
Tried that and I didn’t get the same result than what’s being rendered in Java3D…
Besides how come NORMAL_MAP work just fine and not REFLECTION_MAP ?
I just committed changes that include support for TextureCubeMap. I also got strange behavior, so I would ask JCD to check his demo against current implementation to ensure that we are working on the same codebase.
Yuri
Tried the new libs from the CVS and all hell broke loose at once:
TextureCubeMap is completely screwed now here’s a pic
http://www.users.xith.org/JavaCoolDude/Pictures/screwed.JPG
There was nothing wrong in the version I sent you, the only bug was in the showcase demo where I set the format to RGBA whereas my textures were of RGB type!!!.
As you can see from how the TextureCubeMap webstart demo is running, the NORMAL_MAP texcoord generation works to perfection as I can confirm the result is correct running the equivalent Java3D demo.
However once we switch to REFLECTION_MAP by typing the ‘S’ key, the textures appear to be in an incorrect orientation/location.
I also need to mention that I modified the ImageComponent2D class in such a way that it does actually flip the images upside down at submission time using
g.drawImage(image,0,0,dest.getWidth(),dest.getHeight(),
0,dest.getHeight(),dest.getWidth(),0, null);
located at “public void set(BufferedImage image)”
Here’s a demo running in Java3D that I wrote and should show you the targeted result
J3D
X3D
Finally while you at it, could check if the way I added the DOT 3 extension to TextureShaderPeer is apropriate for a CVS submission?
Cheers
Hi,
DOT3 extension is already in CVS.
[quote]I also need to mention that I modified the ImageComponent2D class in such a way that it does actually flip the images upside down at submission time
[/quote]
With TextureCubeMap, in my tests I manually flipped images vertically, so mapping itself was working as in your demo. BTW, there is some problem with background, and I notice exactly the same behavior as you have.
I plan to continue on this today.
Yuri
Issue with wrong background for this demo fixed. Problems were because of interference of new texture type addition (texture cube map) and recent changes of multitexturing processing.
Issue with vertical flipping of textures in cube map has not been investigated yet.
Yuri
Well, here are some explanations:
-
yUp parameter is currently ignored by ImageComponent2D, and default value of yUp for OpenGL is true (looks like Java3D has default for yUp = false). Xith3D currently does not try to change this setting, so we have to provide textures y-up way (i.e. flip them vertically comparing to Java3D textures requiren yUp=false). Hack modification that flips textures in ImageComponent2D is not OK, because of it breaks compatibility with all previous Xith3D code that uses textures.
-
As of Reflection Maps. Unlike of Normal Maps, it is not enough to just set tex coord generation mode to GL_REFLECTION_MAP_EXT. OpenGL uses eye coordinates for R, and Cube map needs reflection vector in world (where map was created), so additionally it is neccessary to load texture matrix with inverse 3x3 view matrix. Current infrastructure of ShapeAtom does not provide easy, fast and direct access to View matrix, and there are several options how to do this. I will check this issue later today.
Yuri
Wow I never thought I’ll ever go back to using simple JoGL to see how things work out on the low level side.
So I coded this simple demo that shows how the extension TEXTURE_CUBE_MAP works in OpenGL with REFLECTION_MAP and NORMAL_MAP…
Use left, right, up, down to rotate and S to switch generation mode:
Link
Perfect example.
This code really helped to figure out what was wrong in the code.
The reason was really interesting and not-so-easy to figure out, because of it comes to the very very very old code that was working perfectly since very first version of Xith3D.
Previous version of Xith3D was combining View transform (which you typically define with view.getTransform().lookAt(…), aka camera transform) with Projection matrix to speed up transform settings a bit, so all subsequent transforms had no need to know about it at all.
As opposite, JCD’s JOGL-based demo uses only gluPerspective(…) to set Projection transform, so TexCoordGeneration is working OK here.
I had to re-engineer related parts of code in Xith3D to make View transform a part of MODELVIEW matrix, and this fixed a problem with Reflection Maps.
Fixed code committed to CVS, so TextureCubeMaps should work perfectly now.
Yuri