[GEM-dev] frambuffer and Vertex Texture Fetching

[marius schebella]

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