hi,
attached u find a patch which shows that when one sends a |draw full( or |draw fill( to cube or cuboid, ( thats the ones i noticed) the vertices drawing gets messed up. in opposite sphere and tube are working as it should.
this is just visible with alpha enabeled and happens for example if one switches back from drawing a geo as line to fill mode.
esp. strange is that a |draw full( message is doing something, as its everywhere called "fill" in the src, but maybe this points already to a possible errorsource ?
cheers
erich
--------------------- http://randomseed.org
Erich Berger wrote:
hi,
attached u find a patch which shows that when one sends a |draw full( or |draw fill( to cube or cuboid, ( thats the ones i noticed) the vertices drawing gets messed up. in opposite sphere and tube are working as it should.
this is just visible with alpha enabeled and happens for example if one switches back from drawing a geo as line to fill mode.
esp. strange is that a |draw full( message is doing something, as its everywhere called "fill" in the src, but maybe this points already to a possible errorsource ?
without having had a look at your patch, i'd like to remark:
-) "full" should be the same as "fill" and the same as "ferich" (and even "Fiohannes" should work); only a minimum of characters are checked to allow typos....
-) i guess the error occurs because the drawtype-message is "decentralized" and actually sets the wrong draw-type for [cube] (although the very same draw-type is correct for [sphere])
thanks for the report, i'll have a look
mfg.arv.as IOhannes
Thanks for reporting this Erich!
I was about to revisit the issue, but I've not yet converted my old geo switching patches to pixelTANGO.
Also I'm working on a abstraction geo called supercube that you may like, I'm sure we'll have a chance to geek out a bit in Helskinki!
Glad you beat me to it.
I can confirm this error (on OSX)
Oh and also the error is NOT dependant on the alpha, that just makes the error visible. I've included an alteration of the patch with lighting and no alpha and we can better see how the vertecies are drawn. I'm pretty sure draw fill is drawing the vertecies with some points reversed. I only had this error when I started dyanmic patching, so I thought that was the cause, not the draw fill part, which was also in that patch!
pt.light is included just to save me time.
B.
Erich Berger wrote:
hi,
attached u find a patch which shows that when one sends a |draw full( or |draw fill( to cube or cuboid, ( thats the ones i noticed) the vertices drawing gets messed up. in opposite sphere and tube are working as it should.
this is just visible with alpha enabeled and happens for example if one switches back from drawing a geo as line to fill mode.
esp. strange is that a |draw full( message is doing something, as its everywhere called "fill" in the src, but maybe this points already to a possible errorsource ?
cheers
erich
#N canvas 199 23 740 532 10; #X obj 184 398 alpha; #X obj 184 321 color 0 1 0 0.5; #X obj 184 374 rotate 114 0 1 0; #X msg 94 422 draw line; #X msg 94 399 draw fill; #X msg 94 376 draw full; #X obj 184 300 gemhead; #X obj 184 166 alpha; #X obj 184 89 color 0 1 0 0.5; #X obj 184 142 rotate 114 0 1 0; #X msg 94 190 draw line; #X msg 94 167 draw fill; #X msg 94 144 draw full; #X obj 184 68 gemhead; #X obj 184 207 cube 0.5; #X obj 184 439 cuboid 0.5 0.5 1; #X obj 184 115 translateXYZ -1.5 1.5 0; #X obj 184 347 translateXYZ -1.5 -2 0; #X obj 545 164 alpha; #X obj 545 87 color 0 1 0 0.5; #X obj 545 140 rotate 114 0 1 0; #X msg 455 188 draw line; #X msg 455 165 draw fill; #X obj 545 66 gemhead; #X obj 545 205 tube 0.5; #X obj 545 113 translateXYZ 1.5 1.5 0; #X obj 545 406 alpha; #X obj 545 382 rotate 114 0 1 0; #X msg 455 430 draw line; #X msg 455 407 draw fill; #X obj 545 308 gemhead; #X obj 545 355 translateXYZ 1.5 -1.5 0; #X obj 545 447 sphere 0.5; #X obj 545 329 color 0 1 0 0.5; #X obj 403 26 cnv 15 100 60 empty empty empty 20 12 0 14 -258699 -66577 0; #N canvas 0 22 450 300 gemwin 0; #X obj 132 136 gemwin; #X obj 67 89 outlet; #X obj 67 10 inlet; #X obj 67 41 route create; #X msg 67 70 set destroy; #X msg 142 68 set create; #X msg 132 112 create , 1; #X msg 198 112 destroy; #X connect 2 0 3 0; #X connect 3 0 4 0; #X connect 3 0 6 0; #X connect 3 1 5 0; #X connect 3 1 7 0; #X connect 4 0 1 0; #X connect 5 0 1 0; #X connect 6 0 0 0; #X connect 7 0 0 0; #X restore 420 57 pd gemwin; #X msg 420 38 destroy; #X text 12 34 here full & fill , but it messes up the vertices; #X text 20 273 here full & fill , but it messes up the vertices; #X text 452 261 here it s fine; #X connect 0 0 15 0; #X connect 1 0 17 0; #X connect 2 0 0 0; #X connect 3 0 15 0; #X connect 4 0 15 0; #X connect 5 0 15 0; #X connect 6 0 1 0; #X connect 7 0 14 0; #X connect 8 0 16 0; #X connect 9 0 7 0; #X connect 10 0 14 0; #X connect 11 0 14 0; #X connect 12 0 14 0; #X connect 13 0 8 0; #X connect 16 0 9 0; #X connect 17 0 2 0; #X connect 18 0 24 0; #X connect 19 0 25 0; #X connect 20 0 18 0; #X connect 21 0 24 0; #X connect 22 0 24 0; #X connect 23 0 19 0; #X connect 25 0 20 0; #X connect 26 0 32 0; #X connect 27 0 26 0; #X connect 28 0 32 0; #X connect 29 0 32 0; #X connect 30 0 33 0; #X connect 31 0 27 0; #X connect 33 0 31 0; #X connect 35 0 36 0; #X connect 36 0 35 0;
#N canvas 623 262 744 536 10; #X obj 117 276 alpha; #X obj 184 89 color 0 1 0 0.5; #X obj 184 112 rotate 114 0 1 0; #X obj 184 68 gemhead; #X obj 258 324 cube 0.5; #X obj 182 139 translateXYZ -1.5 1.5 0; #X obj 545 164 alpha; #X obj 545 87 color 0 1 0 0.5; #X obj 545 140 rotate 114 0 1 0; #X msg 455 188 draw line; #X msg 455 165 draw fill; #X obj 545 66 gemhead; #X obj 545 205 tube 0.5; #X obj 545 113 translateXYZ 1.5 1.5 0; #X obj 545 406 alpha; #X obj 545 382 rotate 114 0 1 0; #X msg 455 430 draw line; #X msg 455 407 draw fill; #X obj 545 308 gemhead; #X obj 545 355 translateXYZ 1.5 -1.5 0; #X obj 545 447 sphere 0.5; #X obj 545 329 color 0 1 0 0.5; #X text 11 25 here full & fill , but it messes up the vertices; #X text 452 261 here it s fine; #X msg 163 289 draw line; #X msg 15 278 draw fill; #X msg 15 255 draw full; #X obj 98 326 cuboid 0.5 0.5 1; #X obj 159 245 spigot; #X obj 184 219 == 0; #X obj 249 245 spigot; #X obj 274 219 == 1; #X obj 80 109 vradio 15 1 0 2 empty empty empty 0 -6 0 8 -262144 -1 -1 1; #X msg 333 288 draw line; #X msg 266 283 draw fill; #X obj 31 372 pt.light; #X obj 384 116 gemwin; #X msg 376 13 create , 1; #X msg 383 38 0 , destroy; #X msg 414 93 lighting $1; #X obj 412 65 tgl 15 0 empty empty empty 0 -6 0 8 -262144 -1 -1 0 1 ; #X connect 1 0 2 0; #X connect 2 0 5 0; #X connect 3 0 1 0; #X connect 5 0 28 0; #X connect 5 0 30 0; #X connect 6 0 12 0; #X connect 7 0 13 0; #X connect 8 0 6 0; #X connect 9 0 12 0; #X connect 10 0 12 0; #X connect 11 0 7 0; #X connect 13 0 8 0; #X connect 14 0 20 0; #X connect 15 0 14 0; #X connect 16 0 20 0; #X connect 17 0 20 0; #X connect 18 0 21 0; #X connect 19 0 15 0; #X connect 21 0 19 0; #X connect 24 0 27 0; #X connect 25 0 27 0; #X connect 28 0 27 0; #X connect 29 0 28 1; #X connect 30 0 4 0; #X connect 31 0 30 1; #X connect 32 0 29 0; #X connect 32 0 31 0; #X connect 33 0 4 0; #X connect 34 0 4 0; #X connect 37 0 36 0; #X connect 38 0 36 0; #X connect 39 0 36 0; #X connect 40 0 39 0;
#N canvas 607 382 130 132 10; #X obj 1 1 cnv 5 128 130 empty empty $1-Light 5 7 1 11 -133153 -1 0; #X obj 113 3 bng 11 250 50 0 $0-reset $0- Reset -25 6 1 8 -262144 -1 -1; #X obj 34 39 hsl 60 15 0 1 0 0 $0-r $0-sc empty -2 -6 2 8 -258699 -1 -1 5900 1; #X obj 34 56 hsl 60 15 0 1 0 0 $0-g $0-sc empty -2 -6 2 8 -24198 -1 -1 5900 1; #X obj 34 73 hsl 60 15 0 1 0 0 $0-b $0-sc empty -2 -6 2 8 -62784 -1 -1 5900 1; #X obj 14 111 hsl 100 15 -2 7 0 0 $0-z $0-sz empty -2 -6 2 8 -262144 -1 -1 6600 1; #X obj 11 35 vsl 15 70 -4 4 0 0 $0-y $0-sxy empty 0 -8 2 8 -262144 -1 -1 3450 1; #X obj 29 18 hsl 70 15 -4 4 0 0 $0-x $0-sxy empty -2 -6 2 8 -262144 -1 -1 3450 1; #X obj 101 33 cnv 15 15 75 empty empty empty 20 12 0 14 -166441 -66577 0; #X obj 34 90 hsl 60 15 0 1 0 0 $0-sc $0-sb empty -2 -6 2 8 -262144 -1 -1 5900 1; #N canvas 518 270 481 403 interna 0; #X obj 19 127 translateXYZ; #N canvas 736 91 337 192 defaults 0; #X obj 151 25 r $0-reset; #X msg 30 69 1; #X obj 30 90 s $0-sc; #X obj 87 90 s $0-sxy; #X msg 87 69 0; #X msg 151 69 4; #X obj 151 90 s $0-sz; #X obj 15 112 s $0-sb; #X obj 30 26 bang; #X obj 30 5 inlet; #X connect 0 0 5 0; #X connect 0 0 4 0; #X connect 0 0 1 0; #X connect 1 0 2 0; #X connect 1 0 7 0; #X connect 4 0 3 0; #X connect 5 0 6 0; #X connect 8 0 1 0; #X connect 8 0 4 0; #X connect 8 0 5 0; #X connect 9 0 8 0; #X restore 241 185 pd defaults; #X obj 29 86 interp3 $0-x $0-y $0-z; #X obj 19 325 light; #X obj 49 285 pack f f f; #X obj 125 285 bang; #X text 7 3 Light; #X obj 18 44 gemhead 5; #N canvas 632 292 525 452 memento 0; #X obj 29 66 t b f; #X msg 29 90 set; #X msg 59 90 substate $1; #X obj 222 237 route osc; #X obj 29 46 r pt.currentPreset; #X obj 305 75 inlet; #X obj 66 281 originator /pt/light $0; #X obj 84 253 prepend create; #X obj 84 225 list2osc; #X msg 84 200 pt light $1; #X obj 84 179 f $1; #X obj 69 120 loadbang; #X text 16 9 Here we are using the first creation argument to pt.light as the instance number. 1-8; #X obj 53 150 t b b; #X obj 53 328 outlet; #X connect 0 0 1 0; #X connect 0 1 2 0; #X connect 1 0 6 0; #X connect 2 0 6 0; #X connect 3 0 6 1; #X connect 4 0 0 0; #X connect 5 0 3 0; #X connect 7 0 6 0; #X connect 8 0 7 0; #X connect 9 0 8 0; #X connect 10 0 9 0; #X connect 11 0 13 0; #X connect 13 0 14 0; #X connect 13 1 10 0; #X restore 241 139 pd memento; #X obj 241 117 r pt.osc; #X text 210 93 receive OSC on pt.osc; #X obj 241 162 delay 25; #X text 32 362 Added interpolation for light colours (for state-animation) ; #X obj 49 241 interp3 $0-r $0-g $0-b; #X connect 0 0 3 0; #X connect 2 0 0 1; #X connect 2 1 0 2; #X connect 2 2 0 3; #X connect 4 0 3 1; #X connect 5 0 4 0; #X connect 7 0 0 0; #X connect 8 0 11 0; #X connect 9 0 8 0; #X connect 11 0 1 0; #X connect 13 0 4 0; #X connect 13 1 4 1; #X connect 13 1 5 0; #X connect 13 2 4 2; #X connect 13 2 5 0; #X restore 11 141 pd interna; #X obj 157 55 commun /r $0; #X obj 157 74 commun /g $0; #X obj 157 93 commun /b $0; #X obj 157 16 commun /x $0; #X obj 157 36 commun /y $0; #X obj 157 112 commun /z $0; #X connect 2 0 11 0; #X connect 3 0 12 0; #X connect 4 0 13 0; #X connect 5 0 16 0; #X connect 6 0 15 0; #X connect 7 0 14 0; #X connect 11 0 2 0; #X connect 12 0 3 0; #X connect 13 0 4 0; #X connect 14 0 7 0; #X connect 15 0 6 0; #X connect 16 0 5 0; #X coords 0 0 0.00214592 0.00316456 130 132 1;
The default drawing style is GL_QUADS or | draw quad (.
The drawing style for | draw fill ( is GL_POLYGON.
There is a difference between the two, so use whichever one is more appropriate. There is no coding error in GEM as far as I can tell.
I suppose we could add a | draw default ( to GemShape base class that each Geo would populate with the proper value. I did something similar to this with the vertex_arrays.
cgc
On Mar 29, 2005, at 2:54 PM, Erich Berger wrote:
hi,
attached u find a patch which shows that when one sends a |draw full( or |draw fill( to cube or cuboid, ( thats the ones i noticed) the vertices drawing gets messed up. in opposite sphere and tube are working as it should.
this is just visible with alpha enabeled and happens for example if one switches back from drawing a geo as line to fill mode.
esp. strange is that a |draw full( message is doing something, as its everywhere called "fill" in the src, but maybe this points already to a possible errorsource ?
cheers
erich
http://randomseed.org<bugtest.pd>
Actually, to be more correct, all Geos are not created equal. Certain Geos, like sphere and cylinder, use a a library called GLU which handles everything about drawing those shapes. The others are rolled by hand by the GEM developers. The main difference is that the two types have different base classes. The drawing types are not the same between them, which is why GL_QUADS doesn't really do anything. I don't know if that's even supported by GLU as it's not really an appropriate mode for those shapes.
Perhaps there should be a tutorial or help patch explaining this...
The default drawing style is GL_QUADS or | draw quad (.
The drawing style for | draw fill ( is GL_POLYGON.
There is a difference between the two, so use whichever one is more appropriate. There is no coding error in GEM as far as I can tell.
the difference i can see :-), allthough it might be not a bug it is inconsistent as different geos have different behaviours and with some of the handrolled its not possible to switch back to GL_QUADS once draw fill is used.
but thx for pointing out the difference so i can change this locally until a solution is found.
cheers
erich
replying to my own message - uff
sorry i should have read your mail more carefully but now i got it: a |draw quad( is sufficient to bring it back to normal.
cheers
e
On Wed, 30 Mar 2005, Erich Berger wrote:
The default drawing style is GL_QUADS or | draw quad (.
The drawing style for | draw fill ( is GL_POLYGON.
There is a difference between the two, so use whichever one is more appropriate. There is no coding error in GEM as far as I can tell.
the difference i can see :-), allthough it might be not a bug it is inconsistent as different geos have different behaviours and with some of the handrolled its not possible to switch back to GL_QUADS once draw fill is used.
but thx for pointing out the difference so i can change this locally until a solution is found.
cheers
erich
GEM-dev mailing list GEM-dev@iem.at http://iem.at/cgi-bin/mailman/listinfo/gem-dev
Cool, Thanks Johannes.
I was just having a vision for my dynamic pixelTANGO geo switcher needing to test which geo it was and to send the proper value. Yuck!
B.
IOhannes m zmoelnig wrote:
chris clepper wrote:
I suppose we could add a | draw default ( to GemShape base class that each Geo would populate with the proper value.
since i think this is a very good idea i have done so and added it to the CVS.
mfg.asd.r IOhannes
GEM-dev mailing list GEM-dev@iem.at http://iem.at/cgi-bin/mailman/listinfo/gem-dev
On Mar 30, 2005, at 2:02 PM, IOhannes m zmoelnig wrote:
chris clepper wrote:
I suppose we could add a | draw default ( to GemShape base class that each Geo would populate with the proper value.
since i think this is a very good idea i have done so and added it to the CVS.
hey IOhannes,
...finally (busy busy) trying to add my stuff to GemPixUtil.cpp, but I notice that as of today's commit by you, the crazy poynton #define's aren't there: I like it in that it does make the file cleaner and more readable/understandable, but I just want to make sure that this is the way we're going to go with it, as my current file is based on the #define-orama version ;-)
l8r, james
james tittle wrote:
...finally (busy busy) trying to add my stuff to GemPixUtil.cpp, but I notice that as of today's commit by you, the crazy poynton #define's aren't there: I like it in that it does make the file cleaner and more readable/understandable, but I just want to make sure that this is the way we're going to go with it, as my current file is based on the #define-orama version ;-)
oops; obviously i had incidentally checked in another version of the poyntonified conversion routines....
mea culpa
however, it was not the check-in yesterday that was missing the defines (GemPixUtil.cpp wasn't even touched) but rather one week ago (when i initially committed the poynton-conversion)
i had sent you the correct version with the crazy ifdefs.
to get the history right, i have now checked in the good version...
thanks for pointing that one out. mfg.ads.r IOhannes
IOhannes m zmoelnig wrote:
chris clepper wrote:
I suppose we could add a | draw default ( to GemShape base class that each Geo would populate with the proper value.
since i think this is a very good idea i have done so and added it to the CVS.
and by now i should have been able to commit a working version....
mfg..sadr IOhannes