TextureRenderer usage question

OpenGL Development JOGL Development
#1

hello,

i tried to use the texturerender this way:

tex is a TextureRenderer
texdata is a premade TextureData to be used as background image


			if (tex == null) {
				tex = new TextureRenderer(256,256,true);				
				tex.getTexture().updateImage(texdata);									
			}
			
			Graphics2D g2d = tex.createGraphics();
			g2d.setColor(Color.BLACK);
			g2d.setComposite(AlphaComposite.Src);
			g2d.setFont(new Font("verdana",Font.PLAIN,12));
			g2d.drawString(text, 100,100);
			g2d.dispose();
			
			tex.sync(0, 0, 256, 256);

rendering:


		tex.begin3DRendering();
		gl.glBegin(GL.GL_QUADS);			
		gl.glTexCoord2f(0.0f, 0.0f);
		gl.glVertex3f(-0.5f, 0.5f, 0);
		gl.glTexCoord2f(0.0f, 1.0f);
		gl.glVertex3f(-0.5f, -0.5f, 0);
		gl.glTexCoord2f(1.0f, 1.0f);
		gl.glVertex3f(0.5f, -0.5f, 0);
		gl.glTexCoord2f(1.0f, 0.0f);
		gl.glVertex3f(0.5f, 0.5f, 0);
		gl.glEnd();
		tex.end3DRendering();

unfortunately i cant see the font that is written into the texture, only the background image.

is it required to use the texturerender with the beginRendering and endRendering functions?

also, is there a possibility to enable mipmapping for the texture?

thanks!

#2

Hi…

Don’t know if it helps, but the sync-method didn’t work for me. I now use the markDirty-method (I suppose it came with the latest nightly builds).

Greets
Klemens

#3

emzic: the TextureRenderer isn’t intended to be used this way. The Texture it provides is conceptually “read-only” – you should use the Graphics2D you get from createGraphics() to draw your image into the backing store for the TextureRenderer first, and then draw your text on top of it.

Saxer: you’re right, you’ve noticed a change in the latest nightly builds. After discussion with Chris Campbell from the Java 2D team, we changed sync() to markDirty(), in order to allow a background thread with no OpenGL context available to indicate more easily to the OpenGL rendering thread what portion of the TextureRenderer needed to be updated.

#4

thanks, yes that was problem!

what about the mipmap feature? i tried implementing it myself by overriding the TextureRenderer class, but just using “true” in the textureData constructors didnt help.

#5

I need to add support for hardware mipmap support to the Texture class at which point the TextureRenderer can pick it up. It won’t work until that point.

#6

ok. that would be awesome!

currently when using objects with Textures made by TextureRenderer or TextRenderer that are animated and in the distance there are quite ugly aliasing artifacts. i am pretty sure these artifacts are caused by the standard LINEAR filtering and could be erased with mipmaps.

thanks! :slight_smile:

#7

I’ve added support for automatic mipmap generation to the TextureIO classes as well as the TextureRenderer and TextRenderer. This functionality should show up in nightly builds dated 4/9 and later. Note that there’s something wrong with one of our build machines so expect a build to show up on 4/10 after we fix it on Monday. Please try the new functionality and let us know whether it’s working for you.

#8

thanks a lot Ken,

the nightly builds i see on https://jogl.dev.java.net/ are still dated 2007-04-04 03:00 .

#9

We had problems with our nightly builds for the past several nights, but there is finally a new build on the JOGL home page I’m calling RC4. This is the last planned release candidate before the official 1.1.0. I’ll push the build (signing the binaries, etc.) and post about the changes in this build later.

#10

ok thank you!

i will try out the new features now.

first thing that popped up was a GL error when calling
texture.setTexParameteri(GL.GL_TEXTURE_MIN_FILTER, GL.GL_LINEAR_MIPMAP_LINEAR);
on a normal mipmapped Texture.

glGetError() returned the following error codes after a call to glTexParameteri(): GL_INVALID_ENUM

and the getBounds() function now seems to be leaving spaces in the middle of the string away. is that possible, or was it a wrong observation by me?

#11

The Texture class should be setting that for you automatically, but I don’t see why it should report an OpenGL error if you re-specify it. What card, drivers, and OpenGL version are you running? What’s the output of demos.printext.PrintExt? I’m assuming you’re going down the new code path using GL_GENERATE_MIPMAP. What does Texture.isUsingAutoMipmapGeneration() return?

I don’t think this should be happening. Please confirm it and provide a test case if something seems to be wrong.

