PDA

View Full Version : Fast rendering and storing results



camdev1
03-03-2015, 01:34 PM
Hello, I'm new here :)

I've loaded a 3d model in my opengl program and I'm able to render it. The triangles are pure white, and the background is pure black, no lights in the scene, only two colors rendered in the window, the objects is rotating in the scene - to this point I have no problems.

My task is to rotate the object around the up Y axis with the step of 0.1 degree, make the full 360 degree rotation (so it's 3600 frames to render) and save each frame (window is 256x256 px) into the boolean arrays (3600 two dimensional arrays 256 x 256 bits). My question is: how to make it and make it possibly the fastest?

I' not very familiar with OpenGL, but I know how the transformations works, I can draw meshes etc.
So far I see that I have something like max fps set to 60, I guess it have something to do with vsync.

uwi2k2
03-03-2015, 11:19 PM
hi,

after every frame you can copy the render result into a buffer and store it ti your HD.
This is a slow prozess but as long as you keep the szene 256x256 px it should be fine ..
sztart reading here .. and you will find the best function for you:
https://www.opengl.org/wiki/Framebuffer

regards
uwi2k2

camdev1
03-04-2015, 01:11 AM
In fact I need to have very fast access to the resulting data, so saving it to hard disk is not an option for me.
I want to have it in my RAM, but it shouldn't be a problem, 256x256 bits x 3600 =~28 MB, so it's not that big amount of data.
Is the framebuffer still the right choice then?

tkausl
03-04-2015, 02:17 AM
In fact I need to have very fast access to the resulting data, so saving it to hard disk is not an option for me.
I want to have it in my RAM, but it shouldn't be a problem, 256x256 bits x 3600 =~28 MB, so it's not that big amount of data.
Is the framebuffer still the right choice then?
I don't know how you got 28MB, i got 675MB but should still fit in ram.

The framebuffer is still the right choice, since you have to get the image into ram first, saving it to HD would be the second step and has nothing to do with the framebuffer, if you don't want to save just skip this step.

camdev1
03-04-2015, 03:44 AM
Thanks for tips, I'm starting reading about framebuffers :)
And the boolean type is just 1 bit (8 bits = 1 byte) so 256x256 = 65536 bits = 8192 bytes = 8 kilobytes, multiplying by 3600 its somewhere about 28 mb.

tkausl
03-04-2015, 03:46 AM
Ah, so you just need a 1-bit alpha-value, okay.

camdev1
03-04-2015, 08:38 AM
And the last question, should I use the glReadPixels function to finally read data from frame buffer?

GClements
03-04-2015, 07:33 PM
And the boolean type is just 1 bit (8 bits = 1 byte)
All OpenGL image formats use a whole number of bytes for each pixel, so the smallest framebuffer size will be 64 kiB.

After rendering you can either use the CPU or a compute shader or fragment shader to re-pack the data.

If you need low latency (i.e. you need to access the rendered frame from the CPU shortly after rendering it), you should create at least 2 FBOs and alternate between them, so that you can render the next frame while reading the previous one).

If you need throughput rather than latency, you're probably better off creating a few large textures and rendering each frame into a region of a larger texture. That way, you can render as many frames as will fit on one texture in a single draw call. With layered rendering to an array texture, you may be able to do everything in one draw call.