GEM-dev February 2009

gem-dev@lists.iem.at

12 participants
15 discussions

Re: [GEM-dev] framebuffer frustum
by cyrille henry 15 Feb '09

15 Feb '09

Matthias Neuenhofer a Ã©crit : > absolutely clear good. > thatÅ½s perfect - i was always fixed on the master head > which controls the whole setup and split in to cluster axis > which ends on the primitivesÂ… > > i will proof the 2 pass rendering in a big set > > another theme - geometry shader > > i use also gps data and think if it could help draw modulations > from line to planes with the geometry shader. > > did anybody try this with gem? i don't really understand. for now, the geometry shader is not implemented in Gem. but that would be really interesting to have. maybe we should put a feature request on sourceforge. anyway, you can use vertex shader to modulate lines. look at the examples... Cyrille > > Matthias > > > Am 14.02.2009 um 18:44 schrieb cyrille henry: > >> hello, >> >> here is a patch that should explain what i thing regarding your 2 >> comments. >> >> hope you'll understand what i try to say >> >> Cyrille >> >> >> Matthias Neuenhofer a Ã©crit : >>> Am 14.02.2009 um 01:21 schrieb cyrille henry: >>>> >>>> Matthias Neuenhofer a Ã©crit : >>>>> Am 13.02.2009 um 00:40 schrieb cyrille henry: >>>>>> Matthias Neuenhofer a Ã©crit : >>>>>>> super >>>>>>> i compiled on Mac Osx 10.5.6. >>>>>>> there was no OS specific part in, should also work on Microsoft. >>>>>>> but shouldnÅ½t the default texture out to rectangle? >>>>>> why? >>>>>> anyway, changing default could break old patch, so it's usually bad. >>>>> ok leave it, gemframebuffer needs initial values anyway like size >>>>> .... >>>>> even pix_texture use rectangle from default >>>>>>> my attention to the framebuffer was a side effect looking >>>>>>> for a way to sort the render order for proper keying and >>>>>>> discovered [gemreceive] - thanx IOhannes - which >>>>>>> support the [set $1( to sort the chain with z values via >>>>>>> [gemlist_info] >>>>>>> itÅ½s not perfect - always 1 frame to late - looks ok. >>>>>> gemhead does also accept ordering. (via set message) >>>>> yop but i like to go with a feedback via pix_snap in background >>>>> and this snaps only which belongs to the headtree - i know >>>>> snap2tex is faster but i couldnÅ½t get it in to pix_record so in this >>>>> set the gemreceive was perfect >>>> pix_record record a texture that is in main memory, so you can't >>>> make it work with pix_snap2tex. >>>> but, i can't see why using the set message to the gemhead is not >>>> what you need. >>> for the feedback with pix_snap the texture must be drawn first >>> behind all other so i use a master >>> head >>> [gemhead] >>> | >>> [t b a a] >>> right outlet to pix_snap >>> middle outlet to all other >>> left bang to snap message for pix_snap >>> now i need gemreceive to sort all the other clients >>> with set message to gemhead, the pix_snap head has to rendered last >>> otherwise is nothing to grab and >>> laying on top off all other when you feed it back. >>> just for recording without feedback it doesnÅ½t matter >>>> >>>> >>>>>>> but - is a gemhead which sort all clients by himself thinkable? >>>>>> i can't imagine a generic solution >>>>> maybe later >>>>>>> a mapping from the z position multiplied with 1000 to the priority >>>>>>> before itÅ½s drawn in the framebuffer. >>>>>> you can do this by hand, in a 2 pass rendering : render a 1st >>>>>> time only to know the Z, then use it to change priority of the >>>>>> gemhead for the final rendering. >>>>> and the performance will stay acceptable ? >>>> you don't really have to draw your primitive, just to compute there >>>> position. >>>> so performance should not be to bad... >>>> you'll have to try :-) >>> any suggestion? >>> how can i compute the the planes without drawing? >>>> cyrille >>>> >>>>>>> Matthias >>>>>>> Am 12.02.2009 um 14:14 schrieb cyrille henry: >>>>> _______________________________________________ >>>>> GEM-dev mailing list >>>>> GEM-dev(a)iem.at >>>>> http://lists.puredata.info/listinfo/gem-dev >>> _______________________________________________ >>> GEM-dev mailing list >>> GEM-dev(a)iem.at >>> http://lists.puredata.info/listinfo/gem-dev >> #N canvas 178 30 922 708 10; >> #X text 120 44 1st gemhead to be rendered : render the feedback buffer >> ; >> #X obj 40 96 gemhead -1; >> #X text 125 95 last gemhead to be rendered : snap the buffer for >> rendering >> in the next image. (btw \, This is usless if the rendernig is made >> in a framebuffer); >> #X obj 41 222 gemhead 1; >> #X obj 39 42 gemhead 2; >> #X text 40 152 every gemhead from 3 to inf should be rendered between >> rendering the feedback buffer and snap this buffer. so we can use Z >> of each primitive to set gemhead priority; >> #X text 122 222 dummy gemhead \, to know the position of the primitive >> ; >> #X obj 143 267 gemhead; >> #X obj 42 366 translateXYZ; >> #X obj 42 450 translateXYZ; >> #X obj 42 472 alpha; >> #X obj 42 494 color 1 0 0 0.5; >> #X obj 42 586 spigot 0; >> #X obj 42 411 rotateXYZ; >> #X obj 41 245 t a b; >> #X msg 73 267 0; >> #X obj 92 520 f; >> #X obj 143 585 spigot 0; >> #X obj 196 563 == 0; >> #X obj 92 561 == 1; >> #X obj 143 289 t a b; >> #X msg 175 311 1; >> #X text 219 268 real gemhead to draw the primitive; >> #X text 229 292 order depend on Z position; >> #X obj 143 608 gemlist_info; >> #X obj 224 632 unpack f f f; >> #X msg 305 701 set \$1; >> #X floatatom 132 338 5 0 0 0 - - -; >> #X floatatom 181 340 5 0 0 0 - - -; >> #X floatatom 230 343 5 0 0 0 - - -; >> #X floatatom 132 387 5 0 0 0 - - -; >> #X floatatom 181 389 5 0 0 0 - - -; >> #X floatatom 235 391 5 0 0 0 - - -; >> #X floatatom 136 416 5 0 0 0 - - -; >> #X floatatom 185 418 5 0 0 0 - - -; >> #X floatatom 239 420 5 0 0 0 - - -; >> #X obj 539 227 gemhead 1; >> #X obj 641 272 gemhead; >> #X obj 540 371 translateXYZ; >> #X obj 540 455 translateXYZ; >> #X obj 540 477 alpha; >> #X obj 540 591 spigot 0; >> #X obj 540 416 rotateXYZ; >> #X obj 539 250 t a b; >> #X msg 571 272 0; >> #X obj 590 525 f; >> #X obj 641 590 spigot 0; >> #X obj 694 568 == 0; >> #X obj 590 566 == 1; >> #X obj 641 294 t a b; >> #X msg 673 316 1; >> #X obj 641 613 gemlist_info; >> #X obj 722 637 unpack f f f; >> #X msg 803 711 set \$1; >> #X floatatom 630 343 5 0 0 0 - - -; >> #X floatatom 679 345 5 0 0 0 - - -; >> #X floatatom 728 348 5 0 0 0 - - -; >> #X floatatom 630 392 5 0 0 0 - - -; >> #X floatatom 679 394 5 0 0 0 - - -; >> #X floatatom 733 396 5 0 0 0 - - -; >> #X floatatom 634 421 5 0 0 0 - - -; >> #X floatatom 683 423 5 0 0 0 - - -; >> #X floatatom 737 425 5 0 0 0 - - -; >> #X obj 540 499 color 0 1 0 0.5; >> #X obj 42 608 circle 1; >> #X floatatom 373 709 5 0 0 0 - - -; >> #X floatatom 865 710 5 0 0 0 - - -; >> #X obj 540 613 circle 1; >> #X obj 305 678 * 1000; >> #X obj 305 655 + 50; >> #X obj 803 660 + 50; >> #X obj 803 685 * 1000; >> #X obj 620 121 gemwin 5; >> #X msg 620 68 create \, 1; >> #X msg 627 95 destroy; >> #X connect 3 0 14 0; >> #X connect 7 0 20 0; >> #X connect 8 0 13 0; >> #X connect 9 0 10 0; >> #X connect 10 0 11 0; >> #X connect 11 0 12 0; >> #X connect 11 0 17 0; >> #X connect 12 0 64 0; >> #X connect 13 0 9 0; >> #X connect 14 0 8 0; >> #X connect 14 1 15 0; >> #X connect 15 0 16 0; >> #X connect 16 0 19 0; >> #X connect 16 0 18 0; >> #X connect 17 0 24 0; >> #X connect 18 0 17 1; >> #X connect 19 0 12 1; >> #X connect 20 0 8 0; >> #X connect 20 1 21 0; >> #X connect 21 0 16 0; >> #X connect 24 4 25 0; >> #X connect 25 2 69 0; >> #X connect 26 0 7 0; >> #X connect 27 0 8 1; >> #X connect 28 0 8 2; >> #X connect 29 0 8 3; >> #X connect 30 0 13 1; >> #X connect 31 0 13 2; >> #X connect 32 0 13 3; >> #X connect 33 0 9 1; >> #X connect 34 0 9 2; >> #X connect 35 0 9 3; >> #X connect 36 0 43 0; >> #X connect 37 0 49 0; >> #X connect 38 0 42 0; >> #X connect 39 0 40 0; >> #X connect 40 0 63 0; >> #X connect 41 0 67 0; >> #X connect 42 0 39 0; >> #X connect 43 0 38 0; >> #X connect 43 1 44 0; >> #X connect 44 0 45 0; >> #X connect 45 0 48 0; >> #X connect 45 0 47 0; >> #X connect 46 0 51 0; >> #X connect 47 0 46 1; >> #X connect 48 0 41 1; >> #X connect 49 0 38 0; >> #X connect 49 1 50 0; >> #X connect 50 0 45 0; >> #X connect 51 4 52 0; >> #X connect 52 2 70 0; >> #X connect 53 0 37 0; >> #X connect 54 0 38 1; >> #X connect 55 0 38 2; >> #X connect 56 0 38 3; >> #X connect 57 0 42 1; >> #X connect 58 0 42 2; >> #X connect 59 0 42 3; >> #X connect 60 0 39 1; >> #X connect 61 0 39 2; >> #X connect 62 0 39 3; >> #X connect 63 0 41 0; >> #X connect 63 0 46 0; >> #X connect 68 0 26 0; >> #X connect 69 0 68 0; >> #X connect 69 0 65 0; >> #X connect 70 0 66 0; >> #X connect 70 0 71 0; >> #X connect 71 0 53 0; >> #X connect 73 0 72 0; >> #X connect 74 0 72 0; > >