#12

thanks.

i just left that call out, and the error disappeared.

i do not explicitly call
gl.glTexParameteri(GL.GL_TEXTURE_2D, GL.GL_GENERATE_MIPMAP, GL.GL_TRUE);
but i rely on the texturedata constructor:
TextureIO.newTextureData( somebufferedimage, true );

however my hardware:
GL Version: 2.0.6347 WinXP Release
ATI Technologies Inc. RADEON X600 x86/SSE2

Texture.isUsingAutoMipmapGeneration() returns true for the affected textures.

as for the second issue. i implemented a textfield using the texturerenderer and position a cursor in the textline using
textrenderer.getBounds(somesubstring).getWidth();
this was working very well in RC3 but now in RC4 (and no changes to the code) the cursor is off by some pixels if the string contains spaces. i will further investigate this, since at the moment i have no idea where the problem could be.

#13

EDIT: ok, i think i found the real reason of the problem. the returned space with and the calculation of the getBounds seems to be correct in RC3 and in RC4. the only difference is, is that the text that is drawn on the texture uses different widths for spaces.

i took a screenshot with both versions and overlayed them in photoshop, so that you can see the difference:

http://www.embege.com/misc/textrendererspaces.png

you can see that the word “This” is the same, but as soon as spaces follow, there is an offset. the code is the same in both versions.
if you count the space pixels between the words it is 6 in the first version and 8 in the other one.

#14

You’re right, there is a difference in the algorithm since the previous release candidate. As I think you and I discussed on another thread, the TextRenderer is now tokenizing the strings and inserting spaces manually. There is currently a difference between the computed bounds from TextRenderer.getBounds() and the output from draw(). I’ll fix this in the next build.

If getBounds() and draw() were returning identical results, would you care about the slight difference in rendering results? I don’t know how to correct for the pixel offsets at this point, and the tokenizing of strings should make the TextRenderer more efficient behind the scenes.

#15

thank you.

[quote]If getBounds() and draw() were returning identical results, would you care about the slight difference in rendering results?
[/quote]
sorry, i dont quite understand what slight difference you mean. if they are identical, why should there be a difference?

what would be important for my situation is that getBounds() and draw() return identical results (like in RC3), since the textcursor int the textfield is positioned according to the results from the java.awt.font.TextLayout and java.awt.font.TextHitInfo class.

#16

Since you’re using the TextLayout class separately from JOGL’s TextRenderer, you actually need more than just the TextRenderer’s getBounds() and draw() routines to have identical results; you need them to exactly match what would be produced from Java 2D.

Do you have a test case using the TextLayout and TextHitInfo classes to build an OpenGL text field that illustrates the problem with the current code (i.e., the selection not lining up properly)? If so, can you please file a bug with the JOGL Issue Tracker and attach it? You’ll need to request Observer status on the project if you don’t already have it in order to edit bugs you’ve filed.

#17

ok, i will try to pull out the textfield from our project and provide a testcase.
(in short, the problem is just that the spacewidth returned from getSpaceWidth() is not the same as the one that is rendered on the texture)

why exactly was there a need to change the handling of spaces from RC3 to RC4 ? (cause in RC3 the textfield was working fine :wink: )
thanks.

#18

ok here is a testcase that demonstrates the difference betweeen RC3 and RC4

http://www.embege.com/misc/textrenderer.zip

just two classes, should compile fine with RC3 and RC4.
just type something with spaces in the redline and then use the mouse to position the cursor. you should see that the cursor behaves correctly in RC3 and is off by some pixels in RC4.

should i file a bug in the issue tracker with this testcase? will you also need the *.class files and jogl libraries for that, or are the sources sufficient?

thanks a lot!

#19

another minor problem just occured, which was already mentioned by riven in another thread.

what if a string is wider than the backing texture?
i believe the limit is currently the maximum texture size of the graphics card which is 2048-4096 in most cases.

but the combination of older cards (like 512) and the textfield i use, allows users to type in any string they want and this situation may occur.
(users just press and hold a key :wink: )

yes, applications should care about this situation themselves, and i will definitely implement a fix for this, but still i think the jogl-textrenderer should throw an exception. currently it seems that the rendering just stops and the application freezes silently.

#20

Please go ahead and file a bug; just the sources is fine as an attachment.

Please also file a bug about the behavior when the string is too long for the backing texture.

For the time being I’ve reverted the TextRenderer back to the RC3 behavior and made getSpaceWidth() private again, because I’m not sure it’s producing correct results.