hmm - stupid me - i m using this effect as "texture feedback" since years. just did not identify it as a possible motion blur as one needs to choose a right combination of offset/snapsize and background square size for the effect to work properly.

lg

e

--------------------- http://randomseed.org

On Wed, 16 Aug 2006, IOhannes m zmoelnig wrote:

Erich Berger wrote:

...

hi,

i m trying to follow the possibilities of motion blur or drawing traces (without single buffering) as it was discussed a while ago:

...

the simplest method for doing fullscreen motion blur, is currently torender the entire screen (additionally) into a texture and display this texture with an alpha<1.0

see attached example patch

mfg.asdr IOhannes

Hey Frank,

the pix_snap2tex copies the buffer to a texture on the card, so I guess those operations are not so fast on your matrox.. ?

This is a real "workaround" if I ever heard of one, since your doing a lot of effort since we can't seem to control clearing of the window to a degree. I thought someone posted a patch using wrappers to do this, but now I'm not sure if it was successful.

back to "color 0 0 0 0.5" feature request. ;) or "clear" , "clear 0.5" etc...

Note that using pix_snap (which transfers to main memory not gfx card memory) I was able to do double the resolution on linux as I could in windows. This is back in the days when I still has windows installed.

.b.

Frank Barknecht wrote:

Hallo, IOhannes m zmoelnig hat gesagt: // IOhannes m zmoelnig wrote:

...

the simplest method for doing fullscreen motion blur, is currently torender the entire screen (additionally) into a texture and display this texture with an alpha<1.0

As this came up again: This approach for some reason is incredibly slow on both my stationary machine and my laptop. Now both my machines don't have current NVidia or ATi cards, as I'm an open source driver zealot.

My main box still runs an Matrox G450 DH with 16MB, my laptop has a rather recent Intel GMA 900 inside (like several new Mac-laptops), and I can play Quake 2 on both boxes with very good framerates, if I'd want to.

Why is it, that this simple patch, that IOhannes attached, still makes my machines max out with 100% CPU usage, and more importantly: Is there a way to get better performance? Somehow I cannot believe that it has to be *that* slow.

(This is on Linux, Gem is some rather current CVS, but it happened with older Gems as well)

Ciao

On 8/18/06, Erich Berger eb@randomseed.org wrote:

hi,

the work around also does not work for me (even with nvidia). as soon as one starts to work with higher resolutions and non square gemwins it becomes slow and tricky.

pix_snap2tex should not impose much of a performance hit unless the window resolution is really huge (2048x1536 or larger). If it does then it has probably fallen back to software to do a pixel format conversion or there is some other hardware incompatibility.

he implemented a clearmask message to gemwin but i have no idea how to use it: http://lists.puredata.info/pipermail/gem-dev/2003-09/000138.html

You need to get the GL_COLOR_BUFFER_BIT and related constants and make a mask. A better interface could be made for the message.

All it really does is enable or disable a buffer for clearing by glClear(). I recall that someone posted a patch not long ago that used the GEMgl calls to disable clearing the depth buffer, which does the same thing.

cgc

The Intel chips are awful at OpenGL. I tested an Intel MacMini and returned it.

Post the patch you are using and I can test it on some machines.

cgc

On 8/18/06, Frank Barknecht <fbar@footils.org > wrote:

Hallo, chris clepper hat gesagt: // chris clepper wrote:

...

pix_snap2tex should not impose much of a performance hit unless the

window

...

resolution is really huge (2048x1536 or larger). If it does then it has probably fallen back to software to do a pixel format conversion or

there is

...

some other hardware incompatibility.

