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