Java-Gaming.org Hi !
Featured games (91)
games approved by the League of Dukes
Games in Showcase (798)
Games in Android Showcase (234)
games submitted by our members
Games in WIP (865)
games currently in development
News: Read the Java Gaming Resources, or peek at the official Java tutorials
 
    Home     Help   Search   Login   Register   
Pages: [1]
  ignore  |  Print  
  TextureIO Flipping Out??  (Read 7977 times)
0 Members and 1 Guest are viewing this topic.
Offline Andrew Davison

Junior Devvie


Medals: 2



« Posted 2007-02-06 03:50:28 »

I've just been testing my OBJ file loader with JSR-231 RC 2, and the texturing started going 'wrong'.

It seems that the latest version of TextureIO is flipping the loaded images around their y-axis, which is messing up my rendering code. This didn't happen back in the December version of JOGL.

I'm not sure if this is a 'problem', but it's certainly an inconvenience. Would it be possible to expose a 'doFlip' flag in TextureIO's newTexture() methods to turn the flipping on/off?

- Andrew

Dr. Andrew Davison
Dept. of Computer Engineering
Prince of Songkla University, Hat Yai
Songkhla 90112, Thailand
Offline Ken Russell

JGO Coder




Java games rock!


« Reply #1 - Posted 2007-02-06 05:23:01 »

This was an intentional change to BufferedImage-based textures loaded via TextureIO and is highlighted in the 1.1.0-rc2 release notes posted on this thread. This change enabled the introduction of one of the new Texture.updateSubImage() APIs and the new Java 2D interoperability helper classes, including the TextureRenderer and TextRenderer. Correct code using TextureIO should have been using either the Texture.getImageTexCoords() or Texture.getSubImageTexCoords() APIs, or paying attention to the return value of Texture.getMustFlipVertically(). I'm sorry this change affected you, but you're going to have to update your code. The efficiency gains from not flipping the contents of BufferedImage-based textures far outweigh the downsides.
Offline Andrew Davison

Junior Devvie


Medals: 2



« Reply #2 - Posted 2007-02-06 06:48:39 »


My loader reads the texture coordinates from an OBJ file, which was generated by a graphics app. Those coordinates are specified as if the image isn't flipped.

What I'm concerned about is why things use to work in my loader, but now don't. It seems like the texture image I'm using wasn't flipped in the December version of JOGL, but now is. That's a backward compatibility issue that could affect lots of people (?).

Also, I thought that flipping was an optional feature. For example, it's exposed in some of the TextureData() constructors. Couldn't that be made visible via TextureIO as well?

- Andrew

Dr. Andrew Davison
Dept. of Computer Engineering
Prince of Songkla University, Hat Yai
Songkhla 90112, Thailand
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline Ken Russell

JGO Coder




Java games rock!


« Reply #3 - Posted 2007-02-06 16:46:05 »

My loader reads the texture coordinates from an OBJ file, which was generated by a graphics app. Those coordinates are specified as if the image isn't flipped.

In order to use these texture coordinates correctly with the TextureIO classes, you need to feed them through the Texture.getSubImageTexCoords() methods. I'm assuming the graphics application generates (s, t) coordinates from [0..1]. Depending on whether the image has power-of-two dimensions or not, the TextureIO classes may, for example, use the GL_ARB_texture_rectangle extension, in which case the texture coordinates to display the entire texture go from (0, 0) to (image width - 1, image height - 1). The getImageTexCoords() and getSubImageTexCoords() methods abstract away this difference. Your loader should always have been doing this transformation.

What I'm concerned about is why things use to work in my loader, but now don't. It seems like the texture image I'm using wasn't flipped in the December version of JOGL, but now is. That's a backward compatibility issue that could affect lots of people (?).

It is a change in behavior, but one which should not affect correctly written code according to the previous API definitions.

Also, I thought that flipping was an optional feature. For example, it's exposed in some of the TextureData() constructors. Couldn't that be made visible via TextureIO as well?

