hello,
i investigate a bit more the vertex displacement problem. so i've got a 8 bit texture that is rendered in a FLOAT framebuffer, in order to convert it to 32 bit. then, the frambuffer texture is used in a shader to distord a primitive
i have to strangely mix mode 0 and mode 1 in the patch to make it work, and this is very ineficient (just like in 8bit mode).
framebuffer and fragment shader usually work in mode 0 and 1 on my computer.
see patch for more.
thanks to have a look. using texture in vertex shader would be great...
thanks Cyrille
hello cyrille, I did not know that this was possible at all. I always thought there are only 4 vertices involved in the primitive and now I see that it is possible to do displacement on pixel basis. I tested the patch and on my system (osx, ATY,RadeonX1600) I can use A 0, C 0, K 1 (B 1 or 0 does not make a difference) A 1, C 1, K 1 (B - no difference) and also your combinations with 256, 0.00390625. so for me it works just fine. the differences may be related to different hardware/os. I also don't need the line #extension GL_ARB_texture_rectangle : enable what do you mean with "using texture in vertex shader would be great..." do you think this should work without gemframebuffer? marius.
cyrille henry wrote:
hello,
i investigate a bit more the vertex displacement problem. so i've got a 8 bit texture that is rendered in a FLOAT framebuffer, in order to convert it to 32 bit. then, the frambuffer texture is used in a shader to distord a primitive
i have to strangely mix mode 0 and mode 1 in the patch to make it work, and this is very ineficient (just like in 8bit mode).
framebuffer and fragment shader usually work in mode 0 and 1 on my computer.
see patch for more.
thanks to have a look. using texture in vertex shader would be great...
thanks Cyrille
GEM-dev mailing list GEM-dev@iem.at http://lists.puredata.info/listinfo/gem-dev
marius schebella a écrit :
hello cyrille, I did not know that this was possible at all. I always thought there are only 4 vertices involved in the primitive and now I see that it is possible to do displacement on pixel basis.
well. ther is only 4 vertices on a square. that is why i use a newWave primitive. displacement is made on every evrtice of this primitive. but the displacement factor comme from a texture.
I tested the patch and on my system (osx, ATY,RadeonX1600) I can use A 0, C 0, K 1 (B 1 or 0 does not make a difference) A 1, C 1, K 1 (B - no difference) and also your combinations with 256, 0.00390625. so for me it works just fine.
great! can you have a look at the performance.
for me, when it work it's very ineficient.... but it should be very fast. (you can by exemple add more vertice on the primitive)
the differences may be related to different hardware/os.
yep. i'm on linux/nvidia
could someone else try this patch on diferents system?
I also don't need the line #extension GL_ARB_texture_rectangle : enable
in fact, if i remove it, i have a warning at the shader compilation, but it also work.
what do you mean with "using texture in vertex shader would be great..."
i mean that i would be happy if i could make this patch to work just like in your computer.
do you think this should work without gemframebuffer?
no. in fact, using texture in the vertex shader is efficient only when using 32 bit texture, and this on only possible with framebuffer. see chris mail on this list for more details.
cyrille
marius.
cyrille henry wrote:
hello,
i investigate a bit more the vertex displacement problem. so i've got a 8 bit texture that is rendered in a FLOAT framebuffer, in order to convert it to 32 bit. then, the frambuffer texture is used in a shader to distord a primitive
i have to strangely mix mode 0 and mode 1 in the patch to make it work, and this is very ineficient (just like in 8bit mode).
framebuffer and fragment shader usually work in mode 0 and 1 on my computer.
see patch for more.
thanks to have a look. using texture in vertex shader would be great...
thanks 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 did not see the the newWave before, but now I understand it and it makes sense to me... the performance says dsp ~22%(with newWave 60). with newWave 100: 30% and with newWave 256: ~65-70%. is that what you expected? I also added some factor to the R G and B values, which looks nice. marius.
cyrille henry wrote:
marius schebella a écrit :
hello cyrille, I did not know that this was possible at all. I always thought there are only 4 vertices involved in the primitive and now I see that it is possible to do displacement on pixel basis.
well. ther is only 4 vertices on a square. that is why i use a newWave primitive. displacement is made on every evrtice of this primitive. but the displacement factor comme from a texture.
I tested the patch and on my system (osx, ATY,RadeonX1600) I can use A 0, C 0, K 1 (B 1 or 0 does not make a difference) A 1, C 1, K 1 (B - no difference) and also your combinations with 256, 0.00390625. so for me it works just fine.
great! can you have a look at the performance.
for me, when it work it's very ineficient.... but it should be very fast. (you can by exemple add more vertice on the primitive)
the differences may be related to different hardware/os.
yep. i'm on linux/nvidia
could someone else try this patch on diferents system?
I also don't need the line #extension GL_ARB_texture_rectangle : enable
in fact, if i remove it, i have a warning at the shader compilation, but it also work.
what do you mean with "using texture in vertex shader would be great..."
i mean that i would be happy if i could make this patch to work just like in your computer.
do you think this should work without gemframebuffer?
no. in fact, using texture in the vertex shader is efficient only when using 32 bit texture, and this on only possible with framebuffer. see chris mail on this list for more details.
cyrille
marius.
cyrille henry wrote:
hello,
i investigate a bit more the vertex displacement problem. so i've got a 8 bit texture that is rendered in a FLOAT framebuffer, in order to convert it to 32 bit. then, the frambuffer texture is used in a shader to distord a primitive
i have to strangely mix mode 0 and mode 1 in the patch to make it work, and this is very ineficient (just like in 8bit mode).
framebuffer and fragment shader usually work in mode 0 and 1 on my computer.
see patch for more.
thanks to have a look. using texture in vertex shader would be great...
thanks 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
uniform sampler2D MyTex; varying vec4 C; uniform float K; uniform float R; uniform float G; uniform float B; void main() { vec4 v = vec4(gl_Vertex); vec4 color = texture2D(MyTex, K*gl_MultiTexCoord0.st); v.z = color.r*R+color.g*G+color.b*B; C=color; gl_Position = gl_ModelViewProjectionMatrix * v; }
#N canvas 473 22 875 797 10; #X obj 407 63 gemhead; #X obj 480 340 pack 0 0; #X obj 501 320 t b f; #X msg 480 380 link $1 $2; #X floatatom 501 301 2 0 0 0 ID - -; #X floatatom 479 200 2 0 0 0 ID - -; #X obj 498 401 print linking; #X obj 407 554 pix_texture; #X msg 417 225 open deplace.frag; #X obj 424 624 bng 15 250 50 0 empty empty empty 0 -6 0 8 -262144 -1 -1; #X msg 479 625 1; #X obj 527 41 bng 15 250 50 0 empty empty empty 17 7 0 10 -262144 -1 -1; #X msg 74 38 create , 1; #X msg 76 61 0 , destroy; #X obj 34 262 gemhead 1; #X obj 34 344 gemframebuffer; #X obj 34 435 pix_image; #X obj 34 562 pix_texture; #X msg 154 536 mode $1; #X obj 154 514 tgl 15 0 empty empty empty 17 7 0 10 -262144 -1 -1 0 1; #X msg 61 537 quality $1; #X obj 61 517 tgl 15 0 empty empty empty 17 7 0 10 -262144 -1 -1 0 1; #X obj 407 40 tgl 15 0 empty empty empty 17 7 0 10 -262144 -1 -1 1 1; #X msg 36 17 color 1 0 0; #X msg 52 410 open test.jpg; #X obj 34 369 translateXYZ 0 0 -4; #X obj 34 597 square 4; #X msg 61 493 0; #X msg 56 317 mode 0 , type FLOAT , format RGBA , dim 256 256; #X msg 145 285 mode $1; #X obj 145 264 tgl 15 0 empty empty empty 17 7 0 10 -262144 -1 -1 0 1; #X obj 407 255 glsl_fragment; #X obj 407 158 glsl_vertex; #X obj 479 177 change; #X obj 501 275 change; #X obj 407 463 glsl_program; #X obj 35 97 gemwin; #X obj 407 599 rotateXYZ; #X floatatom 427 580 5 0 0 0 - - -; #X msg 546 433 K 256; #X msg 556 455 K 1; #X obj 56 294 loadbang; #X msg 421 136 open deplace0.vert; #X msg 442 106 open deplace1.vert; #X obj 542 63 bng 15 250 50 0 empty empty empty 17 7 0 10 -262144 -1 -1; #X text 554 40 mode 0; #X text 565 62 mode 1; #X msg 422 529 mode $1; #X text 481 528 this look like not being used; #X text 604 430 texture coordinate correction; #X text 208 262 A; #X text 194 518 B; #X text 627 49 C; #X text 687 473 D; #X obj 419 506 tgl 15 0 empty empty empty 17 7 0 10 -262144 -1 -1 0 1; #X text 444 505 E; #X text 46 666 working combination :; #X text 78 707 A 0 , B 1 , C1 , K 256; #X text 79 688 A 1 , B 0 , C 0 , K 0.003; #X obj 53 390 loadbang; #X text 156 489 rectangle=1; #X msg 570 477 K 0.00390625; #X text 78 737 A 0 , B 0 , C0 , K 1; #X text 206 738 (for me); #X text 205 754 (for me); #X text 78 753 A 1 , B 1 , C1 , K 1; #X msg 592 111 open deplace2.vert; #X obj 649 79 bng 15 250 50 0 empty empty empty 17 7 0 10 -262144 -1 -1; #X text 672 78 special1; #X msg 138 342 mode 0 , type FLOAT , format GL_RGB , dim 256 256 ; #X obj 633 603 random 100; #X obj 633 581 metro 1000; #X obj 629 557 tgl 15 0 empty empty empty 17 7 0 10 -262144 -1 -1 0 1; #X obj 633 629 * 0.2; #X obj 633 652 - 10; #X msg 619 689 $1 1000; #X obj 619 711 line; #X msg 613 739 R $1; #X obj 719 599 random 100; #X obj 719 577 metro 1000; #X obj 715 553 tgl 15 0 empty empty empty 17 7 0 10 -262144 -1 -1 0 1; #X obj 719 625 * 0.2; #X obj 719 648 - 10; #X msg 705 685 $1 1000; #X obj 705 707 line; #X msg 699 735 G $1; #X obj 796 599 random 100; #X obj 796 577 metro 1000; #X obj 792 553 tgl 15 0 empty empty empty 17 7 0 10 -262144 -1 -1 0 1; #X obj 796 625 * 0.2; #X obj 796 648 - 10; #X msg 782 685 $1 1000; #X obj 782 707 line; #X msg 776 735 B $1; #X msg 100 118 view 0 0 $1; #X floatatom 112 96 5 0 0 0 - - -; #X msg 163 66 lighting 0; #X msg 162 412 open $1; #X obj 164 383 openpanel; #X msg 238 388 bang; #X obj 331 710 dsp; #X floatatom 331 737 5 0 0 0 - - -; #X msg 483 658 1; #X text 417 699 gem not running 10%; #X text 420 715 60: 22%; #X text 418 735 100: 30%; #X text 418 755 256: 65%; #X obj 36 235 tgl 15 0 empty empty empty 17 7 0 10 -262144 -1 -1 1 1; #X obj 694 521 loadbang; #X obj 407 651 newWave 60; #X connect 0 0 32 0; #X connect 1 0 3 0; #X connect 2 0 1 0; #X connect 2 1 1 1; #X connect 3 0 6 0; #X connect 3 0 35 0; #X connect 4 0 2 0; #X connect 5 0 1 0; #X connect 7 0 37 0; #X connect 8 0 31 0; #X connect 9 0 109 0; #X connect 10 0 109 3; #X connect 11 0 42 0; #X connect 11 0 8 0; #X connect 12 0 36 0; #X connect 13 0 36 0; #X connect 14 0 15 0; #X connect 15 0 25 0; #X connect 15 1 7 1; #X connect 16 0 17 0; #X connect 17 0 26 0; #X connect 18 0 17 0; #X connect 19 0 18 0; #X connect 20 0 17 0; #X connect 21 0 20 0; #X connect 22 0 0 0; #X connect 23 0 36 0; #X connect 24 0 16 0; #X connect 25 0 16 0; #X connect 27 0 21 0; #X connect 28 0 15 0; #X connect 29 0 15 0; #X connect 30 0 29 0; #X connect 31 0 35 0; #X connect 31 1 34 0; #X connect 32 0 31 0; #X connect 32 1 33 0; #X connect 33 0 5 0; #X connect 34 0 4 0; #X connect 35 0 7 0; #X connect 37 0 109 0; #X connect 38 0 37 1; #X connect 39 0 35 0; #X connect 40 0 35 0; #X connect 41 0 28 0; #X connect 42 0 32 0; #X connect 43 0 32 0; #X connect 44 0 43 0; #X connect 44 0 8 0; #X connect 47 0 7 0; #X connect 54 0 47 0; #X connect 59 0 24 0; #X connect 61 0 35 0; #X connect 66 0 32 0; #X connect 67 0 66 0; #X connect 67 0 8 0; #X connect 69 0 15 0; #X connect 70 0 73 0; #X connect 71 0 70 0; #X connect 72 0 71 0; #X connect 73 0 74 0; #X connect 74 0 75 0; #X connect 75 0 76 0; #X connect 76 0 77 0; #X connect 77 0 35 0; #X connect 78 0 81 0; #X connect 79 0 78 0; #X connect 80 0 79 0; #X connect 81 0 82 0; #X connect 82 0 83 0; #X connect 83 0 84 0; #X connect 84 0 85 0; #X connect 85 0 35 0; #X connect 86 0 89 0; #X connect 87 0 86 0; #X connect 88 0 87 0; #X connect 89 0 90 0; #X connect 90 0 91 0; #X connect 91 0 92 0; #X connect 92 0 93 0; #X connect 93 0 35 0; #X connect 94 0 36 0; #X connect 95 0 94 0; #X connect 96 0 36 0; #X connect 97 0 16 0; #X connect 98 0 97 0; #X connect 99 0 98 0; #X connect 100 0 101 0; #X connect 102 0 109 1; #X connect 107 0 14 0; #X connect 108 0 72 0; #X connect 108 0 80 0; #X connect 108 0 88 0;
marius schebella a écrit :
I did not see the the newWave before, but now I understand it and it makes sense to me... the performance says dsp ~22%(with newWave 60). with newWave 100: 30% and with newWave 256: ~65-70%. is that what you expected?
i would expect less. is it the same with all contiguration (A,B,C)?
on my computer, it use 80% cpu with newWave 60...
cyrille
I also added some factor to the R G and B values, which looks nice. marius.
cyrille henry wrote:
marius schebella a écrit :
hello cyrille, I did not know that this was possible at all. I always thought there are only 4 vertices involved in the primitive and now I see that it is possible to do displacement on pixel basis.
well. ther is only 4 vertices on a square. that is why i use a newWave primitive. displacement is made on every evrtice of this primitive. but the displacement factor comme from a texture.
I tested the patch and on my system (osx, ATY,RadeonX1600) I can use A 0, C 0, K 1 (B 1 or 0 does not make a difference) A 1, C 1, K 1 (B - no difference) and also your combinations with 256, 0.00390625. so for me it works just fine.
great! can you have a look at the performance.
for me, when it work it's very ineficient.... but it should be very fast. (you can by exemple add more vertice on the primitive)
the differences may be related to different hardware/os.
yep. i'm on linux/nvidia
could someone else try this patch on diferents system?
I also don't need the line #extension GL_ARB_texture_rectangle : enable
in fact, if i remove it, i have a warning at the shader compilation, but it also work.
what do you mean with "using texture in vertex shader would be great..."
i mean that i would be happy if i could make this patch to work just like in your computer.
do you think this should work without gemframebuffer?
no. in fact, using texture in the vertex shader is efficient only when using 32 bit texture, and this on only possible with framebuffer. see chris mail on this list for more details.
cyrille
marius.
cyrille henry wrote:
hello,
i investigate a bit more the vertex displacement problem. so i've got a 8 bit texture that is rendered in a FLOAT framebuffer, in order to convert it to 32 bit. then, the frambuffer texture is used in a shader to distord a primitive
i have to strangely mix mode 0 and mode 1 in the patch to make it work, and this is very ineficient (just like in 8bit mode).
framebuffer and fragment shader usually work in mode 0 and 1 on my computer.
see patch for more.
thanks to have a look. using texture in vertex shader would be great...
thanks 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
ok, it only uses 20% with nW60 and ~53% with nW256. no difference between mode 0/1. the rest was just my (not optimized!) additions. marius.
cyrille henry wrote:
marius schebella a écrit :
I did not see the the newWave before, but now I understand it and it makes sense to me... the performance says dsp ~22%(with newWave 60). with newWave 100: 30% and with newWave 256: ~65-70%. is that what you expected?
i would expect less. is it the same with all contiguration (A,B,C)?
on my computer, it use 80% cpu with newWave 60...
cyrille
I also added some factor to the R G and B values, which looks nice. marius.
cyrille henry wrote:
marius schebella a écrit :
hello cyrille, I did not know that this was possible at all. I always thought there are only 4 vertices involved in the primitive and now I see that it is possible to do displacement on pixel basis.
well. ther is only 4 vertices on a square. that is why i use a newWave primitive. displacement is made on every evrtice of this primitive. but the displacement factor comme from a texture.
I tested the patch and on my system (osx, ATY,RadeonX1600) I can use A 0, C 0, K 1 (B 1 or 0 does not make a difference) A 1, C 1, K 1 (B - no difference) and also your combinations with 256, 0.00390625. so for me it works just fine.
great! can you have a look at the performance.
for me, when it work it's very ineficient.... but it should be very fast. (you can by exemple add more vertice on the primitive)
the differences may be related to different hardware/os.
yep. i'm on linux/nvidia
could someone else try this patch on diferents system?
I also don't need the line #extension GL_ARB_texture_rectangle : enable
in fact, if i remove it, i have a warning at the shader compilation, but it also work.
what do you mean with "using texture in vertex shader would be great..."
i mean that i would be happy if i could make this patch to work just like in your computer.
do you think this should work without gemframebuffer?
no. in fact, using texture in the vertex shader is efficient only when using 32 bit texture, and this on only possible with framebuffer. see chris mail on this list for more details.
cyrille
marius.
cyrille henry wrote:
hello,
i investigate a bit more the vertex displacement problem. so i've got a 8 bit texture that is rendered in a FLOAT framebuffer, in order to convert it to 32 bit. then, the frambuffer texture is used in a shader to distord a primitive
i have to strangely mix mode 0 and mode 1 in the patch to make it work, and this is very ineficient (just like in 8bit mode).
framebuffer and fragment shader usually work in mode 0 and 1 on my computer.
see patch for more.
thanks to have a look. using texture in vertex shader would be great...
thanks 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
Hmm, sorry here, always the same error : [glsl_program]: link failed! (PowerBook G4, GeForce FX Go5200, MacOsX.4.11). I will test this patch later on MacPro with GeForce 7300 GT. ++
Jack
Le 9 déc. 07 à 14:21, cyrille henry a écrit :
hello,
i investigate a bit more the vertex displacement problem. so i've got a 8 bit texture that is rendered in a FLOAT framebuffer, in order to convert it to 32 bit. then, the frambuffer texture is used in a shader to distord a primitive
i have to strangely mix mode 0 and mode 1 in the patch to make it work, and this is very ineficient (just like in 8bit mode).
framebuffer and fragment shader usually work in mode 0 and 1 on my computer.
see patch for more.
thanks to have a look. using texture in vertex shader would be great...
thanks Cyrille
<vertex_displacement.zip> _______________________________________________ GEM-dev mailing list GEM-dev@iem.at http://lists.puredata.info/listinfo/gem-dev
-
cyrille henry -
Jack -
marius schebella