Jump to content
  • Advertisement
Sign in to follow this  
kRogue

OpenGL MRT's and openGL howto?

This topic is 4830 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

Simple direct question: how does one setup and do Multiple Rendering targets in openGL (using GLSL)? My goal right now is that I want to generate several "screens": a) Normal Vectors (i.e. normal at visible parts of the showing fragments, generted with bump maps and such) b) geometric posiiton in space (i.e basicly gl_Vertex before Projection matrix is applied) c) specular info (specular color for each rgb-component) d) diffuse color (i.e. our textures) then use these together with shadow mapping to do lighting with bump and specular lighting.... Best Regards [please, I hope there is a way to do it without FBO's becuase I have found no Linux beta drivers for nVidia hardware and ATI does not do FBO's at all right now ;( but away to do it with FBO's is also good for me to know (since in a few months the release drivers should have it a go]

Share this post


Link to post
Share on other sites
Advertisement
ARB_draw_buffers extension is required to utilise it (or ATI_draw_buffers, its basically the same thing, all OGL2.0 drivers should support it).

MRT can be done with just pbuffers, setup a pbuffer with a number of AUX buffers and bind them as render targets.

The rest of the details should be covered in the spec

Share this post


Link to post
Share on other sites
read the spec, thank you _phantom_. Atleast it is what I though via the gl_FragData (whcih is mentioned in the spec for the GL shading language) then also found the glDrawBuffers in the openGL 2.0spec.. shoudl have been able to fin that on my own too... now for some stuff that is messier: I hate to do it, but lets talk pbuffers: most of the docs I ahve seen are for MS windows using wgl* functions... I am doing this in Linux, but I use SDL to initialize openGL and such... now looking at the headers <GL/glx.h> we see the functions:

extern GLXPbuffer glXCreatePbuffer(Display *dpy, GLXFBConfig config,
const int *attrib_list);

and

extern void glXDestroyPbuffer(Display *dpy, GLXPbuffer pbuf);


I have been trying to avoid making "system" specific calls, as I want to avoid the whole #ifdef nightmare in my source when I compile it on windows vs Macintosh vs Unix.... I am thinking that SDL has somekind of generic way to do these glX* calls that correctly maps to the right calls in Windows, Macs or Unix.... i.e it has some kinf of "wraper" system so that a certian set of functioanlity is exposed (but mapped differently) under fiddferent systems...
but I have not seen anything in the SDL docs so far for specific glX calls... anyone know? or will I have to deal with the glX calls myself? (and hence to write on other platforms the #ifdef/#elseif hell)

Best Regards


Share this post


Link to post
Share on other sites
if you do end up going platform specific then the simplest way todo it would be to create your own header with a set of platform independant functions in and then link the correct C++ or C file in the final exe, depending on what platform you are on.

So you could have

void Createpbuffer(/*some params here*/);
void Destorypbuffer(/*some params here*/);


for your header file and then make two cpp or c files which contain the functions (called something like pbufferwin32.cpp and pbufferlinux.cpp) and write your platform specific stuff in there.

The only problem I can see is the different handles win32 and linux use, but one doing something like;

#ifdef LINUX
typedef GLXPbuffer pbufferhnd;
#elif defined(WIN32)
typedef hwnd pbufferhnd;


at the top of the header file will fix that for you (just use the 'pbufferhnd' as the parameter to the functions).

Share this post


Link to post
Share on other sites
erg.. that is almot exatly what I wanted to avoid becuase I'd like a way to also implement this stuff in a way so that if it works on my Linux box, it _should_ work on other boxes... erggg... oh well, for now I'll keep it to X style calls....

Best Regards

Share this post


Link to post
Share on other sites
more or less, you could further sud-devide it, so that you have 3 cpp files (pbuffer.cpp, pbufferwin.cpp & pbufferlinux.cpp), in the first one keep all the platform independant stuff and in the last two put functions which are thin wrappers around the platform dependant stuff, a smart compiler should be able to perform some inline magic tricks so that the code ends up as if you were just including it in the orginal functions/cpp file.

This solution would work nicely with a class interface as you can abstract away the problem. (This is the solution I took with my ogl window framework, while its a bit of effort to keep stuff in sync you dont end up in a #ifdef...#end nightmare)

Share this post


Link to post
Share on other sites
I completely agree, and am doing the exact same thing for my windowing routines. :D

_the_phantom: I'd love to compare notes sometime soon on how you handle the differences between linux/windows in your framework.

Share this post


Link to post
Share on other sites
sounds like a sane plan, give me a poke sometime in the near future if ya want to discuss owt [smile]
(I'm currently avoiding IRC and the like so I can focus on getting stuff done)

Share this post


Link to post
Share on other sites
what cards support glDrawBuffers? on my card [GeForce5900XT], GLee gives me a false on GLEE_ARB_draw_buffers, i.e. glDrawBuffers is not supported.... wat cards support writing to multiplt rendering targets? moreover, is there a way to get a GeforceFX to do MRT's? [my system is Linux with Nvidia's 71.74 drivers]

edit: it looks like to me that of the nVidia cards, only cards from the GeForce6 series can do MRT's, someone correct me if I am wrong. but what about ATI's?

Best Regards

[Edited by - kRogue on May 25, 2005 1:04:18 PM]

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!