Is there some way to debug this a bit deeper if performance losses are happening? As I wrote I have two machines where performance of pix_snap2tex is a problem on both. Maybe I just miss a bit of tuning on my system. But at least the Intel chip is becoming more popular with the new Intel-Macs, so maybe other people run into similar problems as well. (Though I'm running Linux, not OS-X ...)

Ciao

Frank Barknecht _ ______footils.org_ __goto10.org__

---

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

Frank

Try using a cube rather than the teapot. My profiling shows that all of the time is spent drawing the teapot and the snap2tex takes nearly 0% CPU. The teapot is twice as bad on the Intel "GPU" since the CPU also has to do all of the translation of those vertices as well.

cgc

On 8/19/06, Frank Barknecht fbar@footils.org wrote:

Hallo, chris clepper hat gesagt: // chris clepper wrote:

...

The Intel chips are awful at OpenGL. I tested an Intel MacMini and returned it.

Well, many people cannot return, because only Intel provides good open source drivers for Linux, everything else is either crap or legally questionable.

...

Post the patch you are using and I can test it on some machines.

I'm using the one IOhannes posted before.

Ciao

Frank Barknecht _ ______footils.org_ __goto10.org__

---

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

On 8/19/06, Frank Barknecht fbar@footils.org wrote:

Thanks for your help. I tried with the Cube now, so far only on my Matrox, where I get the same results: CPU usage goes up to 99-100 percent immediatly. The patch seems to run fine otherwise...

Sounds like a Matrox problem. On my nearly obsolete Powerbook the patch takes under 3% CPU with the cube. Your system might be downloading the textures to the CPU for manipulation and then uploading them again. This is the same as using pix_snap followed by pix_texture.

cgc

Try changing the GL_RGB to GL_RGBA in the snapMess() function in pix_snap2tex.cpp and see what happens.

cgc

On 8/19/06, Frank Barknecht fbar@footils.org wrote:

Hallo, chris clepper hat gesagt: // chris clepper wrote:

...

On 8/19/06, Frank Barknecht fbar@footils.org wrote:

...

Thanks for your help. I tried with the Cube now, so far only on my Matrox, where I get the same results: CPU usage goes up to 99-100 percent immediatly. The patch seems to run fine otherwise...

Sounds like a Matrox problem. On my nearly obsolete Powerbook the patch takes under 3% CPU with the cube. Your system might be downloading the textures to the CPU for manipulation and then uploading them

again. This is

...

the same as using pix_snap followed by pix_texture.

This sounds quite sensible. I now also tested the cube-version on my Intel-laptop. I also get very high load, though only about 80 percent) and crappy performance. Disabling the gemhead of the snap2tex lets CPU usage drop to about zero immediatly.

Maybe it's a problem with the OpenGL libraries or with AGP on my systems. One is a Debian, the other an Ubuntu box, and I didn't do any special configuration.

Maybe some other Debian/Linux users can give some hints here? IOhannes, you are running Debian as well, btu I guess with NVidia...

Ciao

Frank Barknecht _ ______footils.org_ __goto10.org__

---

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

are you sure you are using hardware accelleration ? glxinfo should show this if enabled: erich@pupu:~$ glxinfo name of display: :0.0 display: :0 screen: 0 direct rendering: Yes ....

e

--------------------- http://randomseed.org

On Sat, 19 Aug 2006, Frank Barknecht wrote:

Hallo, chris clepper hat gesagt: // chris clepper wrote:

...

On 8/19/06, Frank Barknecht fbar@footils.org wrote:

...

Thanks for your help. I tried with the Cube now, so far only on my Matrox, where I get the same results: CPU usage goes up to 99-100 percent immediatly. The patch seems to run fine otherwise...

Sounds like a Matrox problem. On my nearly obsolete Powerbook the patch takes under 3% CPU with the cube. Your system might be downloading the textures to the CPU for manipulation and then uploading them again. This is the same as using pix_snap followed by pix_texture.

This sounds quite sensible. I now also tested the cube-version on my Intel-laptop. I also get very high load, though only about 80 percent) and crappy performance. Disabling the gemhead of the snap2tex lets CPU usage drop to about zero immediatly.

Maybe it's a problem with the OpenGL libraries or with AGP on my systems. One is a Debian, the other an Ubuntu box, and I didn't do any special configuration.

