IMHO, I say just deprecate the pd-gem SVN and focus on git. It seems the move to git has been good for getting more contributions, despite my crabbiness ;)

.hc

On Jan 30, 2012, at 3:59 AM, IOhannes m zmoelnig wrote:

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1

On 2012-01-29 07:08, John Harrison wrote:

...

On my Natty 64 bit laptop I've been running an SVN of Gem 93 but recently

hmm, developmen of Gem has moved from svn to git. despite my plans to sync the svn repository with git every now and then, i never found the time todo so. therefore it would be highly appreciated if you could use either the released sources of Gem (0.93.3) or use a git checkout:

$ git clone git://pd-gem.git.sourceforge.net/gitroot/pd-gem/Gem

if you want to stay stable, use the "0.93" branch (which is 0.93.3 + a few minor bugfixes):

$ cd Gem $ git checkout 0.93

...

I've had a problem that any video I try to load with [pix_film] (or probably [pix_movie] although I haven't tried) crashes Pd. I thought I'd compile the latest Gem release with plugins to see if that fixed the problem. When I try to compile, though, I get: imageMAGICK.cpp:82:54: error: ‘GetMimeList’ was not declared in this scope

I have Natty's libmagick++-dev, libmagickcore-dev, libmagickwand-dev (all version 6.6.2.6) installed.

Am I right that GetMimeList() should be defined in a mime.h header file associated with imagemagick?

no. "GetMimeList()" is a member of the imageMAGICK class. it seems like your imageMAGICK.h and imageMAGICK.cpp are slightly out of sync - e.g. because you modified one or only updated the other. alternatively it could mean, that the build-system is somewhat broken so that the 2 files are _made_ out of sync (with some compiler switches) - which should obviously never happen.

fgamsdr IOhannes -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk8mXAgACgkQkX2Xpv6ydvSPZwCgio339wOg7/ad9wkiWOnYrb1Q aWgAoI4XOpp7K0nBGMr4l1J1y3PR89VM =B4Ar -----END PGP SIGNATURE-----

---

GEM-dev mailing list GEM-dev@iem.at http://lists.puredata.info/listinfo/gem-dev

----------------------------------------------------------------------------

"[T]he greatest purveyor of violence in the world today [is] my own government." - Martin Luther King, Jr.

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1

On 2012-01-31 01:28, Hans-Christoph Steiner wrote:

You need to point it to your Pd headers

./configure --with-pd=/path/to/pure-data.git

hmm, but my pure-data.git/ directory usually looks like: <snip> $ ls branches config description HEAD hooks info objects refs </snip>

i'd use something like $ ./configure --with-pd=/path/to/pure-data :-)

anyhow, it seems that florian is trying to build using the xcode project: - - please be aware that these projects have not been updated for _ages_ - - autoconf/configure (as hans pointed out) is the currently used build environment - - max (or one of his students) claimed that they had updated the xcode project for the git snapshot, but they never sent me any diffs (or they got lost)

regarding FTGL: $ configure should find automatically, that you don't have FTGL installed and disable it for you.

