[GEM-dev] Soft edge shading

Florian Grond fgrond at techfak.uni-bielefeld.de
Thu Mar 22 21:32:49 CET 2012 

Hello Cyrille,

yes, maybe a second inlet to the gemwin might be what it needs or just 
one route message for the gemwin for things that are not related to the 
soft edging like

gemwin frame 25
or
gemwin border 1

as far as the bug that I encounter is concerned I discuss them example 
by example. But don't take me wrong it works for me already and I'm very 
happy about it.
Either I have a hardware specific problem or the order how the 
framebuffer is clampt onto the rectangle is kind of messed up as far as 
mostly the vertical order is concerned.
In any case in the working 3 1 example I generally see two ways how to 
strech and clamp the texture. Aspect ratio preserving for the content.
or such that all the content is shown but a little bit deformed.

horizontal row of screens:

1 1 (unrealistic case)
shading to black happens at the right edge
texture moves to the left with increasing overlap

2 1
shading on the right screen on both edges, left and also wrongly on the 
right.
shading on the left screen on the right edge only left edge remains 
unshaded as it should
texture on the right screen is stretched symmetrically to left and right
textures on the left screen is streched towards left

3 1 (my case)
works for me!
shading only at the edges that are close to the middle screen
I wonder if the textures have to move on the left and on the right 
screen. I guess this is a question of preserving the aspect ratio of the 
content of the projection

4 1
like 3 1 but the fourth screen on the right shows vertical stripes as 
artifacts, which is the texture content of the leftmost screen on the top.

vertical colums of screens:

1 2
shading happens only at the vertical edges, left right on top, only 
right at the bottom. No shading  horizontally in the middle.
Content of the screen doe not seem to be properly distributed starts on 
the top screen and not in the middle of both.

1 3
content starts in the middle but when I increas the fractal.jpg
it seems to distribute the content as if the geometry is 3 1 rather than 1 3

mixed mode

2 2
rendering of a small fractal.jpg starts at the bottom right.
when increasing, it extents correctly towards the bottom left.
The top left shows part of the texture and the top right is vertical 
stripy artifacts


