force rendering

[gouessej]

I would like for support for reading from GPU resident textures to be implemented in Ardor3D.[/b]

What do you mean? There is no way to force OpenGL to store the texture data in the GPU, glPrioritizeTextures only allows to suggest priorities, the driver can even ignore them.

[martifa]

By resident I mean textures where the data resides in GPU memory and for which there is no copy on the CPU side. Textures rendered to by a texture renderer are examples of what I mean. Am I perhaps using the term "GPU resident" wrong? Anyhow, as runiter also has experienced, there is currently no support for reading data from such textures from GPU memory over to CPU memory.

[fuchs]

The term is ok I think. As for the copy-from-GPU-to-CPU-RAM functionality, there already is a ticket listed under release 0.8 enhancements: #212. So, be a little more patient (or take on the ticket yourself )

[runiter]

What do you do in updateCamera? You should not have to call updateFrame() twice.

This is what I do for updating camera:

Code: Select all

         camera.setLocation(cameraLocation);
         camera.lookAt(cameraLocation.add(0, 1, 0, null), Vector3.UNIT_Z);
         getCameraNode().updateFromCamera();

[martifa]

The term is ok I think. As for the copy-from-GPU-to-CPU-RAM functionality, there already is a ticket listed under release 0.8 enhancements: #212. So, be a little more patient (or take on the ticket yourself )

I know, I submitted it with a suggestion for a solution;) It's the same solution I proposed to rutiner in this thread. I don't mind putting in some time to get it into ardor core, but I guess someone else would have to approve the solution first. Are you involved in development on Ardor3D? I don't know how these things are organized here...

gouessej, I saw that you have pointed out that I create the buffer every time I read from the texture in the code I provided in #212. A quite trivial thing, but also quite stupid of me not to correct this as I am actually using that code now. Thanks! Have you also looked into the parts of the code that would go into Ardor3D and have an opinion of how this should be done?

Martin

[runiter]

is the scene rendered into the back buffer the first time while you are trying to read from the front buffer? If it is so you would have to render it again for the data to be shifted to the front buffer and be available to you.

Maybe it is indeed rendered to back buffer...I don't know...is this how Ardor3D works?
If so then is there an easy method to call to force the back buffer to pop out with rendering the entire scene a 2nd time?

[martifa]

I don't know really, but I believe double buffering is "always" used in modern desktop 3D graphics. So I think Ardor3D takes care of double buffering behind the scenes. I might be completely wrong, but it would be a fun test if you changed your code to

Code: Select all

while(!done) {
   updateCamera();

   frameHandler.updateFrame();

   getCanvasRenderer().makeCurrentContext();
   //------------------------------------------
   final GL gl = GLU.getCurrentGL();
   gl.glReadBuffer(GL.GL_BACK);
   //------------------------------------------
   renderer.grabScreenContents(_scratch, getFormat(), 0, 0, width, height);
   getCanvasRenderer().releaseCurrentContext();   

}


.

[fuchs]

Are you involved in development on Ardor3D? I don't know how these things are organized here...

Not necessarily more than you, no. If you have a suggestion or improvement that is of use to ardor user in general it will usually get accepted by Renanse and/or MrCoder . (This may involve reminding and nudging them to review the change sometimes if they are busy ) If it is a big enough change (an entire class or more) then you will be asked to sign a contributor agreement, this allows ArdorLabs to avoid potential licensing time bombs and also ensures that the Ardor3D baseline code stays FOSS in the spirit of its current license.

[renanse]

I know, I submitted it with a suggestion for a solution;) It's the same solution I proposed to rutiner in this thread. I don't mind putting in some time to get it into ardor core, but I guess someone else would have to approve the solution first.

I've been looking at this. As stated in my note on the ticket, it's complicated to add readback to TextureRenderer in a general purpose way. If you render to multiple textures and happen to send more than your card can handle in one pass, it will be done in multiple passes, making it hard to guess what color attachment to target, etc. Maybe we could tie the callback(s) to a specific texture and have the renderer inject the correct attachment. There's also the complication of pbuffer-based TextureRenderers.

Another method could be staying out of TextureRenderer and instead exposing glGetTexImage in the Renderer?

[martifa]

I've been looking at this. As stated in my note on the ticket, it's complicated to add readback to TextureRenderer in a general purpose way.

I'm happy to hear you have looked into it:) Thanks, for the feedback!

Maybe we could tie the callback(s) to a specific texture and have the renderer inject the correct attachment.

That's probably a good idea. The solution I have presented is very simple and would, as you say, break down if all textures aren't rendered to in one batch.

There's also the complication of pbuffer-based TextureRenderers.

I don't even know how these work....

Another method could be staying out of TextureRenderer and instead exposing glGetTexImage in the Renderer?

As far as I know glGetTexImage would transfer the whole texture, right? If that is so I would prefer to use another method, because reading the whole texture can be a lot of wasted time and make some things impossible to achieve. For example: The pixel level picking "system" that I am using now would not work with that approach.

If I may make a suggestion I would say we should have a closer look at how we can make a callback based solution more robust and clever so it would handle the situations you describe. At least I want to have the ability to transfer a subset of a texture... Could such a mechanism be implemented for the FBO texture renderers only, as a first version of a "read back" feature?

Martin