Maybe some other Debian/Linux users can give some hints here? IOhannes, you are running Debian as well, btu I guess with NVidia...

Ciao

Frank Barknecht _ ______footils.org_ __goto10.org__

---

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

I found a stupidly simple way to get 'motion blur' with next to zero resources. Ready?

Use single buffer rendering Set up the scene to draw draw everything with positive gemhead numbers set up a gemhead -1 add the alpha, colorRGB 0 0 0 0 and a rectangle object make the rectangle equal the porpotions of the window (4 4 for square, 5.334 for 4:3 rectangle) modulate the alpha inlet to control the blur amount

Stupid enough?

cgc

On 8/19/06, Frank Barknecht fbar@footils.org wrote:

Hallo, Erich Berger hat gesagt: // Erich Berger wrote:

...

are you sure you are using hardware accelleration ? glxinfo should show this if enabled: erich@pupu:~$ glxinfo name of display: :0.0 display: :0 screen: 0 direct rendering: Yes ....

Yes, direct rendering is enabled. Besides glxinfo also Geem tells me so by: "Direct Rendering enabled!"

Ciao

Frank Barknecht _ ______footils.org_ __goto10.org__

---

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

Erich Berger a écrit :

hi chris,

thx for your patience in the motion blur business :-) . it works well - but unfortunately its a motionblur in single buffering. but there is also another problem:

yes, and it's a problem for rendering complex objects. So i don't think this solution solve all the problem.

unless i make something wrong it works for 2d but not 3d. only those pixels of the scene which have the same z-coordinate as the rectangle for the blur get blurred, the rest gets drawn like in single buffer mode

i think you also nead to clear deaph buffer (before drawing the rectangle).

Cyrille

e

...

I found a stupidly simple way to get 'motion blur' with next to zero resources. Ready?

Use single buffer rendering Set up the scene to draw draw everything with positive gemhead numbers set up a gemhead -1 add the alpha, colorRGB 0 0 0 0 and a rectangle object make the rectangle equal the porpotions of the window (4 4 for square, 5.334 for 4:3 rectangle) modulate the alpha inlet to control the blur amount

Stupid enough?

cgc

---

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

yes thats the patch that was posted a while ago. it is this one which does not work for me with nvidia (windows + linux) but ati on osx . its strange - why could that be ?

e

#X floatatom 323 276 5 0 0 0 - - -; #X obj 491 73 gemhead; #X obj 368 296 line; #X msg 383 272 0 , 360 5000; #X obj 373 321 sel 360; #X obj 36 152 gemwin; #N canvas 245 99 680 638 iniciar 0; #X msg 318 132 reset; #X msg 234 281 create; #X obj 218 77 inlet; #X obj 218 107 t b b b b b b b; #X msg 218 313 1; #X obj 233 408 outlet;

chris clepper a écrit :

On 8/21/06, *cyrille henry* <cyrille.henry@la-kitchen.fr mailto:cyrille.henry@la-kitchen.fr> wrote:

Erich Berger a écrit :
 > hi chris,
 >
 > thx for your patience in the motion blur business :-) .
 > it works well - but unfortunately its a motionblur in
 > single buffering. but there is also another problem:
 >
yes, and it's a problem for rendering complex objects.
So i don't think this solution solve all the problem.

Can you give an example of the problem with comples objects?

i don't have exemple here. but drawing somthing like a complex LSystem, when it takes 20ms to draw the shape, then it should blink. this is visible only if the rendering time is long.

of course, motion blur will make this less visible.

the aim of double buffering is to supress this problem...

 > unless i make something wrong it works for 2d but not 3d.
 > only those pixels of the scene which have the same z-coordinate
as the
 > rectangle for the blur get blurred, the rest
 > gets drawn like in single buffer mode

i think you also nead to clear deaph buffer (before drawing the
rectangle).

Sorry, I forgot to mention the depth buffer clearing. I was using this patch:

