Sign in to follow this  
DannyLousberg

pbuffers

Recommended Posts

DannyLousberg    122
Anybody know of some good recoures on pbuffers out there? Google is giving me a hard time weeding out the useless links... The thing is, I need cross-hardware, cross-platform support for these things. If there are any non-object oriënted win32/linux pbuffer wrappers out there, I would surely like to know :) Greetz, Danny

Share this post


Link to post
Share on other sites
Promit    13246
Quote:
Original post by DannyLousberg
The thing is, I need cross-hardware, cross-platform support for these things.


Forget it. The only way you can guarantee support is to use the old CopyTexSubImage2D method to copy from the framebuffer into a texture. If ATI would get their act together, we could use FBOs, but until then...well, things suck.

Share this post


Link to post
Share on other sites
markr    1692
I've not seen a wrapper which handles wgl_ARB_pbuffer and glx_SGIX_pbuffer. I wonder if maybe they are too different.

It would be nice to have one (and as a bonus, handle Apple's pbuffer system for Macos X)

Unfortunately the only other way of doing (useful) offscreen rendering (perhaps) is to use GL_EXT_framebuffer_object, but that has much more limited driver support.

From the docs I've read so far, pbuffers are not straightforward to use - on Windows or glX.

Mark

Share this post


Link to post
Share on other sites
DannyLousberg    122
Owkay, that's a drag...

Anyway, perhaps someone can give me an idea on how to solve my problem another way...

The story goes as follows:

I'm develloping an engine which basically should in the end become some sort of easy-to-use non bloated simple framework type thing. First project that's gonna use it is a generic rpg/dungeon type game. (In true d&d or heroquest style that is).

For this, I need to be able to pick my models... So picking is the deal here. My initial solution was to render all the models a different color, no textures, no lightning, with depth testing to some offscreen buffer. This was only going to happen when a "pickrequest" was posted at the end of the frame, the program buffering "pickable" objects each frame. Performance wise, I thought this was going to be a sweet deal...

Turns out that render targets are at the moment probably one of opengl's weakest points, so I'm kinda <swearword>ed here. Let me just say that "gl" picking is not an option, and I need the backbuffer for other things already.

Most OpenGL picking examples tend to use opengl's picking mechanism, or the "render each in a color to the backbuffer" approach.

I'm kinda surprised I'm having such a hard time implementing this :).

Anywayz,

Thanx

Share this post


Link to post
Share on other sites
Guest Anonymous Poster   
Guest Anonymous Poster
Actually the pbuffer object that comes with the nVidia SDK (DEMOS/OpenGL/inc/shared/pbuffer.h) is rather simple and good. Rewriting it to C shouldn't be much of a problem. Still hoping to get framebuffer objects soon though so we can forget about pbuffers. By the way, at the nVidia website (http://developer.nvidia.com/object/nvidia_opengl_specs.html) thay state:

This page lists all the OpenGL extensions specifications that NVIDIA supports. Extensions marked with an asterisk (*) will be supported in Forceware Release 75 drivers.

and then they go on to mention EXT_framebuffer_objects without an asterix. Still, glxinfo refuses to report that I can use it. Is it possible yet or not?

Share this post


Link to post
Share on other sites
seaephpea    122
Go to the Tools section of www.gpgpu.org . They have a general purpose Render To Texture class which I think uses pbuffers if they're available. Haven't looked at it in great detail though so I might be wrong. Worth a look though.

Tom

Share this post


Link to post
Share on other sites
Promit    13246
In a different vein, you could try and write a raycast function to compute picking entirely on the CPU side. I don't know how easy or difficult it'll be in your particular situation, but it's worth considering.

Share this post


Link to post
Share on other sites
markr    1692
My take on picking is

Either
- Do it entirely CPU-side, and use raycasting to work out the nearest object at the cursor

OR

- Read the zbuffer out underneath the cursor (after normal rendering) and use that value to help you narrow it down to a 3d point in space, which you can then find the nearest object to (if it's near enough)

The latter approach - reading the zbuffer - sounds quite compelling, as it doesn't involve any expensive operations. You only need to read 1 pixel of the zbuffer.

Unfortunately, I don't actually know how to do it. I'm sure someone does.

The maths to work out where you've hit isn't very hard either.

Mark

Share this post


Link to post
Share on other sites
christian h    200
Quote:
Original post by Anonymous Poster
Still, glxinfo refuses to report that I can use it. Is it possible yet or not?


I'm struggling by booting to linux -> windows (crash) -> back to linux.. same thing next week.. ;)
So I'm also waiting for FBO-support in linux.
I guess their statement is just win32 specific, since latest driver for linux is 1.0.7, latest for win32 was 76.something.

ch.

Share this post


Link to post
Share on other sites
Promit    13246
Quote:
Original post by markr
The latter approach - reading the zbuffer - sounds quite compelling, as it doesn't involve any expensive operations.


Except, of course, that it forces a complete pipeline flush.

Share this post


Link to post
Share on other sites
Guest Anonymous Poster   
Guest Anonymous Poster
How can I tell if my graphics card supports PBOs?

Share this post


Link to post
Share on other sites
DannyLousberg    122
I guess I could try the raycasting approach... Only question I have right now is how to determine the 3D coördinates for my mouse position, I'll have to check out gluUnproject...

I can't verify if my FX5600 supports fbo's on linux since I'm at work now, where I only have this crappy DRI supported mobile ATI IGP thing. But I'm guessing if they state support for it on windows, they'll have it on linux too (unified driver infrastructure business, you know...)

I'll post it here when I've checked it at home.


Thanx

Share this post


Link to post
Share on other sites
markr    1692
Quote:
Original post by Promit

Except, of course, that it (zbuffer reading) forces a complete pipeline flush.


It may force a complete pipeline flush, but that doesn't matter, as you'll only do it when rendering is complete.

When rendering is complete, a pipeline flush has to happen anyway sooner or later (I.e. you're going to swap the buffers), so causing one does not cause a performance problem.

It would only be a problem if you were calling it in the middle of rendering, and only *really* a problem if you were calling it multiple times in the middle of rendering. Which you wouldn't be.

Mark

Share this post


Link to post
Share on other sites
renderer    202
You can do a hybrid approach between CPU raycasting and hardware picking.

First, put a bounding sphere around all objects in your scene, then you can do trivial reject that you haven't hit a bunch of objects. The objects that you do hit may not may not actually be picked, because the sphere is just an approximation, but then you can do the hardware picking on a much fewer number of objects and get better support.

Also, I recommend this paper if you want to try doing your own raycasting and you want it to be fast
J. Arvo, D. Kirk, A survey of ray tracing acceleration structures, In Glassner, An Introduction to Ray Tracing, pp. 201-262.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this