The "vertical flip" bit is an indicator to the end user whether the texture coordinates need to be flipped vertically in order to display the image in upright orientation via OpenGL. It is intended to abstract away differences in image file formats where some supply the image data from the bottom up and some from the top down. As a convenience to the end user, we used to manually flip the image data in BufferedImages before transferring them to OpenGL textures, but we stopped doing this in 1.1.0-rc2 because it introduced large inefficiencies when trying to update sub-portions of textures on the fly. There's no way to reasonably support an "override" bit telling the TextureIO implementation to manually flip image data vertically -- this doesn't work for many image formats.
Offline jladdison

Junior Newbie





« Reply #4 - Posted 2007-02-08 03:15:03 »

I am having a similar problem. Is there some place that clearly explains how to use these functions to get the texture coordinates in situations where they are pre calculated separately from the image.

Also, in the mean time is there a webstart link that will give us the RC1 version that does not flip the textures? If I use:

<extension name="jogl" href="http://download.java.net/media/jogl/builds/archive/jsr-231-webstart-current/jogl.jnlp" />

it gives me RC2 which flips all my textures. If I use:

<extension name="jogl" href="http://download.java.net/media/jogl/builds/archive/jsr-231-1.0.0/jogl.jnlp" />

it gives me 1,0 which crashes with certain versions of the JRE. I would normally use the stable release version, but in this case it is not stable (I understand the problem is  in the JRE and not JOGL, so I am not criticizing JOGL for this problem)

I have to deliver a webstart demo tomorrow, of the product we have been working on for the past year that is now effectively broken. It works with RC1 but I am not sure how to include that in webstart without a link to it. I can modify my code later, but this will take quite awhile (unless there is an easy fix that I am missing) .

Thanks,

Jeff

Offline Ken Russell

JGO Coder




Java games rock!


« Reply #5 - Posted 2007-02-08 07:32:57 »

I am having a similar problem. Is there some place that clearly explains how to use these functions to get the texture coordinates in situations where they are pre calculated separately from the image.

Please see the javadoc for Texture.getSubImageTexCoords(). We've tried to make it clear but I have to admit we don't have any concrete examples in the jogl-demos workspace using this API, though the new TextureRenderer in the jogl workspace does use it. We do have a demo using getImageTexCoords() however. If you have pre-computed texture coordinates (typically ranging from 0 to 1) then what you need to do is for each one, multiply it by the width and height to get the texel x and y you're talking about, and then feed that into getSubImageTexCoords(). You can feed in (0, 0) as the lower-left corner of the sub-image and only use the resulting TextureCoords' right() and top() values for the rescaled coordinates.

Also, in the mean time is there a webstart link that will give us the RC1 version that does not flip the textures?

Please use

<extension name="jogl" href="http://download.java.net/media/jogl/builds/archive/jsr-231-1.1.0-rc1/webstart/jogl.jnlp">

Sorry for the last minute trouble.
Offline jladdison

Junior Newbie





« Reply #6 - Posted 2007-02-09 19:03:25 »

Cool. Thanks Ken.  The demo was a success.

Thanks for your help. I did not really understand exactly how the getSubImageTexCoords function worked from the javadoc, but your description above made everything click. I get it now.

Thanks for all your dedication and hard work. It is greatly appreciated.
 
Jeff
Offline Koen Samyn

Senior Newbie





« Reply #7 - Posted 2007-03-01 10:27:05 »

I still have a problem with this for cubemaps.   Huh

Koen

Offline Ken Russell

JGO Coder




Java games rock!


« Reply #8 - Posted 2007-03-01 17:19:40 »

Could you please be more concrete and supply a test case showing what the problem is?

Are you sure you can't solve this by putting in a matrix somewhere along the line which flips the space vertically, and swapping the top and bottom faces of the cubemap?
Offline Koen Samyn

Senior Newbie





« Reply #9 - Posted 2007-03-02 07:43:05 »

