Drawing billions of polygons to screen without locking UI?

[bsder]

I’m rendering a VLSI chip design to screen. This is LOTS of polygons (roughly 1 billion at chip top). It is okay for this to take several seconds to render as long as it doesn’t block the UI.

What I would like to do is let Thread A continuously render to an off-screen FBO until completed and once every 1/60 of a second (or so–probably use an Animator) let the main GUI thread do a blit from the off-screen FBO to the screen. This way, Thread A runs at full-speed or close to it but doesn’t block the GUI thread and thus hang my responsiveness.

Can anybody point me to some sample code for this? The main issue I’m having is how to get a thread-safe, stable working reference to GL and the FBO when I’m not actually sitting in a GLEventListener callback.

Please note that this is different from deferring drawing to the main GUI thread. There are simply far too many polygons to even think about drawing them on the GUI thread.

Thanks.

[lhkbob]

Caveat: this is for JOGL, and don’t know how things will change for JOGL2

What you’re looking for is active rendering. Jogl doesn’t really like you to use active rendering but it is possible. Here’s how it works:

1. Call Threading.disableSingleThreading()
2. Create a GLCanvas just like before, except you’ll want to call setAutoSwapBuffers(false)
3. Have a render method:

GLContext context = canvas.getContext();
context.makeCurrent();
... do rendering here with context.getGL()
context.release();
canvas.swapBuffers();

This is just a simple example, and normally you’ll want to perform error checking on makeCurrent() (see the java docs).

Even with active rendering, you should only render from a single thread - most drivers are single threaded or are buggy with multiple threads. This means that you won’t be able to blit the fbo’s texture to screen until its done rendering.

As far as the number of polygons being rendering, I strongly recommend you look into LOD. I find it hard to imagine that 1 billion polys are necessary for all detail at the highest level.

[bsder]

@lhkbob

Even with active rendering, you should only render from a single thread - most drivers are single threaded or are buggy with multiple threads. This means that you won’t be able to blit the fbo’s texture to screen until its done rendering.

Well, I was going to point out that that defeats the whole purpose of going through this, but it does keep all of the non-GL UI parts like menus active. So, I guess that something …

However, it doesn’t completely solve the problem. I need to be able to occasionally blit the partially completed FBO to the main screen.

@lhkbob

As far as the number of polygons being rendering, I strongly recommend you look into LOD. I find it hard to imagine that 1 billion polys are necessary for all detail at the highest level.

While you would think that, it turns out not to be the case. It turns out that VLSI designers get used to the particular aliasing vagaries of the render engine. Consequently, they can actually “see” errors by observing aliasing artifacts that don’t match the underlying symmetry of the VLSI chip. It’s remarkably unsubtle in a lot of cases.

[lhkbob]

I don’t see any way of reliably getting an FBOs contents while its actively being rendered into. One solution that might work is to split the rendering into smaller batches. Then after each batch, you unbind the fbo and blit the contents to the screen, rebind the fbo and continue with the next batch. I think this would work well depending on how you split the batches up.