On 3/22/12 1:06 PM, Cyrille Henry wrote:
>
> hello,
>
> Le 22/03/2012 16:56, Florian Grond a écrit :
>> Hi Cyrille,
>>
>> Thanks you very much! I tested it and it works for me. However I think
>> geometries other than 3 1 do not work yet as they should. 2 2 gives
>> strange results.
> what do you mean?
> it look like it should imo.
> maybe there is a bug so it did not look the same here or on your
> computer, or we may did not have the same expectation.
>
>>
>> I added some things to the interface, basically exposing some features
>> of gemwin such as offset or border, or frames per second, they can all
>> be set through one inlet, am not sure if the message names I created
>> follow GEM convention I wonder if for a complete functionallity all
>> gemwin methods should be made acessible to the user. Let me know if
>> you find usefull, what I added
> well, i'm usually not a big fan of gui.
> maybe it jus miss an inlet connected to the gemwin ...
>
> Cyrille
>
>
>
>>
>> Again thank you very much!
>>
>> Florian
>>
>>
>>
>> On 3/21/12 5:53 PM, Cyrille Henry wrote:
>>> oups, wrong one.
>>>
>>>
>>> Le 21/03/2012 22:52, Cyrille Henry a écrit :
>>>> oups.
>>>> this one should work better.
>>>> cheers
>>>> cyrille
>>>>
>>>> Le 21/03/2012 22:00, Florian Grond a écrit :
>>>>> hello cyrille,
>>>>>
>>>>>
>>>>> the glsl_fragment does not like the new shader if I bang it I get:
>>>>>
>>>>> compile info log:
>>>>> ERROR: 0:43: '!=' wrong operand types
>>>>> ERROR: 0:45: '!=' wrong operand types
>>>>> ERROR: 0:57: '!=' wrong operand types
>>>>> ERROR: 0:59: '!=' wrong operand types
>>>>>
>>>>> there is a type problem between float and constant int
>>>>>
>>>>> so it says shader not loaded,
>>>>>
>>>>> Cheers,
>>>>>
>>>>> Florian
>>>>>
>>>>>
>>>>>
>>>>> On 3/21/12 4:07 PM, Cyrille Henry wrote:
>>>>>> hello,
>>>>>>
>>>>>> it look like a bug in the original shader.
>>>>>> thanks for reporting it.
>>>>>>
>>>>>> this shader should work.
>>>>>> could you test it so that i commit it if it's ok.
>>>>>>
>>>>>> BTW, the fade control is for both right and left.
>>>>>> so it can be twice what the user expect.
>>>>>> i.e if you want 10 pixel shade on the right, so 10 pixel shade
>>>>>> also on
>>>>>> the left, you have to set overlap to 20.
>>>>>> maybe i should change that.
>>>>>> feedback welcome.
>>>>>>
>>>>>> Cheers
>>>>>> Cyrille
>>>>>>
>>>>>>
>>>>>> Le 21/03/2012 19:30, Florian Grond a écrit :
>>>>>>> Here I could reproduce the problem with the example patch, having it
>>>>>>> extended over the tripple head projectors.
>>>>>>> I basically see the shading again only if I drive the overlap to
>>>>>>> extremely many pixels.
>>>>>>> I was wondering if this might have something to do with the
>>>>>>> texturing
>>>>>>> mode rectangle anywhere?
>>>>>>>
>>>>>>> I modified the the [flat_projection] so that I could define an
>>>>>>> offset
>>>>>>> for the windowcreation.
>>>>>>>
>>>>>>> Thanks for any help,
>>>>>>>
>>>>>>>
>>>>>>> Best,
>>>>>>>
>>>>>>> Florian
>>>>>>>
>>>>>>> On 3/21/12 1:49 PM, Cyrille Henry wrote:
>>>>>>>> hello,
>>>>>>>>
>>>>>>>> would it be possible to see your patch?
>>>>>>>> that would be easier to help.
>>>>>>>>
>>>>>>>>
>>>>>>>> Cyrille
>>>>>>>>
>>>>>>>>
>>>>>>>> Le 21/03/2012 18:15, Florian Grond a écrit :
>>>>>>>>> Hello Jack,
>>>>>>>>>
>>>>>>>>> 01.flat_projection-help.pd seems to work.
>>>>>>>>>
>>>>>>>>> I see either as 4 by 1 or 2 by the fractal image with decreasing
>>>>>>>>> intensity at the edges giving a fade into black.
>>>>>>>>>
>>>>>>>>> I looked into the guts of [flat_projection]
>>>>>>>>>
>>>>>>>>> and if I send the print message to the glsl_fragemnet and the
>>>>>>>>> glsl_program I get lots of info about user variable uvar#1 to
>>>>>>>>> uvar#4
>>>>>>>>>
>>>>>>>>> I'm usin PD extended 0.42.5
>>>>>>>>> I compiled GEM from the sources 0.93.3 (added some handmade
>>>>>>>>> classes)
>>>>>>>>> My GPU NVIDIA GeForce 7300 GT
>>>>>>>>>
>>>>>>>>> My screen size is 1280 * 1024
>>>>>>>>> geometry is x 3 y 1
>>>>>>>>> I would like to have an overlap of about 10 - 15 pixels
>>>>>>>>>
>>>>>>>>> In my installation I see that I get a fade into black only if I
>>>>>>>>> increase the overlap to very high numbers up to have the size of
>>>>>>>>> my x
>>>>>>>>> dimension. So I conclude the fade into black is just too weak.
>>>>>>>>>
>>>>>>>>> How could I change that?
>>>>>>>>>
>>>>>>>>> Thanks,
>>>>>>>>>
>>>>>>>>> Florian
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> So I think the GPU model is ok
>>>>>>>>>
>>>>>>>>> On 3/20/12 6:51 PM, Jack wrote:
>>>>>>>>>> Le 20/03/2012 21:07, Florian Grond a écrit :
>>>>>>>>>>> Dear List,
>>>>>>>>>>>
>>>>>>>>>>> I'm currently working on a horizontal 3 screen projection
>>>>>>>>>>> (tripple
>>>>>>>>>>> head) and I'm using the multiscreen projection flat projection
>>>>>>>>>>> abstraction from Cyrille.
>>>>>>>>>>>
>>>>>>>>>>> The overlap is working nicely but I don't get the it to fade.
>>>>>>>>>>> i.e. I
>>>>>>>>>>> see a vertical stripe of overlap with higher intensity.
>>>>>>>>>>>
>>>>>>>>>>> Any help or pointer where to look for solutions very much
>>>>>>>>>>> appreciated.
>>>>>>>>>>>
>>>>>>>>>>> Cheers,
>>>>>>>>>>>
>>>>>>>>>>> Florian
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>> Hello Florian,
>>>>>>>>>>
>>>>>>>>>> Can you tell us your configuration (Pd, Gem, GPU model) ?
>>>>>>>>>> Have you a problem with the example 01.flat_projection-help.pd' ?
>>>>>>>>>> ++
>>>>>>>>>>
>>>>>>>>>> Jack
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> _______________________________________________
>>>>>>>>>> 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
>>

-- 
--8<-------8<-------- hier abtrennen -----8<--------8<----

F l o r i a n   G R O N D
PhD Student at Ambient Intelligence Group,
CITEC Bielefeld University, Germany
Universitaetsstrasse 21 - 23 33615 Bielefeld
Tel.: 0049 521 106 12163
http://cit-ec.org   http://grond.at

-->8------->8-------- hier abtrennen ------->8------>8----

More information about the GEM-dev mailing list