Hi,

With assertions, you can enable assertions on package level and will only have debugging on for that package.

Yuri

Hi,

Guys, don't you think that it would be good to wrap all profiling, logging and debugging calls into assert statements?

I made a simple test: wrapped all profiling callse with assert - it added 3% FPS for nothing! OK, just 3%, but that's only profiling - what will be with debugging and logging that makes more checks !?

For developers it does not make nay inconvenience - just enable assertions and you have all of debugging/logging functionality back, while game developers who normally do not tune the core will be able to run full speed because of assertions are off by default.

Comment on this, and if there is no objections, I will commit the cnages.

Yuri

Hi,

Fix committed to CVS.

Yuri

Hi,

renanse, I just recognized that JavaWebStart benchmarks on your page use different canvas resolution - Java3D runs 640x480, while Xith3D runs 800x600. Can you check please or I am doing something completely wrong?

Yuri

P.S. My desktop resolution is 1600x1200, so I just did Alt+PrintScreen to check the actual window size.

Hi,

After really long and complicated debugging I finally found a REAL reason for object flashing in Q3 Benchmark. It was... attempt to access texture unit states higher than allowed by OpenG: implementation. This means that for cards that support >= 4 texture unit states for multitexturing, the problem did not appear, but other implementations are silently clamping texture unit state number to maximum allowed if it is too big.

This caused highest texture to be turned off after the core was trying to switch off non-existing not-used texture (states 2 and 3 in case of Q3 Benchmark).

To fix this, stricter checks against implementation limitations added. I will commit the fix after removing all debugging stuff.

Yuri

Hi,

We can easily experiment with disabling the state caching. There is only one method affected, so we can try to build complete appearance in display list.

On the other hand, I believe that higher efficiency of jME is in different area than display lists. For complicated scenegraphs numerous display lists may become an issue - it is even highlighted in some application notes for VBO extension.

BTW, I am still checking what is wrong with multitexture. Currently implemented architecture seem to be correct, but due to some reason it does not set up proper texture states if only one of textures changed.

Yuri

Hi,

The fix in CVS is definitely suboptimal. There is a problem with state caching of texture unit states for multitexture. This is still under deep investigation by me.

Yuri

Hi,

OK, I localized the problem - texture unit state was not set in setupTextureUnit(...).

Sorry, but I had to make setTextureState method in TextureShaderPeer no-modifier - otherwise there will be no access from ShapeAtomPeer. Otherwise we had to make it public, which is even worser.

Maybe we have to review the architecture for mutitexture and texture states to eliminate different codepaths for single-textured and multi-textured shapes.

Yuri

Hi,

After taking a short look at the current implementation renderAtom(...) I got a question:

 As of renderAtom(...) code, STATIC_APPEARANCE means static texture coordinates. Maybe it should be called like this?

Yuri

Hi,


GIMP lies, sorry.

JPEG can hold arbitrary number of bands, AFAIK. And meaning of the bands is completely application-specific. For example, Photoshop uses 4-band JPEGs for storing CMYK images.

Take a look at com.sun.image.codec.jpeg.JPEGDecodeParam JavaDoc for more details. I have somewhere more detalied description of how it works, but I believe it is internal doc... I can not remember exacly...

Another point is that ImageIO JPEG decoding is native-code-accelerated in Java. Not the fastest one, but...

I am not a proponent of neither JPEG nor ImageIO, but for me ImageIO is most compatible image loading mechanism for a moment. If you consider porting another image loading lib, then it should be (I think) A) compatible with ImageIO; B) be Pure Java - I believe we should TRY to keep Xith3D Pure Java, otherwise it has no advantage of being used in Applets without purchasing VeriSign certificate (remember that JOGL comes signed by Sun already).

Yuri

Hi,


Yes, you are right in some extent, but at the end compressed textures can also be downloaded (uploaded - you nearly converted me to this term) using PBOs, which [may] save some RAM on startup.

Yuri

Hi,


False. It is tricky to produce, but it does. I use "custom build JRE" to be able to save such a jpegs, and it even lets me to create textures where quality and subsampling of alpha and color channels are different.

Yuri

Hi,

Take a look at the screenshots: S1.jpg is how it is looking in most cases; S2.jpg is how the same object looks after moving camera a bit (rotate right).
S1.jpg is how it should look (and as it looks most of time), S2.jpg shows it is much brighter and no shadow.

I checked already that it has nothing to do with Color, Transparency and Lighting. My guess for a moment that something is wrong with Multitexturing.

Yuri

Hi,


Yes, I agree, and even more - we have support for comprssed texture formats already implemented and functional. But if you consider also Internet-downloadable applications, then you should also consider the transport size and - as you can guess - JPEG or JPEG2000 images will be way smaller than DXT1 compressed ones. But, yes, use of DXT1 compressed images saves you from doing decompression - it all is done by hardware, and it is efinitely the best choice. Even for smaller textures DXT1 image may be smaller than JPEG, and this saves A LOT of performance.

...as always, there should be a balance...

Yuri

Hi,

We can also use no-modifier classes, fields and methods that will be visible inside package only but not visible from outside.

Yuri

Hi,

I agree with one minor comment: I easily believe that this unpacking procedure made by glTexImage2D may perform quite different if there is no real data transformation changed (they call this "swizzling" in that paper), so if you observe 7800GT performance for 8-bit Fixed Point RGBA and BGRA (columns 1 and 2 on 7800 GT line on Download), you will find quite big difference - 483 MB/s for RGBA vs 2238 MB/s for BGRA, which is, say, a kind of difference.

Yuri

Hi,

