next »

[Oliver]

Hi,

after migrating an existing project to the current xith trunk (migrating to the new HUD system), the TextureFilter won't work for Image Widgets any more.

The code to change the filter is like this:

myImage.getTexture().setFilter(TextureFilter.ANISOTROPIC_2);

The TextureFilter works in the Panel Widget. Unfortunately some parts of the HUD in my project aren't easy to convert into a panel.

I had a look into the sources to see if I can find a solution. But unfortunately the HUD system has changed a lot from the old version - thus it isn't easy at all to compare with the old (well filtering) Image class

many thanks if anyone can help!

Cheers,
Oliver

[Marvin Fröhlich]

Make the ImageWidget heavyweight. Then it should work.

Marvin

[Oliver]

Hi Marvin,

of course I tried that before posting here, but without success. I tried to dig into the issue meanwhile:

• The Image object in an example is 28x28 pixel (this is the output size on the screen)
• The source image is a png (28x28), has an alpha channel and is partially transparent
• The Image will be rendered in the HUD with a size of 28x28 pixel
• The Texture2D object created by the ResourceLoader is 32x32 (I guess textures must be in a power of 2?)
• The texture will be streched into 28x28 pixel what seems to cause the bad quality.
• With TileMode "Tile_BOTH" the arrow will be rendered in good quality, but of course will be clipped.

The old version of Xith3D rendered the same png file in 28x28 with much better quality. Take a look to the attached images. Both are xith renderings and the blue arrow is 28x28 each:

Old HUD System		New HUD System

I'am not sure what exactly causes the issue in the new HUD system. Is it the texture's size of 32x32 or is it a change in the HUD/render code?

Thanks for your help,
Oliver

Edit: I rolled back the xith 3D binaries and saw that the Texture2D in my example was 32x32 as well. Thus, the issue must be in the rendering of the 32x32 texture into the  28x28 image. It might be, that the TextureFilter isn't used?

[Marvin Fröhlich]

It can very well be, that the texture filter isn't used. The new HUD system doesn't create and maintain one shape and texture per widget, but creates one texture and shape for the root heavyweight and any lightweight contained in it will use the texture and shape of the (grand-)parent heavyweight and all of its properties and so forth. Any heavyweight will always have its own shape and texture and properties.

Yes, textures must (or should) be power-of-two sized. But only the 28x28 part of your texture is used by appropriate texture coordinates. So this wil not be the problem.

Could you please create a testcase. This will make it much easier for me to check this.

Marvin

[Oliver]

Thanks Marvin,

I've uploaded a new test into xith-tk:

org.xith3d.test.ui.ImageWidgetTest

Cheers

[Marvin Fröhlich]

I have renamed the testcase to ImageWidgetFilterTest.

The problem is not the OpenGL texture filter, but the Java Graphics2D interpolation filter. There was only a simple nearest_neighbour filter used when a streched image was rendered. Now a bicubic filter is used. We need to observe, if this doesn't drop performance too much for anyone using a streched image widget.

Additionally the texture filter wouldn't have to be set to the image widget's texture, but the to image widget's shape's texture. Have a look at line 102 in the testcase. Though this doesn't have any effect and only drops performance for nothing, since the shape is not scaled by OpenGL.

Marvin

[Oliver]

Thank you for the fast response and for pointing this out.

The rendering looks much better now, indeed still not as clean as in the old HUD system. See the comparison below:

I still wonder how it worked (in term of quality and performace) in the old system. It's very confusing comparing the sources.

Oliver

Edit: attached the source images from the example above