[GEM-dev] vertex displacement

[marius schebella]

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 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
>>>>
>>>>
>>>
>>
>>
>> ------------------------------------------------------------------------
>>
>> _______________________________________________
>> GEM-dev mailing list
>> GEM-dev at iem.at
>> http://lists.puredata.info/listinfo/gem-dev
>