this patch does not work on my computer : if i remove the objects nead to clear depth buffer, everything work as expected (i.e. not perfectly, but i see it's working).

Erich, could you try removing this 2 objects (gemglcleardeph and gemglclear) from the gemchain and tell us if it's working better? (do you also nead to destroy and then create the gemwin again?)

this is certainly why i was not able to use the stencil buffer...

anybody know why clearing the depth buffer clear also the rendering window?

Cyrille

#N canvas 417 23 824 714 10; #X obj 261 44 gemhead; #X obj 265 254 translateXYZ; #X obj 265 334 rotateXYZ; #X floatatom 323 276 5 0 0 0 - - -; #X obj 491 73 gemhead; #X obj 368 296 line; #X msg 383 272 0 , 360 5000; #X obj 373 321 sel 360; #X obj 36 152 gemwin; #N canvas 245 99 680 638 iniciar 0; #X msg 318 132 reset; #X msg 234 281 create; #X obj 218 77 inlet; #X obj 218 107 t b b b b b b b; #X msg 218 313 1; #X obj 233 408 outlet; #X msg 268 212 buffer 1; #X msg 251 244 lighting 1; #X msg 301 156 title FERRARI; #X msg 284 184 dimen 320 240; #X connect 0 0 5 0; #X connect 1 0 5 0; #X connect 2 0 3 0; #X connect 3 0 4 0; #X connect 3 1 1 0; #X connect 3 2 7 0; #X connect 3 3 6 0; #X connect 3 4 9 0; #X connect 3 5 8 0; #X connect 3 6 0 0; #X connect 4 0 5 0; #X connect 6 0 5 0; #X connect 7 0 5 0; #X connect 8 0 5 0; #X connect 9 0 5 0; #X restore 36 101 pd iniciar; #X msg 36 68 bang; #X msg 45 126 destroy; #X obj 320 11 tgl 15 0 empty empty empty 0 -6 0 8 -262144 -1 -1 1 1 ; #X floatatom 349 237 5 0 0 0 - - -; #X floatatom 570 195 5 0 0 0 - - -; #X floatatom 517 163 5 0 0 0 - - -; #X floatatom 543 179 5 0 0 0 - - -; #X obj 491 134 rotateXYZ; #X obj 491 219 translateXYZ; #X obj 491 289 world_light; #X obj 265 155 colorRGB; #X obj 277 95 / 360; #X obj 293 119 expr 1-$f1; #X msg 586 264 1 1 1; #X msg 277 630 draw fill; #X msg 515 264 debug 1; #X obj 264 393 GEMglClearDepth; #X obj 281 516 GEMglClear; #X obj 382 448 GLdefine GL_DEPTH_BUFFER_BIT; #X msg 365 365 1; #X obj 265 665 rectangle 1.33 1; #X obj 320 29 metro 20; #X msg 382 420 bang; #X msg 349 211 1; #X msg 585 169 2; #X floatatom 529 110 5 0 0 0 - - -; #X obj 136 288 random 6; #X obj 136 316 - 3; #X obj 68 412 line; #X obj 68 364 t f b; #X obj 136 411 line; #X obj 136 363 t f b; #X obj 74 207 tgl 15 0 empty empty empty 0 -6 0 8 -262144 -1 -1 1 1 ; #X obj 68 261 random 8; #X obj 68 289 - 4; #X obj 474 32 loadbang; #X text 77 79 begin now; #X msg 116 133 bang; #X floatatom 343 154 5 0 0 0 - - -; #X obj 267 76 alpha; #X obj 74 228 metro 1000; #X msg 91 389 1000; #X msg 164 388 1000; #X obj 648 70 gemhead -1; #X obj 648 131 alpha; #X obj 650 248 rectangle 5.33 4; #X floatatom 740 155 5 0 0 0 - - -; #X obj 648 185 colorRGB 0 0 0 0.1; #X msg 172 112 frame 100; #X msg 157 80 frame 60; #X msg 113 158 profile 1 , fps; #X floatatom 41 181 5 0 0 0 - - -; #X msg 7 150 fps; #X msg 110 31 dimen 1024 768; #X msg 36 30 create , 1; #X connect 0 0 49 0; #X connect 1 0 2 0; #X connect 2 0 26 0; #X connect 3 0 2 3; #X connect 4 0 17 0; #X connect 5 0 7 0; #X connect 5 0 2 3; #X connect 5 0 2 1; #X connect 5 0 2 2; #X connect 5 0 21 0; #X connect 6 0 5 0; #X connect 7 0 6 0; #X connect 8 0 61 0; #X connect 9 0 8 0; #X connect 10 0 9 0; #X connect 11 0 8 0; #X connect 12 0 31 0; #X connect 13 0 1 3; #X connect 14 0 18 3; #X connect 15 0 18 1; #X connect 16 0 18 2; #X connect 17 0 18 0; #X connect 18 0 19 0; #X connect 20 0 1 0; #X connect 21 0 20 1; #X connect 21 0 22 0; #X connect 22 0 20 2; #X connect 22 0 20 3; #X connect 23 0 19 1; #X connect 24 0 30 0; #X connect 25 0 19 0; #X connect 26 0 27 0; #X connect 27 0 30 0; #X connect 28 0 27 1; #X connect 29 0 26 1; #X connect 31 0 0 0; #X connect 31 0 4 0; #X connect 31 0 53 0; #X connect 32 0 28 0; #X connect 33 0 13 0; #X connect 34 0 14 0; #X connect 35 0 17 2; #X connect 36 0 37 0; #X connect 37 0 41 0; #X connect 38 0 1 1; #X connect 39 0 38 0; #X connect 39 1 51 0; #X connect 40 0 1 2; #X connect 41 0 40 0; #X connect 41 1 52 0; #X connect 42 0 50 0; #X connect 43 0 44 0; #X connect 44 0 39 0; #X connect 45 0 34 0; #X connect 45 0 23 0; #X connect 45 0 33 0; #X connect 45 0 6 0; #X connect 45 0 29 0; #X connect 45 0 32 0; #X connect 45 0 42 0; #X connect 45 0 12 0; #X connect 47 0 8 0; #X connect 48 0 20 4; #X connect 49 0 20 0; #X connect 50 0 36 0; #X connect 50 0 43 0; #X connect 51 0 38 1; #X connect 52 0 40 1; #X connect 53 0 54 0; #X connect 54 0 57 0; #X connect 56 0 57 4; #X connect 57 0 55 0; #X connect 58 0 8 0; #X connect 59 0 8 0; #X connect 60 0 8 0; #X connect 62 0 8 0; #X connect 63 0 8 0; #X connect 64 0 8 0;

---

---

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

well, if you see something, then it "work better" i think we have the same problem.

so, i think the gemglcleardeph and gemglclear does not only clear depth buffer, but also the color buffer. but i don't really see why, and how to solve this.

cyrille

Erich Berger a écrit :

...

Erich, could you try removing this 2 objects (gemglcleardeph and gemglclear) from the gemchain and tell us if it's working better? (do you also nead to destroy and then create the gemwin again?)

when i remove them and reconnect the chain i still dont see anything. i have to close the window and create it again. it behaves like you describe (but only with my nvidia with ati osx it works like chris says).

i dont understand your question about if it works better ? i just works as normal single buffer then.

best

e

---

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

I add the line :

post("mask %d, depth %d, current %d, color %d", mask, GL_DEPTH_BUFFER_BIT, GL_CURRENT_BIT, GL_COLOR_BUFFER_BIT);

and it gives me : mask 256, depth 256, current 1, color 16384

looks OK. ???

cyrille

chris clepper a écrit :

On 8/21/06, *cyrille henry* <cyrille.henry@la-kitchen.fr mailto:cyrille.henry@la-kitchen.fr> wrote:

well, if you see something, then it "work better"
i think we have the same problem.

so, i think the gemglcleardeph and gemglclear does not only clear depth
buffer, but also the color buffer.
but i don't really see why, and how to solve this. 

It works on both Nvidia and ATI on OSX, but not ATI on Windows. The code only clears the depth buffer, so I can't see what would trigger the clearing of any other buffers. Maybe the GLdefine constants are wrong or there is an OR being done? Try printing out GL_DEPTH_BUFFER_BIT, GL_CURRENT_BIT and GL_COLOR_BUFFER_BIT to the console.

cgc

---

---

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

i made more test. the depth buffer is empty, but not with the correct value. the problem comes from GEMglClearDepth

this code :

///////////////////////////////////////////////////////// // Render // void GEMglClearDepth :: render(GemState *state) { glClearDepth (10); // <- fix for test only post("depth : %d", depth); // <- ...

}