The problem was that uvw coordinates are used for cubemaps. I solved it for now by swapping the positive & negative faces of the entire cubemap (it was a procedural texture anyway so that doesn't matter much).

Thx for the hint.  Wink

Koen

Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline Koen Samyn

Senior Newbie





« Reply #10 - Posted 2007-03-02 10:32:31 »

Would it be possible to change the method getSubImageTexCoords, so we can feed it with a TextureCoords object ?

For example :

TextureCoords loopTC = new TextureCoords();
while (moreUVsToProcess){
int p1x = ...
int p1y = ...
texture.getSubImageTexCoords(p1x,p1y,p1x,p1y,loopTC);
// write back the new texture coordinates
}


Offline quintesse

Junior Devvie




Java games rock!


« Reply #11 - Posted 2007-03-02 13:37:22 »

I can't speak for Ken of course, but I can tell you that what you want goes against the advise given by various very knowledgeable people like to author of Effective Java.

Chapter 13 of Effective Java "Favor immutability" for example tells you to use value-objects wherever possible. It gives a bunch of advantages for using them, besides the most obvious disadvantages of course: the need to make a copy each time you need a different value.

The TextureCoords class does not adhere completely to the rules though because it's methods are not final, to be a true immutable objects they should be. So somebody should probably decide which way to go: either go for full immutability or make it easily mutable by default.
Offline Koen Samyn

Senior Newbie





« Reply #12 - Posted 2007-03-02 13:52:48 »

I am aware of the advantages of Immutable objects.

However in this case, a lot of very temporary objects are created. In all cases the reference to the object will only exist inside the loop that transforms the textures coordinates.

An alternative solution would be to add a batch processing method like this :

calculateSubImageTexCoords(float[] uvs);
&
calculateSubImageTexCoords(FloatBuffer uvs);

Koen

Offline Ken Russell

JGO Coder




Java games rock!


« Reply #13 - Posted 2007-03-02 16:43:04 »

I'm facing this problem in another context and I think I'm going to solve it by setting up a texture matrix. That would also save you from having to mutate your texture coordinates. Would that approach work better? You can compute the values that have to go into the texture matrix from the various parameters of the Texture object (look at the implementation of getSubImageTexCoords for pointers).
Offline Koen Samyn

Senior Newbie





« Reply #14 - Posted 2007-03-02 17:16:01 »

Quote
I'm facing this problem in another context and I think I'm going to solve it by setting up a texture matrix. That would also save you from having to mutate your texture coordinates. Would that approach work better? You can compute the values that have to go into the texture matrix from the various parameters of the Texture object (look at the implementation of getSubImageTexCoords for pointers).

A matrix would be the best solution (wish I thought of it Smiley, it's the simplest and cleanest solution.

Koen

Pages: [1]
  ignore  |  Print  
 
 

 
Riven (45 views)
2019-09-04 15:33:17

hadezbladez (4025 views)
2018-11-16 13:46:03

hadezbladez (1468 views)
2018-11-16 13:41:33

hadezbladez (4048 views)
2018-11-16 13:35:35

hadezbladez (780 views)
2018-11-16 13:32:03

EgonOlsen (4098 views)
2018-06-10 19:43:48

EgonOlsen (4685 views)
2018-06-10 19:43:44

EgonOlsen (2762 views)
2018-06-10 19:43:20

DesertCoockie (3657 views)
2018-05-13 18:23:11

nelsongames (3867 views)
2018-04-24 18:15:36
Java Gaming Resources
by philfrei
2019-05-14 16:15:13

Deployment and Packaging
by philfrei
2019-05-08 15:15:36

Deployment and Packaging
by philfrei
2019-05-08 15:13:34

Deployment and Packaging
by philfrei
2019-02-17 20:25:53

Deployment and Packaging
by mudlee
2018-08-22 18:09:50

Java Gaming Resources
by gouessej
2018-08-22 08:19:41

Deployment and Packaging
by gouessej
2018-08-22 08:04:08

Deployment and Packaging
by gouessej
2018-08-22 08:03:45
java-gaming.org is not responsible for the content posted by its members, including references to external websites, and other references that may or may not have a relation with our primarily gaming and game production oriented community. inquiries and complaints can be sent via email to the info‑account of the company managing the website of java‑gaming.org
Powered by MySQL Powered by PHP Powered by SMF 1.1.18 | SMF © 2013, Simple Machines | Managed by Enhanced Four Valid XHTML 1.0! Valid CSS!