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
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@iem.at http://lists.puredata.info/listinfo/gem-dev
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@iem.at http://lists.puredata.info/listinfo/gem-dev
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... 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@iem.at http://lists.puredata.info/listinfo/gem-dev
hello,
http://techreport.com/discussions.x/8872
look like it's not possible with your hardware to get this patch working at full speed.
could anyone else test this patch please?
cyrille
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... 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@iem.at http://lists.puredata.info/listinfo/gem-dev
GEM-dev mailing list GEM-dev@iem.at http://lists.puredata.info/listinfo/gem-dev
I tried this patch on my machine with a GeForce 8600M GT, but I couldn't get it to do anything. Here's the transcript:
.hc
On Apr 5, 2008, at 7:35 PM, cyrille henry wrote:
hello,
http://techreport.com/discussions.x/8872
look like it's not possible with your hardware to get this patch working at full speed.
could anyone else test this patch please?
cyrille
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... 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@iem.at http://lists.puredata.info/listinfo/gem-dev
GEM-dev mailing list GEM-dev@iem.at http://lists.puredata.info/listinfo/gem-dev
GEM-dev mailing list GEM-dev@iem.at http://lists.puredata.info/listinfo/gem-dev
------------------------------------------------------------------------ ----
you need todays gem version. marius.
Hans-Christoph Steiner wrote:
I tried this patch on my machine with a GeForce 8600M GT, but I couldn't get it to do anything. Here's the transcript:
.hc
On Apr 5, 2008, at 7:35 PM, cyrille henry wrote:
hello,
http://techreport.com/discussions.x/8872
look like it's not possible with your hardware to get this patch working at full speed.
could anyone else test this patch please?
cyrille
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... 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@iem.at http://lists.puredata.info/listinfo/gem-dev
GEM-dev mailing list GEM-dev@iem.at http://lists.puredata.info/listinfo/gem-dev
GEM-dev mailing list GEM-dev@iem.at http://lists.puredata.info/listinfo/gem-dev
http://at.or.at/hans/
marius schebella a écrit :
you need todays gem version.
yes, but i don't know if it will solve everything.
why do the : [glsl_program]: Link failed! it should have linked even with older gem version. it is also strange that it try to link many time.
so, the 1st thing to do is to compile the latest gem. then, we will see...
cyrille
marius.
Hans-Christoph Steiner wrote:
I tried this patch on my machine with a GeForce 8600M GT, but I couldn't get it to do anything. Here's the transcript:
.hc
On Apr 5, 2008, at 7:35 PM, cyrille henry wrote:
hello,
http://techreport.com/discussions.x/8872
look like it's not possible with your hardware to get this patch working at full speed.
could anyone else test this patch please?
cyrille
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... 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@iem.at > http://lists.puredata.info/listinfo/gem-dev
GEM-dev mailing list GEM-dev@iem.at http://lists.puredata.info/listinfo/gem-dev
GEM-dev mailing list GEM-dev@iem.at http://lists.puredata.info/listinfo/gem-dev
http://at.or.at/hans/
Hello Cyrille, Here a problem on PowerBook G4, MacOSX.4.11, GeForce FX Go5200 :
glsl_program]: Info_log: [glsl_program]: ERROR: Implementation limit of 0 active vertex shader samplers (e.g., maximum number of supported image units) exceeded, vertex shader uses 1 samplers
[glsl_program]: ARB Link failed! [glsl_program]: vertex shader running in hardware [glsl_program]: fragment shader running in hardware
I will try on MacBookPro later. ++
Jack
Le 6 avr. 08 à 01:35, cyrille henry a écrit :
hello,
http://techreport.com/discussions.x/8872
look like it's not possible with your hardware to get this patch working at full speed.
could anyone else test this patch please?
cyrille
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... 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@iem.at http://lists.puredata.info/listinfo/gem-dev
GEM-dev mailing list GEM-dev@iem.at http://lists.puredata.info/listinfo/gem-dev
GEM-dev mailing list GEM-dev@iem.at http://lists.puredata.info/listinfo/gem-dev
well, the error is self explanatory. your hardware limit is 0 vertex shader sample maximum, and you try to load 1.
so, this is a hardware limitation.
in order to use this patch, you need a glsl 3.0 hardware i think. i realize that this is not very used yet.
thanks for testing this
cyrille
Jack a écrit :
Hello Cyrille, Here a problem on PowerBook G4, MacOSX.4.11, GeForce FX Go5200 :
glsl_program]: Info_log: [glsl_program]: ERROR: Implementation limit of 0 active vertex shader samplers (e.g., maximum number of supported image units) exceeded, vertex shader uses 1 samplers
[glsl_program]: ARB Link failed! [glsl_program]: vertex shader running in hardware [glsl_program]: fragment shader running in hardware
I will try on MacBookPro later. ++
Jack
Le 6 avr. 08 à 01:35, cyrille henry a écrit :
hello,
http://techreport.com/discussions.x/8872
look like it's not possible with your hardware to get this patch working at full speed.
could anyone else test this patch please?
cyrille
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... 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@iem.at http://lists.puredata.info/listinfo/gem-dev
GEM-dev mailing list GEM-dev@iem.at http://lists.puredata.info/listinfo/gem-dev
GEM-dev mailing list GEM-dev@iem.at http://lists.puredata.info/listinfo/gem-dev
GEM-dev mailing list GEM-dev@iem.at http://lists.puredata.info/listinfo/gem-dev
With the last version it's different, the fractal picture disappear and i get only a white square :
reading startup file: /Users/rybn12/.pdrc libdir loader $Revision: 1.8 $ written by Hans-Christoph Steiner hans@at.or.at compiled on Apr 6 2008 at 04:09:45 compiled against Pd version 0.40.3.extended-20080406 GEM: Graphics Environment for Multimedia GEM: ver: 0.91-cvs GEM: compiled: Apr 6 2008 GEM: maintained by IOhannes m zmoelnig GEM: Authors : Mark Danks (original version) GEM: Chris Clepper GEM: James Tittle GEM: IOhannes m zmoelnig GEM: with help by Guenter Geiger, Daniel Heckenberg, Cyrille Henry, et al. GEM: using AltiVec optimization libdir_loader: added cyclone to the global classpath libdir_loader: added zexy to the global classpath libdir_loader: added creb to the global classpath libdir_loader: added cxc to the global classpath libdir_loader: added iemlib to the global classpath libdir_loader: added list-abs to the global classpath libdir_loader: added mapping to the global classpath libdir_loader: added markex to the global classpath libdir_loader: added maxlib to the global classpath libdir_loader: added memento to the global classpath libdir_loader: added mjlib to the global classpath libdir_loader: added motex to the global classpath libdir_loader: added oscx to the global classpath libdir_loader: added pddp to the global classpath libdir_loader: added pdogg to the global classpath libdir_loader: added pixeltango to the global classpath libdir_loader: added pmpd to the global classpath libdir_loader: added rradical to the global classpath libdir_loader: added sigpack to the global classpath libdir_loader: added smlib to the global classpath libdir_loader: added toxy to the global classpath libdir_loader: added unauthorized to the global classpath libdir_loader: added pan to the global classpath libdir_loader: added freeverb to the global classpath libdir_loader: added hcs to the global classpath libdir_loader: added jmmmp to the global classpath libdir_loader: added ext13 to the global classpath libdir_loader: added hardware to the global classpath libdir_loader: added deprecated to the global classpath libdir_loader: added flatspace to the global classpath [gemframebuffer]: default format is GL_RGB, 6407 [gemframebuffer]: default type is BYTE, 5121 [gemframebuffer]: type is BYTE, 5121 [gemframebuffer]: format is GL_RGB_FLOAT32_ATI, 6407 [pix_image]: GEM: loaded image: /Users/rybn12/Desktop/Mickael/ deforme_vertex_texture 2/test.jpg [pix_texture]: using mode 0: TEXTURE_2D GemwinMac: width - 500 height - 500 GemWindow Activate err = 0 GLEW version 1.5.0 GEM: Start rendering error: [glsl_vertex]: need to load a shader ... you might be able to track this down from the Find menu. error: [glsl_fragment]: need to load a shader [gemframebuffer]: using rectmode 0:GL_TEXTURE_2D [gemframebuffer]: using type: BYTE [gemframebuffer]: using texunit: 0 linking: link 1.4013e-45 0 linking: link 1.4013e-45 2.8026e-45 [glsl_program]: Info_log: [glsl_program]: ERROR: Implementation limit of 0 active vertex shader samplers (e.g., maximum number of supported image units) exceeded, vertex shader uses 1 samplers
[glsl_program]: ARB Link failed! [glsl_program]: vertex shader running in hardware [glsl_program]: fragment shader running in hardware GL: invalid framebuffer operation GL: invalid framebuffer operation GL: invalid framebuffer operation GL: invalid framebuffer operation GL: invalid framebuffer operation GL: invalid framebuffer operation GL: invalid framebuffer operation GL: invalid framebuffer operation GL: invalid framebuffer operation GL: invalid framebuffer operation
Le 6 avr. 08 à 14:15, Jack a écrit :
Hello Cyrille, Here a problem on PowerBook G4, MacOSX.4.11, GeForce FX Go5200 :
glsl_program]: Info_log: [glsl_program]: ERROR: Implementation limit of 0 active vertex shader samplers (e.g., maximum number of supported image units) exceeded, vertex shader uses 1 samplers
[glsl_program]: ARB Link failed! [glsl_program]: vertex shader running in hardware [glsl_program]: fragment shader running in hardware
I will try on MacBookPro later. ++
Jack
Le 6 avr. 08 à 01:35, cyrille henry a écrit :
hello,
http://techreport.com/discussions.x/8872
look like it's not possible with your hardware to get this patch working at full speed.
could anyone else test this patch please?
cyrille
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... 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@iem.at http://lists.puredata.info/listinfo/gem-dev
GEM-dev mailing list GEM-dev@iem.at http://lists.puredata.info/listinfo/gem-dev
GEM-dev mailing list GEM-dev@iem.at http://lists.puredata.info/listinfo/gem-dev
GEM-dev mailing list GEM-dev@iem.at http://lists.puredata.info/listinfo/gem-dev
ok. probably because rgb32 was not recognise, so your framebuffer still was in int. with the new gem version rgb32 works, so it's normal that there is a difference.
it's also normal that it's still did not work because of your hardware limitation. i can't say more.
do you have a nvidia or an ati in your macbookpro? as the ati X1000 familly are not compatible with this, it worth a try only if you have an nvidia one.
cyrille
Jack a écrit :
With the last version it's different, the fractal picture disappear and i get only a white square :
reading startup file: /Users/rybn12/.pdrc libdir loader $Revision: 1.8 $ written by Hans-Christoph Steiner hans@at.or.at compiled on Apr 6 2008 at 04:09:45 compiled against Pd version 0.40.3.extended-20080406 GEM: Graphics Environment for Multimedia GEM: ver: 0.91-cvs GEM: compiled: Apr 6 2008 GEM: maintained by IOhannes m zmoelnig GEM: Authors : Mark Danks (original version) GEM: Chris Clepper GEM: James Tittle GEM: IOhannes m zmoelnig GEM: with help by Guenter Geiger, Daniel Heckenberg, Cyrille Henry, et al. GEM: using AltiVec optimization libdir_loader: added cyclone to the global classpath libdir_loader: added zexy to the global classpath libdir_loader: added creb to the global classpath libdir_loader: added cxc to the global classpath libdir_loader: added iemlib to the global classpath libdir_loader: added list-abs to the global classpath libdir_loader: added mapping to the global classpath libdir_loader: added markex to the global classpath libdir_loader: added maxlib to the global classpath libdir_loader: added memento to the global classpath libdir_loader: added mjlib to the global classpath libdir_loader: added motex to the global classpath libdir_loader: added oscx to the global classpath libdir_loader: added pddp to the global classpath libdir_loader: added pdogg to the global classpath libdir_loader: added pixeltango to the global classpath libdir_loader: added pmpd to the global classpath libdir_loader: added rradical to the global classpath libdir_loader: added sigpack to the global classpath libdir_loader: added smlib to the global classpath libdir_loader: added toxy to the global classpath libdir_loader: added unauthorized to the global classpath libdir_loader: added pan to the global classpath libdir_loader: added freeverb to the global classpath libdir_loader: added hcs to the global classpath libdir_loader: added jmmmp to the global classpath libdir_loader: added ext13 to the global classpath libdir_loader: added hardware to the global classpath libdir_loader: added deprecated to the global classpath libdir_loader: added flatspace to the global classpath [gemframebuffer]: default format is GL_RGB, 6407 [gemframebuffer]: default type is BYTE, 5121 [gemframebuffer]: type is BYTE, 5121 [gemframebuffer]: format is GL_RGB_FLOAT32_ATI, 6407 [pix_image]: GEM: loaded image: /Users/rybn12/Desktop/Mickael/deforme_vertex_texture 2/test.jpg [pix_texture]: using mode 0: TEXTURE_2D GemwinMac: width - 500 height - 500 GemWindow Activate err = 0 GLEW version 1.5.0 GEM: Start rendering error: [glsl_vertex]: need to load a shader ... you might be able to track this down from the Find menu. error: [glsl_fragment]: need to load a shader [gemframebuffer]: using rectmode 0:GL_TEXTURE_2D [gemframebuffer]: using type: BYTE [gemframebuffer]: using texunit: 0 linking: link 1.4013e-45 0 linking: link 1.4013e-45 2.8026e-45 [glsl_program]: Info_log: [glsl_program]: ERROR: Implementation limit of 0 active vertex shader samplers (e.g., maximum number of supported image units) exceeded, vertex shader uses 1 samplers
[glsl_program]: ARB Link failed! [glsl_program]: vertex shader running in hardware [glsl_program]: fragment shader running in hardware GL: invalid framebuffer operation GL: invalid framebuffer operation GL: invalid framebuffer operation GL: invalid framebuffer operation GL: invalid framebuffer operation GL: invalid framebuffer operation GL: invalid framebuffer operation GL: invalid framebuffer operation GL: invalid framebuffer operation GL: invalid framebuffer operation
Le 6 avr. 08 à 14:15, Jack a écrit :
Hello Cyrille, Here a problem on PowerBook G4, MacOSX.4.11, GeForce FX Go5200 :
glsl_program]: Info_log: [glsl_program]: ERROR: Implementation limit of 0 active vertex shader samplers (e.g., maximum number of supported image units) exceeded, vertex shader uses 1 samplers
[glsl_program]: ARB Link failed! [glsl_program]: vertex shader running in hardware [glsl_program]: fragment shader running in hardware
I will try on MacBookPro later. ++
Jack
Le 6 avr. 08 à 01:35, cyrille henry a écrit :
hello,
http://techreport.com/discussions.x/8872
look like it's not possible with your hardware to get this patch working at full speed.
could anyone else test this patch please?
cyrille
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... 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@iem.at > http://lists.puredata.info/listinfo/gem-dev
GEM-dev mailing list GEM-dev@iem.at http://lists.puredata.info/listinfo/gem-dev
GEM-dev mailing list GEM-dev@iem.at http://lists.puredata.info/listinfo/gem-dev
GEM-dev mailing list GEM-dev@iem.at http://lists.puredata.info/listinfo/gem-dev
Le 6 avr. 08 à 16:20, cyrille henry a écrit :
ok. probably because rgb32 was not recognise, so your framebuffer still was in int. with the new gem version rgb32 works, so it's normal that there is a difference.
it's also normal that it's still did not work because of your hardware limitation. i can't say more.
do you have a nvidia or an ati in your macbookpro? as the ati X1000 familly are not compatible with this, it worth a try only if you have an nvidia one.
Yes, i have a ATI Radeon X1600 on the macbookpro and it doesn't work. Thanx. ++
Jack
cyrille
Jack a écrit :
With the last version it's different, the fractal picture disappear and i get only a white square : reading startup file: /Users/rybn12/.pdrc libdir loader $Revision: 1.8 $ written by Hans-Christoph Steiner hans@at.or.at compiled on Apr 6 2008 at 04:09:45 compiled against Pd version 0.40.3.extended-20080406 GEM: Graphics Environment for Multimedia GEM: ver: 0.91-cvs GEM: compiled: Apr 6 2008 GEM: maintained by IOhannes m zmoelnig GEM: Authors : Mark Danks (original version) GEM: Chris Clepper GEM: James Tittle GEM: IOhannes m zmoelnig GEM: with help by Guenter Geiger, Daniel Heckenberg, Cyrille Henry, et al. GEM: using AltiVec optimization libdir_loader: added cyclone to the global classpath libdir_loader: added zexy to the global classpath libdir_loader: added creb to the global classpath libdir_loader: added cxc to the global classpath libdir_loader: added iemlib to the global classpath libdir_loader: added list-abs to the global classpath libdir_loader: added mapping to the global classpath libdir_loader: added markex to the global classpath libdir_loader: added maxlib to the global classpath libdir_loader: added memento to the global classpath libdir_loader: added mjlib to the global classpath libdir_loader: added motex to the global classpath libdir_loader: added oscx to the global classpath libdir_loader: added pddp to the global classpath libdir_loader: added pdogg to the global classpath libdir_loader: added pixeltango to the global classpath libdir_loader: added pmpd to the global classpath libdir_loader: added rradical to the global classpath libdir_loader: added sigpack to the global classpath libdir_loader: added smlib to the global classpath libdir_loader: added toxy to the global classpath libdir_loader: added unauthorized to the global classpath libdir_loader: added pan to the global classpath libdir_loader: added freeverb to the global classpath libdir_loader: added hcs to the global classpath libdir_loader: added jmmmp to the global classpath libdir_loader: added ext13 to the global classpath libdir_loader: added hardware to the global classpath libdir_loader: added deprecated to the global classpath libdir_loader: added flatspace to the global classpath [gemframebuffer]: default format is GL_RGB, 6407 [gemframebuffer]: default type is BYTE, 5121 [gemframebuffer]: type is BYTE, 5121 [gemframebuffer]: format is GL_RGB_FLOAT32_ATI, 6407 [pix_image]: GEM: loaded image: /Users/rybn12/Desktop/Mickael/ deforme_vertex_texture 2/test.jpg [pix_texture]: using mode 0: TEXTURE_2D GemwinMac: width - 500 height - 500 GemWindow Activate err = 0 GLEW version 1.5.0 GEM: Start rendering error: [glsl_vertex]: need to load a shader ... you might be able to track this down from the Find menu. error: [glsl_fragment]: need to load a shader [gemframebuffer]: using rectmode 0:GL_TEXTURE_2D [gemframebuffer]: using type: BYTE [gemframebuffer]: using texunit: 0 linking: link 1.4013e-45 0 linking: link 1.4013e-45 2.8026e-45 [glsl_program]: Info_log: [glsl_program]: ERROR: Implementation limit of 0 active vertex shader samplers (e.g., maximum number of supported image units) exceeded, vertex shader uses 1 samplers [glsl_program]: ARB Link failed! [glsl_program]: vertex shader running in hardware [glsl_program]: fragment shader running in hardware GL: invalid framebuffer operation GL: invalid framebuffer operation GL: invalid framebuffer operation GL: invalid framebuffer operation GL: invalid framebuffer operation GL: invalid framebuffer operation GL: invalid framebuffer operation GL: invalid framebuffer operation GL: invalid framebuffer operation GL: invalid framebuffer operation Le 6 avr. 08 à 14:15, Jack a écrit :
Hello Cyrille, Here a problem on PowerBook G4, MacOSX.4.11, GeForce FX Go5200 :
glsl_program]: Info_log: [glsl_program]: ERROR: Implementation limit of 0 active vertex shader samplers (e.g., maximum number of supported image units) exceeded, vertex shader uses 1 samplers
[glsl_program]: ARB Link failed! [glsl_program]: vertex shader running in hardware [glsl_program]: fragment shader running in hardware
I will try on MacBookPro later. ++
Jack
Le 6 avr. 08 à 01:35, cyrille henry a écrit :
hello,
http://techreport.com/discussions.x/8872
look like it's not possible with your hardware to get this patch working at full speed.
could anyone else test this patch please?
cyrille
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... 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@iem.at >> http://lists.puredata.info/listinfo/gem-dev > > >
GEM-dev mailing list GEM-dev@iem.at http://lists.puredata.info/listinfo/gem-dev
GEM-dev mailing list GEM-dev@iem.at http://lists.puredata.info/listinfo/gem-dev
GEM-dev mailing list GEM-dev@iem.at http://lists.puredata.info/listinfo/gem-dev
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@iem.at http://lists.puredata.info/listinfo/gem-dev
GEM-dev mailing list GEM-dev@iem.at http://lists.puredata.info/listinfo/gem-dev
hello
works fine on my machine mac book pro 10.5.2 NVIDIA 8600 needs 25% cpu
Matthias Am 05.04.2008 um 15:13 schrieb cyrille henry:
please update/compile and test!
cyrille < deforme_vertex_texture .tar.gz>_______________________________________________ GEM-dev mailing list GEM-dev@iem.at http://lists.puredata.info/listinfo/gem-dev
-
cyrille henry -
Hans-Christoph Steiner -
Jack -
marius schebella -
Matthias Neuenhofer