gives : depth : 1073741824 in the log and the patch is working.

look like there is a problem with (GLclampd) casting.

cyrille

chris clepper a écrit :

Yes, that mask is only for the depth buffer. The mask for color and depth would be 256 + 16384.

On 8/21/06, *cyrille henry* < cyrille.henry@la-kitchen.fr mailto:cyrille.henry@la-kitchen.fr> wrote:

I add the line :

        post("mask %d, depth %d, current %d, color %d", mask,
GL_DEPTH_BUFFER_BIT, GL_CURRENT_BIT, GL_COLOR_BUFFER_BIT);


and it gives me :
mask 256, depth 256, current 1, color 16384

looks OK.
???

cyrille

chris clepper a écrit :
 > On 8/21/06, *cyrille henry* < cyrille.henry@la-kitchen.fr
<mailto:cyrille.henry@la-kitchen.fr>
 > <mailto:cyrille.henry@la-kitchen.fr
<mailto:cyrille.henry@la-kitchen.fr>>> wrote:
 >
 >     well, if you see something, then it "work better"
 >     i think we have the same problem.
 >
 >     so, i think the gemglcleardeph and gemglclear does not only
clear depth
 >     buffer, but also the color buffer.
 >     but i don't really see why, and how to solve this.
 >
 >
 > It works on both Nvidia and ATI on OSX, but not ATI on Windows.  The
 > code only clears the depth buffer, so I can't see what would
