Off-screen rendering: Is it portable?

Hi all,

I need to deploy an OpenGL program across multiple Windows computers, which may have any graphics cards.
I need to be able to print my OpenGL model and I’m curious, is off-screen rendering is supported by all OpenGL implementations?

Thanks.

This is the second time you’ve asked this question: http://www.opengl.org/discussion_boards/ubbthreads.php?ubb=showflat&Number=286906#Post286906

The answer is “no, it’s not”. However, it is very widely supported on most modern cards and chips, so you really need to research your user base, find out more about what hardware they have, and write your code to target that hardware.

You also need to say more about what you mean by “print my model”. Do you mean “print” as in to a printer? Off-screen rendering has nothing to do with printing. You could easily send it to a printer using glReadPixels and your local friendly printing API.

glReadPixels from not-FBO only works for visible pixels. So no 10x larger window for higher DPI print quality, no hidden GL window, no slightly overlapping window.

“You could easily send it to a printer using glReadPixels…”

That’s what I’m doing now. I have four computers to test with and I’m finding that 3 work just fine, but on one of them, glReadPixels is returning gunk at the top and bottom. This consists of pixels that are nothing like what’s on-screen. It’s a Windows XP machine that’s the problem. HOWEVER I’m not the one who’s operating it so it may be that they’ve got the window too small and these pixels are not appearing.

“find out more about what hardware they have”

It’s going out into the world where anybody can use it, so there is little chance of either my asking them or adapting to what they have.

“glReadPixels from not-FBO only works for visible pixels.”

… And I can’t guarantee that a user will not have the window scrunched down so that very few pixels are visible.

OK, so if glReadPixels won’t always work, and FBO isn’t guaranteed to be available, is there any option left?

How about ray-tracing? I could include a POVRay executable, I suppose, and invoke that. However the users will want to print this quickly; they don’t have all day to wait.

OK, so if glReadPixels won’t always work, and FBO isn’t guaranteed to be available, is there any option left?

I asked this in the other thread, which you completely ignored. What do you mean by “guaranteed?” OpenGL itself is not “guaranteed” to even be available. If it is available, drivers aren’t “guaranteed” to work.

So what kind of “guarantee” are you looking for?

The only guarantee is this: get mesa3d and compile it into .dll, then use it as a software renderer. You’ll have FBO support even if there’s no graphics card installed on the windblows computer.

Hi Alfonse, sorry I completely ignored your question a year and eight months ago. Will you forgive me, my old comrade?

By guaranteed I mean that my program will be going to a variety of Windows users with a variety of video cards. It can’t not function. If it does, others will become frustrated and I… I will experience melancholy.

So for instance my current problem involves using glReadPixels and I’m told that some of the pixels being read are garbled. I had no idea some versions of Windows didn’t support glReadPixels properly, but apparently at least one does.

I could try that experimentally, taking out GLUT 3.7.6 and Windows’ OpenGL and putting in MesaLib and MesaGLUT. But I worry, isn’t Mesa much slower?

Also, will GLUI work all right on top of Mesa3D? I am using subwindows, which are another feature that seems to break on other systems.

By guaranteed I mean that my program will be going to a variety of Windows users with a variety of video cards.

I’m trying to get at specifics, and “variety” isn’t very specific. Give a minimum OpenGL version number. Or a Direct3D version number. Or even just the lowest-end cards that you plan to support.

In general, when people release programs, they offer a minimum specification below which the application is not intended to function. What is yours?

But I worry, isn’t Mesa much slower?

Of course it is; it’s a software renderer. But because it is software, it is “guaranteed” to work.

You can use both mesa or the real thing if it is available. If it is not, you use the software fallback, mesa3d.

Everything will work with mesa3d, only rather slowly.