From what I can see, Displacement mapping under OpenGL is done via uber/super buffers, which are exposed on the R300/R350 line of cards.
However, I cannot for the life of me actually find any information regarding using the extensions to handle displacement mapping. Does anyone have any links to information in regards to this, or have any information themselvse on it?
AFAIK displacement-mapping is only available on Matrox cards at the moment. Don´t know, if they have an OpenGL extension for it (i´ve never seen one). You should check out their pages for more information.
I was asking about the use of them on the r300/r350 based cards specifically, which do support it (its a DX9 feature after-all, and the D3D demos of it run fine).
I understand that the uber/super buffers are still not finalized, however the current spec of them is implemented in the ATi drivers from what Ive seen, and I was hoping to find some info on them.
Originally posted by DopeFish: Ive read those, an the most info they contain about how to use it under OpenGL is that you need to use UberBuffers to do so. Nothing more.
It’s a two-step process: You have to use a fragment program to render to a floating point buffer, and then use that floating point buffer as a vertex buffer.
You supply your geometric data as input to the fragment program and you issue texture reads for the displacement mapping part (you can do it adaptive or not).
The generation of the vertex data is just rasterising a rectangle. The fragment program will be run for each component of the fp buffer et voilà
This is a generic technique, you can use it to generate vertices based on any kind of data (NURBS anyone?).
Heck, you don’t even need to generate vertices at all, you can generate any kind of data (physics, photon maps, etc).
[This message has been edited by evanGLizr (edited 07-09-2003).]
too bad uberbuffers (actually überbuffers… funny typo when moved the word to english) aren’t yet officially in the drivers…
to ati: how long do you think will it go till we can see specs and an official insertion of GL_ATI_uber_buffers in the extensionstring? i know its yet in the drivers in some sort… but guessing the parameters just from… brain… is a bit difficult
or any other way to get to infos?
i hope it helps out of the rendertexture mess we have currently (all the wgl crap, and the pbuffer wich needs pixelformat and context and device context and all has to fit in some or the other way… bah)…
And i hope it now will become a ATI extension… its looks like an ARB workgroup has been on this several month now, so an ARB_super_buffers would be better… ( and thats a more correct translation )
I have made a sample fp & vp program that uses short indexes sent to the vp that generates the actual vertex (x,y) coords and the z is taken from a vertex attrib array directly from a pbuffer image stored in mem. this way you can generate rather simple displacement maps. I also use this for shadow volume creation out of shadow maps and IBR stuff…
It would be very easy if any card vendor made an extension that generates the x,y vertex so I dont need to ent the index data all the time.
davepermen : I’ve read as much as i could about uber_buffers, but i have never seen ATI_uber_buffers… only a purposed ARB one ( from the december meeting), is this the same, or do you have some extra info to give me here?
Originally posted by Mazy:
davepermen : I’ve read as much as i could about uber_buffers, but i have never seen ATI_uber_buffers… only a purposed ARB one ( from the december meeting), is this the same, or do you have some extra info to give me here?
Originally posted by Mazy: except for the postfix ATI, it looks exactly as the ARB proposal
possible… you have any infos about the ARB proposal? pseudo specs? i haven’t found any while looking around the last night (okay, i was ****ing tierd, too )