Looks like we again have the same problem with flashing objects in Q3 Benchmark. Few days ago the problem gone, but now again it is here. I don't know after which changes it re-appeared.

Yuri

Hi,


I meant transferring texture from the encoded state (jpeg/png/*** image or stream) to the ready-to-render state (in video memory).

OK, depending from which side to look. "Texture Download" wording taken directly from NVidia's "Fast Texture Downloads and Readbacks using Pixel Buffer Objects in OpenGL" technical brief, so I just re-used the term (OK, this brief is around one year old, but I was checking this topic way earlier). So if you don't mind I will continue to use the same term, besides I agree 100% that from the Application Side it looks like "Upload Textures To The Driver/Video Memory".

Yes, you are right about PBOs, but I can not 100% agree ok that they will not help. With faster texture download I target not only the FPS reached, but faster application startup and lower memory usage during startup. And the latter is a point where PBOs may help I think.

Another application of PBOs I am targeting personally is a video streaming to texture - I intensively use this feature, and if I can parallelize decoding and texture streaming plus utilize DMA transfers using, say, PDR (Pixel Data Range) (which I personally don't like too much), then I can reduce CPU load for video playback by avoiding at least one memory-to-memory transfer.

Yuri

Hi,

I would like to get images that produce these errors for further investigation.

I had only a problem with bands when was trying to load RBG texture into RGBA destination, and Grayscale texture in RGB/RGBA destination.

Yuri

Hi,


Not really, I just explain how things work.

What I can (and probably will) do is to change DirectBufferedImage implementation so it is using DirectByteBuffers. Integration with TextureLoader is your part.

A4 step acceleration is tricky, but it after may make use of DMA transfers directly from user space to AGP/PCI/PCI-e memory or even decode image data directly there.

I am not so sure if we should use this because of side effect is neccesity to put all textures in single DirectByteBuffer (i.e. implement a kind of texture memory allocation ourself).

Yuri

Hi,


I guess he is intergating it with existing texture loader.

But in the meantime I plan to play a bit with even better loading which may theoretically utilize some features of the driver.

...but for this I guess we will need something like a "lazy texture loading" which will run on Rendering thread (i.e. within the context of GLCanvas.display(...)

Yuri

Hi,

I agree with Marvin, especially that there are some things in mind.

Yuri

Hi,

I believe yes - this is a rudiment from very very very very old time. I guess it is a JBuilder meta-information file.

Yuri

Hi,


I just checked the state-of-the-art OpenGL extensions, and there are ways how to avoid this and make texture download to the driver even faster.

Yuri

Hi,

In general, you should support images of up to 4 bands:

1-band (grayscale) - for Alpha or Luminance textures
2-band - For Luminance+Alpha textures
3-band for RGB
4-band for RGBA.

There are methods for creating DirectBufferedImage for cases of 1, 3 and 4 bands. We probably should also support 2-band. Check com.xith3d.image.DirectBufferedImage for details.

Yuri

Hi,

After reviewing the code in texture shader, ImageComponent2D and DirectBufferedImage, I believe that we sould introduce some changes also there.

The general point on loading textures is that we copy them way too much - at least 3 times when DirectBufferedImage is used, and 4 times when using plain BufferedImage. Textures often are big, so this consumes memory and increases the startup time.

For regular BufferedImage, procedure is following:

A1. Read image and store it to data array allocated internally by ImageIO
A2. Allocate new byte[] in ImageComponent2D and pull data out of BufferedImage from step A1 using pixel processor
A3. Allocate DirectByteBuffer in ImageComponent2D and put data from byte[] from step A2 into it
A4. Pass a reference to DirectByteBuffer created at A3 to OpenGL context, which will allocate one more array to hold texture data in driver space

Step A4 we can not avoid anyway... (there are some ideas on that, but I am not so sure they will work).

Now what is happening with DirectBufferedImage.

B1. Create new DirectBufferedImage of appropriate type - it will create the byte[] (the Backing Store) similar to one created on A2 and hold reference to it
B2. Read image DIRECTLY into DirectBufferedImage - this will store pixel data into Backing Store byte[] and will avoid of extra byte[] allocation inside ImageIO
B3. Allocate DirectByteBuffer in ImageComponent2D and put data from byte[] from step B1 into it
B4. Pass a reference to DirectByteBuffer created at B3 to OpenGL context,

...and how it should be at the end:

C1. Create new DirectBufferedImage of appropriate type - it will create the DirectByteBuffer (the Backing Buffer) similar to one created on B3 and hold reference to it
C2. Read image DIRECTLY into DirectBufferedImage - this will store pixel data into Backing Buffer DirectByteBuffer. This is way more tricky, but I have few implementations of this which are fast enough (I did that for progress-trackable texture loading which shows the progress of ImageIO decoding the image.
C3. Create ImageComponent2D such a way that no new DirectByteBuffer is created but one from step C1 used
C4. Pass a reference to DirectByteBuffer created at C1 to OpenGL context

You can see that we can get rid of a lot of pixel processing this way, but this only fits Power-Of-Two-sized textures, and others have to be loaded conventional way.

Yuri

Hi,

Looks like my chapter to XIN should come... Or so... For those who feel fit to read heavy technical stuff.

Yuri

Hi,

There is a check in Group anyway, but I would like to have a switch that turns warnings of (should be ON by default, or even can throw Runtime Exception).

Yuri

Hi,


As I mentioned also, it is already fixed in current CVS.

Yuri

Hi,

Please describe a problem in a bit more details - I believe I will find some time to look at it over the weekend.

[You should consider I am not an user of HUD, but know how the core works in deep details and how to debug it [the core], so if you feel we can use it let's do so].

Yuri