PDA

View Full Version : Displacement mapping



DopeFish
07-08-2003, 02:53 AM
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?

Jan
07-08-2003, 03:47 AM
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.

Jan.

DopeFish
07-08-2003, 04:10 AM
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.

Azrael
07-08-2003, 10:44 AM
ATI and NVIDIA seem to have a paper about SuperBuffers, perhaps it's explained there, how to use it.

see you,
Azrael

[This message has been edited by Azrael (edited 07-08-2003).]

Ostsol
07-08-2003, 12:33 PM
http://www.ati.com/developer/gdc/GDC2003-DisplacementMapping.pdf http://www.ati.com/developer/gdc/GDC2003-DisplacementMappingNotes.pdf

DopeFish
07-08-2003, 08:11 PM
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.

evanGLizr
07-09-2003, 04:28 AM
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).]

Baerbel
07-10-2003, 01:55 PM
There is an Effect-Demo at the ATI-Dev-Websites wich includes source-code for displacement-mapping in directx. http://meshuggah.4fo.de/
mfG
Baerbel

DopeFish
07-11-2003, 03:12 AM
Thnx for the replies.

I can see its going to take me a while to get my head around uber buffers

Mazy
07-11-2003, 03:19 AM
It seems like a lot of fragment calculations if you want adaptive generation. is it even possible?

davepermen
07-11-2003, 03:53 AM
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 http://www.opengl.org/discussion_boards/ubb/biggrin.gif

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)..

Mazy
07-11-2003, 04:05 AM
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 http://www.opengl.org/discussion_boards/ubb/smile.gif )

davepermen
07-11-2003, 04:45 AM
yeah, should get ARB_uber_buffers..

i just HATE that pbuffer crap i currently have to work with.. not to say its the only reason my app is not crossplatform..

and the ATI_uberbuffer function names look very promising.... http://www.opengl.org/discussion_boards/ubb/biggrin.gif can't wait.

ToolTech
07-11-2003, 04:58 AM
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.

Mazy
07-11-2003, 05:54 AM
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?

davepermen
07-11-2003, 07:00 AM
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?

the extra info i have is not much...

its essencially that:

atioglxx.dll has these (http://\"http://www.itstudents.ch/users/dave/files/glextensions.txt\") extensions, including the "GL_ATI_uber_buffers".

they are not exposed all in the glGetString yet (so aren't the GL_GL2_ exts..)..


there are these functions in the dll that look like they fit to GL_ATI_uber_buffers:



glVertexAttribMemATI
glVertexArrayMemATI
glSwapBuffersATI
glIsFramebufferATI
glGetFramebufferATI
glBindFramebufferATI
glDeleteFramebufferATI
glNewFramebufferATI
glDetachMemATI
glAttachMemATI
glInvalidateMemATI
glGetMemSubImage1DATI
glGetMemSubImage2DATI
glGetMemSubImage3DATI
glGetMemImageATI
glMemCopy1DATI
glMemCopy2DATI
glMemCopy3DATI
glCopyMemSubImage1DATI
glCopyMemSubImage2DATI
glMemSubImage1DATI
glMemSubImage2DATI
glMemSubImage3DATI
glCopyMemImage1DATI
glCopyMemImage2DATI
glMemImageATI
glIsMemATI
glGetMemATI
glGetBaseMemATI
glGetSubMemATI
glGetMemPropertyATI
glDeleteMemATI
glCloneMemATI
glGetMemInfoLogATI
glAllocMem1DATI
glAllocMem2DATI
glAllocMem3DATI


thats all i know.. i registered actually to the ati devrel, but never really got anything from them so i dunno more..


[This message has been edited by davepermen (edited 07-11-2003).]

Mazy
07-11-2003, 07:35 AM
except for the postfix ATI, it looks exactly as the ARB proposal

davepermen
07-11-2003, 07:49 AM
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 http://www.opengl.org/discussion_boards/ubb/biggrin.gif)

Mazy
07-11-2003, 08:06 AM
http://developer.nvidia.com/docs/IO/4449/SUPP/GDC2003_OGL_ARBSuperbuffers.pdf

and ofcourse there are notes here and there in the meeting notes
http://www.opengl.org/developers/about/arb/notes/meeting_note_2003-03-11.html#sb http://www.opengl.org/developers/about/arb/notes/meeting_note_2002-12-10.html#membuf


[This message has been edited by Mazy (edited 07-11-2003).]