trigger the
 > clearing of any other buffers.  Maybe the GLdefine constants are
wrong
 > or there is an OR being done?  Try printing out GL_DEPTH_BUFFER_BIT,
 > GL_CURRENT_BIT and GL_COLOR_BUFFER_BIT to the console.
 >
 > cgc
 >
 >
 >
 >
------------------------------------------------------------------------

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

and finally, the attachement. sorry. c

cyrille henry a écrit :

finally : i replace all GLclampd by float and cast the value on the glClearDepth. like in the attachment.

this solve the problem.

is it clean enough to be commited on the cvs?

cyrille

cyrille henry a écrit :

...

i made more test. the depth buffer is empty, but not with the correct value. the problem comes from GEMglClearDepth

this code :

///////////////////////////////////////////////////////// // Render // void GEMglClearDepth :: render(GemState *state) { glClearDepth (10); // <- fix for test only post("depth : %d", depth); // <- ...

}

gives : depth : 1073741824 in the log and the patch is working.

look like there is a problem with (GLclampd) casting.

cyrille

chris clepper a écrit :

...

Yes, that mask is only for the depth buffer. The mask for color and depth would be 256 + 16384. On 8/21/06, *cyrille henry* < cyrille.henry@la-kitchen.fr mailto:cyrille.henry@la-kitchen.fr> wrote:

I add the line :

        post("mask %d, depth %d, current %d, color %d", mask,
GL_DEPTH_BUFFER_BIT, GL_CURRENT_BIT, GL_COLOR_BUFFER_BIT);


and it gives me :
mask 256, depth 256, current 1, color 16384