finally: your subject mentions "Gem-0.93.3" and "OSX-10.6" in one line. the _only_ way to make this work is by forcing the build to be i386 only. look at the configure flags (./configure --help), there should be (oh, 0.92 is a _long_ time ago) a flag that allows you to set the architecture/fatness of the built dll. something like: "--enable-fat-binary=i386" should do the trick. if it does not, you might have to add "-arch i386" to the CXXFLAGS and LDFLAGS manually (and make sure that there are no "-arch x86_64" anywhere.

fgamsdr IOhannes

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1

On 2012-02-01 19:41, Florian Grond wrote:

and make

I found the following

gem_filmDarwin.so gem_filmQT.so gem_imageQT.so gem_imageSGI.so gem_recordQT.so gem_videoDarwin.so Gem.d_fat

If I compare it with what I see in /Library/Pd/Gem I figured that I don't have have some of the so files

well, you the Gem binary release has been compiled on machines that have more development libraries installed that your machine; therefore there is support for some more backends, which results in more plugins (files with .so extension)

anyhow, you should even be able to use the plugins from the release with your self-compiled Gem!

and I also miss the Gem.pd_Darwin

well, you specified that you wanted to create a Gem.d_fat, rather than a Gem.pd_darwin at the cmdline. you get what you ask for.

I thought I could just take Gem.d_fat and the so files and place it in /Library/Pd/Gem which I did, PD-extended starts but shows compiled Nov 10 2011

this seems to be a bug in Pd-extended, which (for reasons of incompatibility) prefers to not be able to load .d_fat files on osx and instead uses only .pd_darwin (though - for reasons unknown - it allows e.g. .l_i386 and .pd_linux on linux/i386; so this seems to solve some special osx issue)

i would advise you to file a bug-report against pd-extended.

Everything seems to work, but I figured it uses the Gem.pd_Darwin universal binary.

So I tried this configuer line:

./configure --with-pd=/Users/maki/Development/pure-data/src --enable-fat-binary=i386

the output from configure tells me that the target is now Gem.pd_darwin

right; you could have simply renamed all .d_fat files to .pd_darwin

After make, when I copy the Gem.pd_Darwin into /Library/Pd/Gem PD can't load it and says Symbol not found : _sys_close expected in flat namespace

again, seems to be a problem with Pd version mismatch. i suspect that you compiled Gem using Pd-0.43 and are now using Pd-0.42 (or some other older version). it's always best to use the same version for compilation and running!

I also have some class files that I've added to the sources but the seem not to get compiled. (That's the reason why I need to compile Gem) I can't find the corresponding object files.

depends on how you added them. just putting the .cpp/.h files into src/Pixes/ is no longer enough! you have to explicitely add them to src/Pixes/Makefile.am

fgmasdr IOhannes

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

I have no problem sharing my patch but it depends on the classes that I added to the GEM sources and won't work without. i'll try to reproduce the problem without the self made objects.

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

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

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

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.

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

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@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 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@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

On 3/23/12 5:57 AM, Cyrille Henry wrote:

hello,

thanks for the precision. i think i understand the problem : I can reproduce all of this is the geometry screen is at 3x1 and the computer screen is at what you describe. i.e : a 3 screen wide image is computed and you try to render it in different screen setup. this point out that it's not clearly explain that geometry screen and computer screen should defined the same number of screen. i.e. geometry screen X * geometry screen Y should be equal tocomputer screen X * computer screen Y

OK understood! when I set screen and computer geometry to the same values it works for me too. So maybe the interface needs to show only one and apply the setting to both?

Thanks again for your response and the quick fix,

Florian

hope that help. i'll add a comment in the example patch.

thanks for the feedback Cyrille

Le 22/03/2012 21:32, Florian Grond a écrit :

...

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

---

GEM-dev mailing list GEM-dev@iem.at http://lists.puredata.info/listinfo/gem-dev

maybe an explanation like that could go into the help patch.

Florian

On 3/23/12 12:25 PM, Cyrille Henry wrote:

Le 23/03/2012 16:32, Florian Grond a écrit : ...

...

OK understood! when I set screen and computer geometry to the same values it works for me too. So maybe the interface needs to show only one and apply the setting to both?

well, you don't need to have the same screen geometry on the computer and on the display. i mean : if you have a standard setup with a screen on the right, and one on the left, you may want to have them one on top of the other for your installation... (so having a 2x1 and 1x2 geometry for the computer and screen)

if you have 1 single graphic card with 2 output : 1 normal and one with a tripleheard : 4 screens are connected on a single row, but you can use that to display a 2x2 matrices... (having a 4x1 and a 2x2 geometry for the computer and screen)

so, having screen geometry and computer geometry different is a very useful feature of this example.

cheers c

...

Thanks again for your response and the quick fix,

Florian

...

hope that help. i'll add a comment in the example patch.

thanks for the feedback Cyrille

Le 22/03/2012 21:32, Florian Grond a écrit :

...

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