1 0

fsaa / nvidia / linux
by cyrille henry 10 Feb '09

10 Feb '09

hello, i just found that : http://www.nvnews.net/vbulletin/showthread.php?t=121200&highlight=fsaa fsaa value for 4x Bilinear Multisampling have change from FSAA 4 to FSAA 5. don't really understand why, but i'm tracking this problem since a long time... (why FSAA 4 had no effect on recent nvidia driver) i think it can be useful for someone else... Cyrille

2 1

FSAA for windows
by patrick 05 Feb '09

05 Feb '09

hi, i was looking GemWinCreateNT.cpp and didn't found hints.fsaa inside. does it means that FSAA is not working for NVidia on Windows? pat

2 1

problems compiling videoio
by Holger Ballweg 02 Feb '09

02 Feb '09

Hi list, I tried to compile videoIO from svn without success, so I hacked something together which built (patch attached) but doesn't run in pd because of missing symbols. I'm not very good at resolving these - don't know why they aren't found, the libraries are all in /usr/lib/videoIO... Is there some version of videoIO out there which compiles or does the svn version has a special trick to build it? Cheers, holger

1 0

FSAA problem with latest nvidia driver on linux
by cyrille henry 01 Feb '09

01 Feb '09

hello, with latest (v177 or 180) nvidia proprietary driver under linux, anti-aliasing did not work. i don't really understand why, but removing the line 144 : setenv("__GL_FSAA_MODE", svalue, 1); from Base/GemWinCreateXWin.cpp does solve the problem : it allow nvidia-setting to control the application aliasing. it look like a bug in nvidia driver, but it would be nice if Gem could have a workaround. i propose changing : setenv("__GL_FSAA_MODE", svalue, 1); to : if (fsaa!=0) setenv("__GL_FSAA_MODE", svalue, 1); that should not harm anyone. any objection? Cyrille

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

GEM-dev February 2009