looks OK.
???

cyrille

chris clepper a écrit :
 > On 8/21/06, *cyrille henry* < cyrille.henry@la-kitchen.fr
<mailto:cyrille.henry@la-kitchen.fr>
 > <mailto:cyrille.henry@la-kitchen.fr
<mailto:cyrille.henry@la-kitchen.fr>>> wrote:
 >
 >     well, if you see something, then it "work better"
 >     i think we have the same problem.
 >
 >     so, i think the gemglcleardeph and gemglclear does not only
clear depth
 >     buffer, but also the color buffer.
 >     but i don't really see why, and how to solve this.
 >
 >
 > It works on both Nvidia and ATI on OSX, but not ATI on 

Windows. The > code only clears the depth buffer, so I can't see what would trigger the > clearing of any other buffers. Maybe the GLdefine constants are wrong > or there is an OR being done? Try printing out GL_DEPTH_BUFFER_BIT, > GL_CURRENT_BIT and GL_COLOR_BUFFER_BIT to the console. > > cgc > > > >

---

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

---

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

chris clepper a écrit :

Cyrille

Go ahead and commit those changes.

well, i don't have write access.

c

This turned out to be an architecture problem where PowerPC conformed to the casts and x86 didn't. The MacBook here also had the same problem.

Looks like some further vetting of the code is needed to deal with 'x86 float' issues.

cgc

On 8/21/06, *cyrille henry* <cyrille.henry@la-kitchen.fr mailto:cyrille.henry@la-kitchen.fr> wrote:

finally : i replace all GLclampd by float
and cast the value on the glClearDepth.
like in the attachment.

this solve the problem.

is it clean enough to be commited on the cvs?

cyrille

cyrille henry a écrit :
 > i made more test.
 > the depth buffer is empty, but not with the correct value.
 > the problem comes from GEMglClearDepth
 >
 > this code :
 >
 > /////////////////////////////////////////////////////////
 > // Render
 > //
 > void GEMglClearDepth :: render(GemState *state) {
 >     glClearDepth (10);  // <- fix for test only
 > post("depth : %d", depth);  // <- ...
 >
 > }
 >
 > gives :
 > depth : 1073741824 in the log
 > and the patch is working.
 >
 > look like there is a problem with (GLclampd) casting.
 >
 >
 > cyrille
 >
 >
 > chris clepper a écrit :
 >> Yes, that mask is only for the depth buffer.  The mask for color and
 >> depth would be 256 + 16384.
 >> On 8/21/06, *cyrille henry* < cyrille.henry@la-kitchen.fr
<mailto:cyrille.henry@la-kitchen.fr>
 >> <mailto:cyrille.henry@la-kitchen.fr
<mailto:cyrille.henry@la-kitchen.fr>>> wrote:
 >>
 >>     I add the line :
 >>
 >>             post("mask %d, depth %d, current %d, color %d", mask,
 >>     GL_DEPTH_BUFFER_BIT, GL_CURRENT_BIT, GL_COLOR_BUFFER_BIT);
 >>
 >>
 >>     and it gives me :
 >>     mask 256, depth 256, current 1, color 16384
 >>
 >>     looks OK.
 >>     ???
 >>
 >>     cyrille
 >>
 >>     chris clepper a écrit :
 >>      > On 8/21/06, *cyrille henry* < cyrille.henry@la-kitchen.fr
<mailto:cyrille.henry@la-kitchen.fr>
 >>     <mailto:cyrille.henry@la-kitchen.fr
<mailto:cyrille.henry@la-kitchen.fr>>
 >>      > <mailto:cyrille.henry@la-kitchen.fr
<mailto:cyrille.henry@la-kitchen.fr>
 >>     <mailto:cyrille.henry@la-kitchen.fr
<mailto:cyrille.henry@la-kitchen.fr>>>> wrote:
 >>      >
 >>      >     well, if you see something, then it "work better"
 >>      >     i think we have the same problem.
 >>      >
 >>      >     so, i think the gemglcleardeph and gemglclear does
