[GEM-dev] frambuffer and Vertex Texture Fetching

cyrille henry cyrille.henry at la-kitchen.fr
Sun Apr 6 13:45:52 CEST 2008



marius schebella a écrit :
> cyrille,
> I am using a variation of your patch to get my vertex morphing working. 
> is just need to figure out a way to save 3d objects as rgb images...
hum.
a shader can do such thing i think.

the vertex shader should get XYZ position and convert it to rgb color : this is not very hard.
but you'll also have to map your shape on a plane in the vertex shader in order to get a usable image.
this can be done by example converting the XYZ in polar coordinate and then mapping this to a square.

well. if you do this, then please send it to the list, it will certainly interest other people...

cyrille


> marius.
> 
> cyrille henry wrote:
>> hello,
>>
>> the good new is that things still can work as it was.
>> just replace rgb32 with rgb.
>> the old version does not use the same primitive, so i's possible there 
>> is more vertex now. this can explain the 70->130% diference.
>>
>> we can investigate, i am not sure your card is able to use this 
>> acceleration.
>>
>> with a nvidia 7700, this patch use only few %, so the change is really 
>> important!
>>
>> cyrille
>>
>> marius schebella a écrit :
>>> hi,
>>> when I click on type byte, format rgb32 then I get this printout
>>> [gemframebuffer]: type is BYTE, 5121
>>> [gemframebuffer]: format is GL_RGB_FLOAT32_ATI, 32992
>>> but it starts eating up all my cpu.
>>> with the old version I cud run dim 512 512 at ~70%
>>> with the new version I am +130%
>>> this is on os x 10.5.2 with ati X1600.
>>> marius.
>>>
>>> cyrille henry wrote:
>>>> hello,
>>>> i'm currently investigating the use of framebuffer to create a 
>>>> texture in order to use it as a vertex displacement.
>>>> this has already been discuss in this list, but new stuff in 
>>>> framebuffer makes me try again.
>>>>
>>>> i'm specially motived because it's the last things that prevent me 
>>>> trying physical modeling in glsl.
>>>>
>>>>
>>>>
>>>> having a look at framebuffer, i noticed strange things :
>>>> -changing type or format does not init the framebuffer, you have to 
>>>> change dim, or rectangle (mode) in order to init it.
>>>> (i don't know why)
>>>>
>>>> -in void gemframebuffer :: typeMess(char* type), should :
>>>>
>>>>     else if (!strcmp(type, "FLOAT")){
>>>>       post("type is GL_FLOAT, %d",m_type);
>>>>       m_type = GL_FLOAT;
>>>>       return;
>>>>
>>>> be replaced by :     else if (!strcmp(type, "FLOAT")){
>>>>       m_type = GL_FLOAT;
>>>>       post("type is GL_FLOAT, %d",m_type);
>>>>       return;
>>>> ???
>>>> (it's also the same in formatMess)
>>>>
>>>> anyway. here are the good news :
>>>> i add (and commit) a RGB32 format corresponding to        
>>>> m_internalformat = GL_RGB_FLOAT32_ATI;
>>>> #ifdef __APPLE__
>>>>        m_format = GL_BGR;
>>>> #else        m_format = GL_RGB;
>>>> #endif
>>>> (i  don't know if apple definition is ok).
>>>>
>>>> but the internal format GL_RGB_FLOAT32_ATI was mandatory in order to 
>>>> have an efficient implementation of vertex texture fetching.
>>>>
>>>> so here is an example. it still need to be cleaned, but i'd like to 
>>>> know if it work on other computer.
>>>> (here, it's about 50 time faster than previous example i send to 
>>>> this list)
>>>>
>>>> please update/compile and test!
>>>>
>>>> cyrille
>>>>
>>>>
>>>> ------------------------------------------------------------------------ 
>>>>
>>>>
>>>> _______________________________________________
>>>> GEM-dev mailing list
>>>> GEM-dev at iem.at
>>>> http://lists.puredata.info/listinfo/gem-dev
>>>
>>>
>>>
>>
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> GEM-dev mailing list
> GEM-dev at iem.at
> http://lists.puredata.info/listinfo/gem-dev




More information about the GEM-dev mailing list