not only
 >>     clear depth
 >>      >     buffer, but also the color buffer.
 >>      >     but i don't really see why, and how to solve this.
 >>      >
 >>      >
 >>      > It works on both Nvidia and ATI on OSX, but not ATI on
 >> Windows.  The
 >>      > code only clears the depth buffer, so I can't see what would
 >>     trigger the
 >>      > clearing of any other buffers.  Maybe the GLdefine
constants are
 >>     wrong
 >>      > or there is an OR being done?  Try printing out
 >> GL_DEPTH_BUFFER_BIT,
 >>      > GL_CURRENT_BIT and GL_COLOR_BUFFER_BIT to the console.
 >>      >
 >>      > cgc
 >>      >
 >>      >
 >>      >
 >>      >
 >>
 >>
------------------------------------------------------------------------
 >>
 >>      >
 >>      > _______________________________________________
 >>      > GEM-dev mailing list
 >>      > GEM-dev@iem.at <mailto:GEM-dev@iem.at> <mailto:
GEM-dev@iem.at <mailto:GEM-dev@iem.at>>
 >>      > http://lists.puredata.info/listinfo/gem-dev
 >>     < http://lists.puredata.info/listinfo/gem-dev>
 >>
 >>
 >
 > _______________________________________________
 > GEM-dev mailing list
 > GEM-dev@iem.at <mailto: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

chris clepper a écrit :

On 8/21/06, *cyrille henry* <cyrille.henry@la-kitchen.fr mailto:cyrille.henry@la-kitchen.fr> wrote:

chris clepper a écrit :
 > Cyrille
 >
 > Go ahead and commit those changes.
well,
i don't have write access.

Why not?

i did not understand gem code enough to accept the write acces to the cvs.

I put the fix in CVS. I suspect that other GEMgl objects need the same.

grep GLclampd * give no result...

c

cgc

sorry solved it - upgrade helped

e

--------------------- http://randomseed.org

On Wed, 23 Aug 2006, Erich Berger wrote:

hi,

after installing an nvidia card using ubuntu driver package 7174 and recompiling GEM i get the error on load cant load lib undefined symbol glGenFrameebuffersEXT .

iohannes do you have an idea what this could be ?

libGL* point to the right libs

best + thx e

---

http://randomseed.org

On Mon, 21 Aug 2006, cyrille henry wrote:

...

chris clepper a �crit :

...

On 8/21/06, *cyrille henry* <cyrille.henry@la-kitchen.fr mailto:cyrille.henry@la-kitchen.fr> wrote:

chris clepper a �crit :
 > Cyrille
 >
 > Go ahead and commit those changes.
well,
i don't have write access.

Why not?

i did not understand gem code enough to accept the write acces to the cvs.

...

I put the fix in CVS. I suspect that other GEMgl objects need the same.

grep GLclampd * give no result...

c

...

cgc

---

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

IOhannes m zmoelnig a écrit :

chris clepper wrote:

...

On 8/21/06, *cyrille henry* <cyrille.henry@la-kitchen.fr mailto:cyrille.henry@la-kitchen.fr> wrote:

chris clepper a écrit :
 > Cyrille
 >
 > Go ahead and commit those changes.
well,
i don't have write access.

Why not?

i am a bit reluctant to give anybody who contributes 2 lines of code, write access to the repository. i know that cyrille has contributed more than 2 lines in the past years, but i couldn't have known when he sent his first patch.

so it's up to him, whether he thinks that live might be easier with write access or whether things work fine by sending code to this list and having somebody else check them in.

cyrille, do you need/want write access to the CVS?

i dont think i'll be more productive in the future. so, i don't really need it, i feel ok sending code to this list.

but it's not the 1st time this question is asked. so, if YOU think it's better, you can give me write access.

Cyrille

mfg.asdr. IOhannes

---

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