Hey all,
In trying to build a 32x24 control point curve3d I realized a nasty bug.
Seems that if you use curve3d with more than 8x8 (linux) and 10x10 (OSX) points you get into some trouble. In some cases it seems that the 8x9 grid on linux will simply never render a curve3d shape. If you have two curve3d's in a patch and one of them is 8x9 or bigger it actually interacts with the other 8x8 curve3d.
The attached patch shows the interaction bug. Changing both to 8x8 fixes the problem. If your on OSX you'll need to change the curve3d size to 10x10 and 10x11 respectively.
Happens on my fresh gem CVS on linux and an older (6 months+) CVS on OSX.
Thanks!
b>
#N canvas 604 283 541 542 10; #N canvas 79 562 455 304 gemwin 0; #X obj 132 182 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 198 112 destroy; #X msg 132 112 create , 1; #X obj 207 134 loadbang; #X msg 207 155 lighting 0; #X connect 2 0 3 0; #X connect 3 0 4 0; #X connect 3 0 7 0; #X connect 3 1 5 0; #X connect 3 1 6 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 connect 8 0 9 0; #X connect 9 0 0 0; #X restore 26 61 pd gemwin; #X msg 26 42 create; #X text 22 21 Create window:; #X obj 27 118 gemhead; #X floatatom 55 161 5 0 0 0 - - -; #X floatatom 90 161 5 0 0 0 - - -; #X floatatom 126 161 5 0 0 0 - - -; #X floatatom 95 119 5 0 0 0 - - -; #X floatatom 143 119 5 0 0 0 - - -; #X floatatom 192 119 5 0 0 0 - - -; #X obj 27 182 rotateXYZ 0 0 0; #X floatatom 113 268 5 0 0 0 - - -; #X obj 28 221 colorRGB 1 0 0; #X obj 27 139 translateXYZ -2.5 0 0; #X obj 247 118 gemhead; #X floatatom 275 161 5 0 0 0 - - -; #X floatatom 310 161 5 0 0 0 - - -; #X floatatom 346 161 5 0 0 0 - - -; #X floatatom 315 119 5 0 0 0 - - -; #X floatatom 363 119 5 0 0 0 - - -; #X floatatom 412 119 5 0 0 0 - - -; #X obj 247 182 rotateXYZ 0 0 0; #X msg 267 291 set 0 0 0 0 $1; #X floatatom 333 268 5 0 0 0 - - -; #X obj 27 344 curve3d 8 8; #X obj 249 221 colorRGB 0 1 0; #X obj 247 139 translateXYZ -2.5 -2 0; #X msg 47 291 set 0 0 0 0 $1; #X obj 247 344 curve3d 8 9; #X obj 338 344 cnv 15 15 15 empty empty empty 20 12 0 14 -260818 -66577 0; #X text 23 407 If you change the second curve3d to 8x8 then it works as expected. Change back to 8x9 and then the two get confused again. Seems this is happening on my OSX machine as well (except only when using a 10x11 or bigger grid) , using a much older CVS version.; #X text 25 365 For OSX: 10 10; #X text 247 366 For OSX: 10 11; #X text 129 42 Curve3d is acting very odd when using lots of control points. My aim is at least a 32x24 curve3d.; #X connect 0 0 1 0; #X connect 1 0 0 0; #X connect 3 0 13 0; #X connect 4 0 10 1; #X connect 5 0 10 2; #X connect 6 0 10 3; #X connect 7 0 13 1; #X connect 8 0 13 2; #X connect 9 0 13 3; #X connect 10 0 12 0; #X connect 11 0 27 0; #X connect 12 0 24 0; #X connect 13 0 10 0; #X connect 14 0 26 0; #X connect 15 0 21 1; #X connect 16 0 21 2; #X connect 17 0 21 3; #X connect 18 0 26 1; #X connect 19 0 26 2; #X connect 20 0 26 3; #X connect 21 0 25 0; #X connect 22 0 28 0; #X connect 23 0 22 0; #X connect 25 0 28 0; #X connect 26 0 21 0; #X connect 27 0 24 0;
hello,
your patch works for me. i've got a problem with more than 30x24 control points : changing control point does have no effect. it's the only problem i've got.
anyway : curve3d is very slow, creating a 32x24 control point will use all CPU of a standart computer.
i've got a standart gem version.
hum, strange. cyrille
B. Bogart a écrit :
Hey all,
In trying to build a 32x24 control point curve3d I realized a nasty bug.
Seems that if you use curve3d with more than 8x8 (linux) and 10x10 (OSX) points you get into some trouble. In some cases it seems that the 8x9 grid on linux will simply never render a curve3d shape. If you have two curve3d's in a patch and one of them is 8x9 or bigger it actually interacts with the other 8x8 curve3d.
The attached patch shows the interaction bug. Changing both to 8x8 fixes the problem. If your on OSX you'll need to change the curve3d size to 10x10 and 10x11 respectively.
Happens on my fresh gem CVS on linux and an older (6 months+) CVS on OSX.
Thanks!
b>
#N canvas 604 283 541 542 10; #N canvas 79 562 455 304 gemwin 0; #X obj 132 182 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 198 112 destroy; #X msg 132 112 create , 1; #X obj 207 134 loadbang; #X msg 207 155 lighting 0; #X connect 2 0 3 0; #X connect 3 0 4 0; #X connect 3 0 7 0; #X connect 3 1 5 0; #X connect 3 1 6 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 connect 8 0 9 0; #X connect 9 0 0 0; #X restore 26 61 pd gemwin; #X msg 26 42 create; #X text 22 21 Create window:; #X obj 27 118 gemhead; #X floatatom 55 161 5 0 0 0 - - -; #X floatatom 90 161 5 0 0 0 - - -; #X floatatom 126 161 5 0 0 0 - - -; #X floatatom 95 119 5 0 0 0 - - -; #X floatatom 143 119 5 0 0 0 - - -; #X floatatom 192 119 5 0 0 0 - - -; #X obj 27 182 rotateXYZ 0 0 0; #X floatatom 113 268 5 0 0 0 - - -; #X obj 28 221 colorRGB 1 0 0; #X obj 27 139 translateXYZ -2.5 0 0; #X obj 247 118 gemhead; #X floatatom 275 161 5 0 0 0 - - -; #X floatatom 310 161 5 0 0 0 - - -; #X floatatom 346 161 5 0 0 0 - - -; #X floatatom 315 119 5 0 0 0 - - -; #X floatatom 363 119 5 0 0 0 - - -; #X floatatom 412 119 5 0 0 0 - - -; #X obj 247 182 rotateXYZ 0 0 0; #X msg 267 291 set 0 0 0 0 $1; #X floatatom 333 268 5 0 0 0 - - -; #X obj 27 344 curve3d 8 8; #X obj 249 221 colorRGB 0 1 0; #X obj 247 139 translateXYZ -2.5 -2 0; #X msg 47 291 set 0 0 0 0 $1; #X obj 247 344 curve3d 8 9; #X obj 338 344 cnv 15 15 15 empty empty empty 20 12 0 14 -260818 -66577 0; #X text 23 407 If you change the second curve3d to 8x8 then it works as expected. Change back to 8x9 and then the two get confused again. Seems this is happening on my OSX machine as well (except only when using a 10x11 or bigger grid) , using a much older CVS version.; #X text 25 365 For OSX: 10 10; #X text 247 366 For OSX: 10 11; #X text 129 42 Curve3d is acting very odd when using lots of control points. My aim is at least a 32x24 curve3d.; #X connect 0 0 1 0; #X connect 1 0 0 0; #X connect 3 0 13 0; #X connect 4 0 10 1; #X connect 5 0 10 2; #X connect 6 0 10 3; #X connect 7 0 13 1; #X connect 8 0 13 2; #X connect 9 0 13 3; #X connect 10 0 12 0; #X connect 11 0 27 0; #X connect 12 0 24 0; #X connect 13 0 10 0; #X connect 14 0 26 0; #X connect 15 0 21 1; #X connect 16 0 21 2; #X connect 17 0 21 3; #X connect 18 0 26 1; #X connect 19 0 26 2; #X connect 20 0 26 3; #X connect 21 0 25 0; #X connect 22 0 28 0; #X connect 23 0 22 0; #X connect 25 0 28 0; #X connect 26 0 21 0; #X connect 27 0 24 0;
GEM-dev mailing list GEM-dev@iem.at http://lists.puredata.info/listinfo/gem-dev
Hey Cyrille,
The problem I had seemed to be related to the bug with control points not responding. I have come accross this so many times recently in different ways. The bug either represented itself as a lack of control of the point, OR controlling a second curve3d object. Both things always happening when trying to use control points beyond a certain size. I also had some problems with a single curve3d 32x24 not rendering at all! (as if there was no gemhead connected)
I think the size is machine dependant, did you try counting up from 8x8 to 30x24 to see if the patch caused the bug at any point? I downloaded gem0.90 for linux as well and it still does the same thing.
why would 32x24 control points be a problem if #1: less res was used, 32x24 for example, #2 if the points where not moved very often, #3 if we're drawing only the control points and not the curve itself etc.. ?
Hopefully someone out there can reproduce this problem. I do think it is the same bug as the control point issue you talk about, just another effect of it. seems to be display-list related...
B>
cyrille henry wrote:
hello,
your patch works for me. i've got a problem with more than 30x24 control points : changing control point does have no effect. it's the only problem i've got.
anyway : curve3d is very slow, creating a 32x24 control point will use all CPU of a standart computer.
i've got a standart gem version.
hum, strange. cyrille
B. Bogart a écrit :
Hey all,
In trying to build a 32x24 control point curve3d I realized a nasty bug.
Seems that if you use curve3d with more than 8x8 (linux) and 10x10 (OSX) points you get into some trouble. In some cases it seems that the 8x9 grid on linux will simply never render a curve3d shape. If you have two curve3d's in a patch and one of them is 8x9 or bigger it actually interacts with the other 8x8 curve3d.
The attached patch shows the interaction bug. Changing both to 8x8 fixes the problem. If your on OSX you'll need to change the curve3d size to 10x10 and 10x11 respectively.
Happens on my fresh gem CVS on linux and an older (6 months+) CVS on OSX.
Thanks!
b>
#N canvas 604 283 541 542 10; #N canvas 79 562 455 304 gemwin 0; #X obj 132 182 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 198 112 destroy; #X msg 132 112 create , 1; #X obj 207 134 loadbang; #X msg 207 155 lighting 0; #X connect 2 0 3 0; #X connect 3 0 4 0; #X connect 3 0 7 0; #X connect 3 1 5 0; #X connect 3 1 6 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 connect 8 0 9 0; #X connect 9 0 0 0; #X restore 26 61 pd gemwin; #X msg 26 42 create; #X text 22 21 Create window:; #X obj 27 118 gemhead; #X floatatom 55 161 5 0 0 0 - - -; #X floatatom 90 161 5 0 0 0 - - -; #X floatatom 126 161 5 0 0 0 - - -; #X floatatom 95 119 5 0 0 0 - - -; #X floatatom 143 119 5 0 0 0 - - -; #X floatatom 192 119 5 0 0 0 - - -; #X obj 27 182 rotateXYZ 0 0 0; #X floatatom 113 268 5 0 0 0 - - -; #X obj 28 221 colorRGB 1 0 0; #X obj 27 139 translateXYZ -2.5 0 0; #X obj 247 118 gemhead; #X floatatom 275 161 5 0 0 0 - - -; #X floatatom 310 161 5 0 0 0 - - -; #X floatatom 346 161 5 0 0 0 - - -; #X floatatom 315 119 5 0 0 0 - - -; #X floatatom 363 119 5 0 0 0 - - -; #X floatatom 412 119 5 0 0 0 - - -; #X obj 247 182 rotateXYZ 0 0 0; #X msg 267 291 set 0 0 0 0 $1; #X floatatom 333 268 5 0 0 0 - - -; #X obj 27 344 curve3d 8 8; #X obj 249 221 colorRGB 0 1 0; #X obj 247 139 translateXYZ -2.5 -2 0; #X msg 47 291 set 0 0 0 0 $1; #X obj 247 344 curve3d 8 9; #X obj 338 344 cnv 15 15 15 empty empty empty 20 12 0 14 -260818 -66577 0; #X text 23 407 If you change the second curve3d to 8x8 then it works as expected. Change back to 8x9 and then the two get confused again. Seems this is happening on my OSX machine as well (except only when using a 10x11 or bigger grid) , using a much older CVS version.; #X text 25 365 For OSX: 10 10; #X text 247 366 For OSX: 10 11; #X text 129 42 Curve3d is acting very odd when using lots of control points. My aim is at least a 32x24 curve3d.; #X connect 0 0 1 0; #X connect 1 0 0 0; #X connect 3 0 13 0; #X connect 4 0 10 1; #X connect 5 0 10 2; #X connect 6 0 10 3; #X connect 7 0 13 1; #X connect 8 0 13 2; #X connect 9 0 13 3; #X connect 10 0 12 0; #X connect 11 0 27 0; #X connect 12 0 24 0; #X connect 13 0 10 0; #X connect 14 0 26 0; #X connect 15 0 21 1; #X connect 16 0 21 2; #X connect 17 0 21 3; #X connect 18 0 26 1; #X connect 19 0 26 2; #X connect 20 0 26 3; #X connect 21 0 25 0; #X connect 22 0 28 0; #X connect 23 0 22 0; #X connect 25 0 28 0; #X connect 26 0 21 0; #X connect 27 0 24 0;
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
B. Bogart a écrit :
Hey Cyrille,
The problem I had seemed to be related to the bug with control points not responding. I have come accross this so many times recently in different ways. The bug either represented itself as a lack of control of the point, OR controlling a second curve3d object. Both things always happening when trying to use control points beyond a certain size. I also had some problems with a single curve3d 32x24 not rendering at all! (as if there was no gemhead connected)
I think the size is machine dependant, did you try counting up from 8x8 to 30x24 to see if the patch caused the bug at any point?
i did not try all possibility, but it look like the bug is as soon as a curve3d is created with more than 30 points (X and/or Y).
I downloaded gem0.90 for linux as well and it still does the same thing.
i don't thik there was any change in curve3d object since the 0.90 release, so it's not surprising.
why would 32x24 control points be a problem if #1: less res was used, 32x24 for example, #2 if the points where not moved very often, #3 if we're drawing only the control points and not the curve itself etc.. ?
on my computer it does work with any size if i draw only the control points. So, i think the opengl command : glEvalCoord2f is limited to a sepecific size, depending on the openGL implementation of your hardware (or driver, as this is usualy not hardware accelerated).
Size is limited in the curve3d code to 50x50.
Hopefully someone out there can reproduce this problem. I do think it is the same bug as the control point issue you talk about,
i think so.
cyrille
just another effect of it. seems to be display-list related...
B>
cyrille henry wrote:
hello,
your patch works for me. i've got a problem with more than 30x24 control points : changing control point does have no effect. it's the only problem i've got.
anyway : curve3d is very slow, creating a 32x24 control point will use all CPU of a standart computer.
i've got a standart gem version.
hum, strange. cyrille
B. Bogart a écrit :
Hey all,
In trying to build a 32x24 control point curve3d I realized a nasty bug.
Seems that if you use curve3d with more than 8x8 (linux) and 10x10 (OSX) points you get into some trouble. In some cases it seems that the 8x9 grid on linux will simply never render a curve3d shape. If you have two curve3d's in a patch and one of them is 8x9 or bigger it actually interacts with the other 8x8 curve3d.
The attached patch shows the interaction bug. Changing both to 8x8 fixes the problem. If your on OSX you'll need to change the curve3d size to 10x10 and 10x11 respectively.
Happens on my fresh gem CVS on linux and an older (6 months+) CVS on OSX.
Thanks!
b>
#N canvas 604 283 541 542 10; #N canvas 79 562 455 304 gemwin 0; #X obj 132 182 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 198 112 destroy; #X msg 132 112 create , 1; #X obj 207 134 loadbang; #X msg 207 155 lighting 0; #X connect 2 0 3 0; #X connect 3 0 4 0; #X connect 3 0 7 0; #X connect 3 1 5 0; #X connect 3 1 6 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 connect 8 0 9 0; #X connect 9 0 0 0; #X restore 26 61 pd gemwin; #X msg 26 42 create; #X text 22 21 Create window:; #X obj 27 118 gemhead; #X floatatom 55 161 5 0 0 0 - - -; #X floatatom 90 161 5 0 0 0 - - -; #X floatatom 126 161 5 0 0 0 - - -; #X floatatom 95 119 5 0 0 0 - - -; #X floatatom 143 119 5 0 0 0 - - -; #X floatatom 192 119 5 0 0 0 - - -; #X obj 27 182 rotateXYZ 0 0 0; #X floatatom 113 268 5 0 0 0 - - -; #X obj 28 221 colorRGB 1 0 0; #X obj 27 139 translateXYZ -2.5 0 0; #X obj 247 118 gemhead; #X floatatom 275 161 5 0 0 0 - - -; #X floatatom 310 161 5 0 0 0 - - -; #X floatatom 346 161 5 0 0 0 - - -; #X floatatom 315 119 5 0 0 0 - - -; #X floatatom 363 119 5 0 0 0 - - -; #X floatatom 412 119 5 0 0 0 - - -; #X obj 247 182 rotateXYZ 0 0 0; #X msg 267 291 set 0 0 0 0 $1; #X floatatom 333 268 5 0 0 0 - - -; #X obj 27 344 curve3d 8 8; #X obj 249 221 colorRGB 0 1 0; #X obj 247 139 translateXYZ -2.5 -2 0; #X msg 47 291 set 0 0 0 0 $1; #X obj 247 344 curve3d 8 9; #X obj 338 344 cnv 15 15 15 empty empty empty 20 12 0 14 -260818 -66577 0; #X text 23 407 If you change the second curve3d to 8x8 then it works as expected. Change back to 8x9 and then the two get confused again. Seems this is happening on my OSX machine as well (except only when using a 10x11 or bigger grid) , using a much older CVS version.; #X text 25 365 For OSX: 10 10; #X text 247 366 For OSX: 10 11; #X text 129 42 Curve3d is acting very odd when using lots of control points. My aim is at least a 32x24 curve3d.; #X connect 0 0 1 0; #X connect 1 0 0 0; #X connect 3 0 13 0; #X connect 4 0 10 1; #X connect 5 0 10 2; #X connect 6 0 10 3; #X connect 7 0 13 1; #X connect 8 0 13 2; #X connect 9 0 13 3; #X connect 10 0 12 0; #X connect 11 0 27 0; #X connect 12 0 24 0; #X connect 13 0 10 0; #X connect 14 0 26 0; #X connect 15 0 21 1; #X connect 16 0 21 2; #X connect 17 0 21 3; #X connect 18 0 26 1; #X connect 19 0 26 2; #X connect 20 0 26 3; #X connect 21 0 25 0; #X connect 22 0 28 0; #X connect 23 0 22 0; #X connect 25 0 28 0; #X connect 26 0 21 0; #X connect 27 0 24 0;
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
GEM-dev mailing list GEM-dev@iem.at http://lists.puredata.info/listinfo/gem-dev
I wrote an object called pix_record today that makes Quicktime movies on OSX. I went ahead and checked it into the main branch. I threw an #ifdef __APPLE__ around everything in the .h and .cpp file so it shouldn't mess up other platform compilations.
The object is not complete but I wanted to work on it in more than one place so up it went. Surprisingly, the dialog box works although it never gets proper focus - just don't hit any of the buttons labeled 'Options...' in the compression settings and you'll be fine. I will hopefully have a more programmatic way to setup compression working soon, but it's going to take some unravelling of QT innards to get there.
Apparently only a few minor changes are needed to get this working on Windows, but I still don't have a copy of VC++ yet, so that will have to wait. Anyone else who wants to give it a crack, go right ahead. I have no idea how Linux would handle this, but there might be a way to cover all platforms with the same object (like pix_film, but not pix_texture!).
cgc
chris clepper wrote:
I wrote an object called pix_record today that makes Quicktime movies on OSX. I went ahead and checked it into the main branch. I threw an #ifdef __APPLE__ around everything in the .h and .cpp file so it shouldn't mess up other platform compilations.
The object is not complete but I wanted to work on it in more than one place so up it went. Surprisingly, the dialog box works although it never gets proper focus - just don't hit any of the buttons labeled 'Options...' in the compression settings and you'll be fine. I will hopefully have a more programmatic way to setup compression working soon, but it's going to take some unravelling of QT innards to get there.
great. just one question (that keeps me bothering with [pix_write] for a long, long time): wouldn't it be better if [pix_record] would work on pix-buffers rather than on the render-buffer ? this basically means using 2 objects [pix_snapshot] (or probably some improved version of it) and [pix_record] where now we only need 1 object.
but i have heard rumours of people who just use the pix-input capabilities of Gem (admittedly not the real strength of Gem) and don't care for texturing and the like; and want to directly record the pix-stream with [pix_write] (and the current [pix_record]) they would have to go through capturing-texturing-grabbing-recording, which works in theory, but not if you want to record things while you are displaying something different (e.g. to do large delay-lines)
apart from that it is really a long missing object.
all platforms with the same object (like pix_film, but not pix_texture!).
;-)
mfg.mgh.asd. IOhannes
Hi Chris,
I wrote an object called pix_record today that makes Quicktime movies on OSX. I went ahead and checked it into the main
These are great news - such an object had been asked for many, many times in the past. No more workarounds like capturing from screen or assemble thousands of tiffs to a movie again ... Thank you. One thing bothers me: Apples MPEG4-Implementation is known to be rather inferior when compared to xvid etc. What codecs does quicktime actually support? And wouln't it be feasible to use a more open platform (like ffmpeg or theora) to do this? theora would have the added benefit of producing streaming video ... Then again, I don't know too much about OSX and even less about its multimedia framework, so don't feel bothered if I talk bs here.
Apparently only a few minor changes are needed to get this working on Windows, but I still don't have a copy of VC++ yet, so that will have to wait. Anyone else who wants to give it a crack, go right ahead. I
I could give it a go with Dev-Cpp (uses the MinGW port of the GNU utils), but that would have to wait until next week ...
with kind regards, Thoralf.
___________________________________________________________ How much free photo storage do you get? Store your holiday snaps for FREE with Yahoo! Photos http://uk.photos.yahoo.com
Quoting Thoralf Schulze thoralf_schulze@yahoo.de:
One thing bothers me: Apples MPEG4-Implementation is known to be rather inferior when compared to xvid etc. What codecs does quicktime actually support? And wouln't it be feasible to use a more open platform (like ffmpeg or theora) to do this? theora would have the added benefit of producing streaming video ... Then again, I don't know too much about OSX and even less about its multimedia framework, so don't feel bothered if I talk bs here.
MPEG4, Divx and the like are not suited for use with this object because they are designed as delivery and not production codecs. These do not perform well in real-time encodng and are so lossy you cannot really do any additional processing or editing with them afterwards. This object is designed to be used with uncompressed 4:2:2, JPEG (Photo and Motion), DVC PAL/NTSC and DVCPRO HD which are all suitable for further processing. The open source alternatives do not really offer the support for production video that Quicktime does. That being said, there will be no limitations on the Quicktime codecs available for use, so you can attempt to use distribution codecs if you wish.
I am working on a way to allow any installed Quicktime codec to be used with pix_record. This is more of a user interface problem to be solved than anything else. Right now I can dump a numbered list of codecs to the console and also store them in an array. The idea is that the user can select the codec by number and use that. The list looks like this:
pix_record : codec 0 Animation 1919706400 ctype 65670 pix_record : codec 1 BMP 1465011269 ctype 131253 pix_record : codec 2 Cinepak 1668704612 ctype 65710 pix_record : codec 3 Component Video 2037741106 ctype 65725 pix_record : codec 4DV - PAL 1685480304 ctype 65679 pix_record : codec 5 DV/DVCPRO - NTSC 1685480224 ctype 65678 ... pix_record : codec 27 Sorenson Video 3 1398165811 ctype 65721 pix_record : codec 28 Sorenson Video 1398165809 ctype 65719
Those numbers after the name are actually constants stored into the array which really tell QT what to use. It's a bit of a pain.
Also, as I mentioned in the first post, the standard Quicktime compression dialog does work by holding down the command key and selecting a compressor that way.
I could give it a go with Dev-Cpp (uses the MinGW port of the GNU utils), but that would have to wait until next week ...
I would wait if you are not familiar with the Quicktime API. The object features some non-standard ways of using the API which might cause problems on Windows (or even OSX as I haven't fully tested it).
cgc
---------------------------------------------------------------- This message was sent using IMP, the Internet Messaging Program.
Hi Chris,
got your point about the the production vs. distribution codec issue. At the end of the day, it should be possible to reencode the content of a mov-container to mpeg4-within-avi, so this is not really an issue.
I could give it a go with Dev-Cpp (uses the MinGW
I would wait if you are not familiar with the Quicktime API. The object features some non-standard ways of using the API which might cause problems on Windows (or even OSX as I haven't fully tested it).
This does sound like a lot of tweaking :-) I actually succeeded to compile the quicktime-related stuff in filmQT, -Wno-multichar seems to be a necessity. Sadly enough, linking is another story - win has a limit regarding the length of the command line, and GEM breaks this with ease. Anyways, I'll be more than happy to give it a try next week.
with kind regards, Thoralf.
cgc
----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.
___________________________________________________________ Yahoo! Messenger - NEW crystal clear PC to PC calling worldwide with voicemail http://uk.messenger.yahoo.com
Thoralf Schulze wrote:
filmQT, -Wno-multichar seems to be a necessity. Sadly enough, linking is another story - win has a limit regarding the length of the command line, and GEM breaks this with ease.
yes, i forgot about that. you could try either removing the file-eating openGL-stuff (just remove the references to it from the makefile) or try linking with wildcards (openGL/*.obj or the like), which might get you around the length of the command line (i have no idea about how w32's cmd handles wildcards)
but to re-iterate my question (esp. to chris): would it be a big problem (in terms of performance: you know more about it than me) to separate the recorder from the snapshot into 2 objects ? it would really give more flexibility.
mfg.a.sdr IOhannes
Quoting IOhannes m zmoelnig zmoelnig@iem.at:
but to re-iterate my question (esp. to chris): would it be a big problem (in terms of performance: you know more about it than me) to separate the recorder from the snapshot into 2 objects ? it would really give more flexibility.
pix_record does not do glReadPixels, it only grabs images from the GemState. I did use pix_write as the template for pix_record which is probably the only reason it is built from the GemBase class and not PixObj class.
pix_record is YUV only, but I will add RGB at some point. I have to finish up the messaging for selecting codecs and quality levels as well.
cgc
PS - I need to get that server side spam filter cranked down a notch. the joys of having a paranoid admin.
---------------------------------------------------------------- This message was sent using IMP, the Internet Messaging Program.
chris clepper wrote:
Quoting IOhannes m zmoelnig zmoelnig@iem.at:
pix_record does not do glReadPixels, it only grabs images from the GemState. I did use pix_write as the template for pix_record which is probably the only reason it is built from the GemBase class and not PixObj class.
so i should have looked deeper into the code to discover all my wishes are already fullfilled.
great.
mfg.a.df IO 'being of for holidays' hannes
Hi,
For the first few versions I'll create one surface out of multiple curve3d patches. Since this is about the only option I have. I'll be controling the points of the curve3d using the python numarray extension.
Anyone else confirm curve3d weirdness? fixable? (should I post this to the bug tracker?)
B.
cyrille henry wrote:
B. Bogart a écrit :
Hey Cyrille,
The problem I had seemed to be related to the bug with control points not responding. I have come accross this so many times recently in different ways. The bug either represented itself as a lack of control of the point, OR controlling a second curve3d object. Both things always happening when trying to use control points beyond a certain size. I also had some problems with a single curve3d 32x24 not rendering at all! (as if there was no gemhead connected)
I think the size is machine dependant, did you try counting up from 8x8 to 30x24 to see if the patch caused the bug at any point?
i did not try all possibility, but it look like the bug is as soon as a curve3d is created with more than 30 points (X and/or Y).
I downloaded gem0.90 for linux as well and it still does the same thing.
i don't thik there was any change in curve3d object since the 0.90 release, so it's not surprising.
why would 32x24 control points be a problem if #1: less res was used, 32x24 for example, #2 if the points where not moved very often, #3 if we're drawing only the control points and not the curve itself etc.. ?
on my computer it does work with any size if i draw only the control points. So, i think the opengl command : glEvalCoord2f is limited to a sepecific size, depending on the openGL implementation of your hardware (or driver, as this is usualy not hardware accelerated).
Size is limited in the curve3d code to 50x50.
Hopefully someone out there can reproduce this problem. I do think it is the same bug as the control point issue you talk about,
i think so.
cyrille
just another effect of it. seems to be display-list related...
B>
cyrille henry wrote:
hello,
your patch works for me. i've got a problem with more than 30x24 control points : changing control point does have no effect. it's the only problem i've got.
anyway : curve3d is very slow, creating a 32x24 control point will use all CPU of a standart computer.
i've got a standart gem version.
hum, strange. cyrille
B. Bogart a écrit :
Hey all,
In trying to build a 32x24 control point curve3d I realized a nasty bug.
Seems that if you use curve3d with more than 8x8 (linux) and 10x10 (OSX) points you get into some trouble. In some cases it seems that the 8x9 grid on linux will simply never render a curve3d shape. If you have two curve3d's in a patch and one of them is 8x9 or bigger it actually interacts with the other 8x8 curve3d.
The attached patch shows the interaction bug. Changing both to 8x8 fixes the problem. If your on OSX you'll need to change the curve3d size to 10x10 and 10x11 respectively.
Happens on my fresh gem CVS on linux and an older (6 months+) CVS on OSX.
Thanks!
b>
#N canvas 604 283 541 542 10; #N canvas 79 562 455 304 gemwin 0; #X obj 132 182 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 198 112 destroy; #X msg 132 112 create , 1; #X obj 207 134 loadbang; #X msg 207 155 lighting 0; #X connect 2 0 3 0; #X connect 3 0 4 0; #X connect 3 0 7 0; #X connect 3 1 5 0; #X connect 3 1 6 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 connect 8 0 9 0; #X connect 9 0 0 0; #X restore 26 61 pd gemwin; #X msg 26 42 create; #X text 22 21 Create window:; #X obj 27 118 gemhead; #X floatatom 55 161 5 0 0 0 - - -; #X floatatom 90 161 5 0 0 0 - - -; #X floatatom 126 161 5 0 0 0 - - -; #X floatatom 95 119 5 0 0 0 - - -; #X floatatom 143 119 5 0 0 0 - - -; #X floatatom 192 119 5 0 0 0 - - -; #X obj 27 182 rotateXYZ 0 0 0; #X floatatom 113 268 5 0 0 0 - - -; #X obj 28 221 colorRGB 1 0 0; #X obj 27 139 translateXYZ -2.5 0 0; #X obj 247 118 gemhead; #X floatatom 275 161 5 0 0 0 - - -; #X floatatom 310 161 5 0 0 0 - - -; #X floatatom 346 161 5 0 0 0 - - -; #X floatatom 315 119 5 0 0 0 - - -; #X floatatom 363 119 5 0 0 0 - - -; #X floatatom 412 119 5 0 0 0 - - -; #X obj 247 182 rotateXYZ 0 0 0; #X msg 267 291 set 0 0 0 0 $1; #X floatatom 333 268 5 0 0 0 - - -; #X obj 27 344 curve3d 8 8; #X obj 249 221 colorRGB 0 1 0; #X obj 247 139 translateXYZ -2.5 -2 0; #X msg 47 291 set 0 0 0 0 $1; #X obj 247 344 curve3d 8 9; #X obj 338 344 cnv 15 15 15 empty empty empty 20 12 0 14 -260818 -66577 0; #X text 23 407 If you change the second curve3d to 8x8 then it works as expected. Change back to 8x9 and then the two get confused again. Seems this is happening on my OSX machine as well (except only when using a 10x11 or bigger grid) , using a much older CVS version.; #X text 25 365 For OSX: 10 10; #X text 247 366 For OSX: 10 11; #X text 129 42 Curve3d is acting very odd when using lots of control points. My aim is at least a 32x24 curve3d.; #X connect 0 0 1 0; #X connect 1 0 0 0; #X connect 3 0 13 0; #X connect 4 0 10 1; #X connect 5 0 10 2; #X connect 6 0 10 3; #X connect 7 0 13 1; #X connect 8 0 13 2; #X connect 9 0 13 3; #X connect 10 0 12 0; #X connect 11 0 27 0; #X connect 12 0 24 0; #X connect 13 0 10 0; #X connect 14 0 26 0; #X connect 15 0 21 1; #X connect 16 0 21 2; #X connect 17 0 21 3; #X connect 18 0 26 1; #X connect 19 0 26 2; #X connect 20 0 26 3; #X connect 21 0 25 0; #X connect 22 0 28 0; #X connect 23 0 22 0; #X connect 25 0 28 0; #X connect 26 0 21 0; #X connect 27 0 24 0;
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
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
I was able to reproduce the issue; however, I don't think this is a bug in GEM. I have pretty much confirmed that each object in GEM has it's own correct values as passed to it from the patch. Like Cyrille, I suspect this is a driver level bug/limit which is where the curve control points are converted to vertices.
If you use draw control_line both objects will function correctly because it uses standard glVertex3() calls like the other GEM objects.
The best solution would be to remake the object using standard immediate mode or better yet vertex arrays.
cgc
On Jul 21, 2005, at 10:17 AM, B. Bogart wrote:
Hi,
For the first few versions I'll create one surface out of multiple curve3d patches. Since this is about the only option I have. I'll be controling the points of the curve3d using the python numarray extension.
Anyone else confirm curve3d weirdness? fixable? (should I post this to the bug tracker?)
B.
cyrille henry wrote:
B. Bogart a écrit :
Hey Cyrille,
The problem I had seemed to be related to the bug with control points not responding. I have come accross this so many times recently in different ways. The bug either represented itself as a lack of control of the point, OR controlling a second curve3d object. Both things always happening when trying to use control points beyond a certain size. I also had some problems with a single curve3d 32x24 not rendering at all! (as if there was no gemhead connected)
I think the size is machine dependant, did you try counting up from 8x8 to 30x24 to see if the patch caused the bug at any point?
i did not try all possibility, but it look like the bug is as soon as a curve3d is created with more than 30 points (X and/or Y).
I downloaded gem0.90 for linux as well and it still does the same thing.
i don't thik there was any change in curve3d object since the 0.90 release, so it's not surprising.
why would 32x24 control points be a problem if #1: less res was used, 32x24 for example, #2 if the points where not moved very often, #3 if we're drawing only the control points and not the curve itself etc.. ?
on my computer it does work with any size if i draw only the control points. So, i think the opengl command : glEvalCoord2f is limited to a sepecific size, depending on the openGL implementation of your hardware (or driver, as this is usualy not hardware accelerated).
Size is limited in the curve3d code to 50x50.
Hopefully someone out there can reproduce this problem. I do think it is the same bug as the control point issue you talk about,
i think so.
cyrille
just another effect of it. seems to be display-list related...
B>
cyrille henry wrote:
hello,
your patch works for me. i've got a problem with more than 30x24 control points : changing control point does have no effect. it's the only problem i've got.
anyway : curve3d is very slow, creating a 32x24 control point will use all CPU of a standart computer.
i've got a standart gem version.
hum, strange. cyrille
B. Bogart a écrit :
Hey all,
In trying to build a 32x24 control point curve3d I realized a nasty bug.
Seems that if you use curve3d with more than 8x8 (linux) and 10x10 (OSX) points you get into some trouble. In some cases it seems that the 8x9 grid on linux will simply never render a curve3d shape. If you have two curve3d's in a patch and one of them is 8x9 or bigger it actually interacts with the other 8x8 curve3d.
The attached patch shows the interaction bug. Changing both to 8x8 fixes the problem. If your on OSX you'll need to change the curve3d size to 10x10 and 10x11 respectively.
Happens on my fresh gem CVS on linux and an older (6 months+) CVS on OSX.
Thanks!
b>
#N canvas 604 283 541 542 10; #N canvas 79 562 455 304 gemwin 0; #X obj 132 182 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 198 112 destroy; #X msg 132 112 create , 1; #X obj 207 134 loadbang; #X msg 207 155 lighting 0; #X connect 2 0 3 0; #X connect 3 0 4 0; #X connect 3 0 7 0; #X connect 3 1 5 0; #X connect 3 1 6 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 connect 8 0 9 0; #X connect 9 0 0 0; #X restore 26 61 pd gemwin; #X msg 26 42 create; #X text 22 21 Create window:; #X obj 27 118 gemhead; #X floatatom 55 161 5 0 0 0 - - -; #X floatatom 90 161 5 0 0 0 - - -; #X floatatom 126 161 5 0 0 0 - - -; #X floatatom 95 119 5 0 0 0 - - -; #X floatatom 143 119 5 0 0 0 - - -; #X floatatom 192 119 5 0 0 0 - - -; #X obj 27 182 rotateXYZ 0 0 0; #X floatatom 113 268 5 0 0 0 - - -; #X obj 28 221 colorRGB 1 0 0; #X obj 27 139 translateXYZ -2.5 0 0; #X obj 247 118 gemhead; #X floatatom 275 161 5 0 0 0 - - -; #X floatatom 310 161 5 0 0 0 - - -; #X floatatom 346 161 5 0 0 0 - - -; #X floatatom 315 119 5 0 0 0 - - -; #X floatatom 363 119 5 0 0 0 - - -; #X floatatom 412 119 5 0 0 0 - - -; #X obj 247 182 rotateXYZ 0 0 0; #X msg 267 291 set 0 0 0 0 $1; #X floatatom 333 268 5 0 0 0 - - -; #X obj 27 344 curve3d 8 8; #X obj 249 221 colorRGB 0 1 0; #X obj 247 139 translateXYZ -2.5 -2 0; #X msg 47 291 set 0 0 0 0 $1; #X obj 247 344 curve3d 8 9; #X obj 338 344 cnv 15 15 15 empty empty empty 20 12 0 14 -260818 -66577 0; #X text 23 407 If you change the second curve3d to 8x8 then it works as expected. Change back to 8x9 and then the two get confused again. Seems this is happening on my OSX machine as well (except only when using a 10x11 or bigger grid) , using a much older CVS version.; #X text 25 365 For OSX: 10 10; #X text 247 366 For OSX: 10 11; #X text 129 42 Curve3d is acting very odd when using lots of control points. My aim is at least a 32x24 curve3d.; #X connect 0 0 1 0; #X connect 1 0 0 0; #X connect 3 0 13 0; #X connect 4 0 10 1; #X connect 5 0 10 2; #X connect 6 0 10 3; #X connect 7 0 13 1; #X connect 8 0 13 2; #X connect 9 0 13 3; #X connect 10 0 12 0; #X connect 11 0 27 0; #X connect 12 0 24 0; #X connect 13 0 10 0; #X connect 14 0 26 0; #X connect 15 0 21 1; #X connect 16 0 21 2; #X connect 17 0 21 3; #X connect 18 0 26 1; #X connect 19 0 26 2; #X connect 20 0 26 3; #X connect 21 0 25 0; #X connect 22 0 28 0; #X connect 23 0 22 0; #X connect 25 0 28 0; #X connect 26 0 21 0; #X connect 27 0 24 0;
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
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
GEM-dev mailing list GEM-dev@iem.at http://lists.puredata.info/listinfo/gem-dev
Thanks Chris for the clarification.
I got tired of creating large sets of "set blah blah" messages to curve3d, especially when I want to change the dimentions of the shape and have the control points evenly spaced.
What I have done is used numarray in pyext to generate the "set" messages automatically from a numarray of points in 3d. I'll be using this approach to get the most control over individual points while not creating too many messages manually.
I wonder if there is some way to connect the vertex arrays to the python numarray module. numarray is fast enough for signals so it should be fast enough for vertex arrays. I suppose the only issue is possibly faster-than-control-message communication between numarray and vertex arrays.
Anyhow thinking out loud.
B>
chris clepper wrote:
I was able to reproduce the issue; however, I don't think this is a bug in GEM. I have pretty much confirmed that each object in GEM has it's own correct values as passed to it from the patch. Like Cyrille, I suspect this is a driver level bug/limit which is where the curve control points are converted to vertices.
If you use draw control_line both objects will function correctly because it uses standard glVertex3() calls like the other GEM objects.
The best solution would be to remake the object using standard immediate mode or better yet vertex arrays.
cgc
On Jul 21, 2005, at 10:17 AM, B. Bogart wrote:
Hi,
For the first few versions I'll create one surface out of multiple curve3d patches. Since this is about the only option I have. I'll be controling the points of the curve3d using the python numarray extension.
Anyone else confirm curve3d weirdness? fixable? (should I post this to the bug tracker?)
B.
cyrille henry wrote:
B. Bogart a écrit :
Hey Cyrille,
The problem I had seemed to be related to the bug with control points not responding. I have come accross this so many times recently in different ways. The bug either represented itself as a lack of control of the point, OR controlling a second curve3d object. Both things always happening when trying to use control points beyond a certain size. I also had some problems with a single curve3d 32x24 not rendering at all! (as if there was no gemhead connected)
I think the size is machine dependant, did you try counting up from 8x8 to 30x24 to see if the patch caused the bug at any point?
i did not try all possibility, but it look like the bug is as soon as a curve3d is created with more than 30 points (X and/or Y).
I downloaded gem0.90 for linux as well and it still does the same thing.
i don't thik there was any change in curve3d object since the 0.90 release, so it's not surprising.
why would 32x24 control points be a problem if #1: less res was used, 32x24 for example, #2 if the points where not moved very often, #3 if we're drawing only the control points and not the curve itself etc.. ?
on my computer it does work with any size if i draw only the control points. So, i think the opengl command : glEvalCoord2f is limited to a sepecific size, depending on the openGL implementation of your hardware (or driver, as this is usualy not hardware accelerated).
Size is limited in the curve3d code to 50x50.
Hopefully someone out there can reproduce this problem. I do think it is the same bug as the control point issue you talk about,
i think so.
cyrille
just another effect of it. seems to be display-list related...
B>
cyrille henry wrote:
hello,
your patch works for me. i've got a problem with more than 30x24 control points : changing control point does have no effect. it's the only problem i've got.
anyway : curve3d is very slow, creating a 32x24 control point will use all CPU of a standart computer.
i've got a standart gem version.
hum, strange. cyrille
B. Bogart a écrit :
Hey all,
In trying to build a 32x24 control point curve3d I realized a nasty bug.
Seems that if you use curve3d with more than 8x8 (linux) and 10x10 (OSX) points you get into some trouble. In some cases it seems that the 8x9 grid on linux will simply never render a curve3d shape. If you have two curve3d's in a patch and one of them is 8x9 or bigger it actually interacts with the other 8x8 curve3d.
The attached patch shows the interaction bug. Changing both to 8x8 fixes the problem. If your on OSX you'll need to change the curve3d size to 10x10 and 10x11 respectively.
Happens on my fresh gem CVS on linux and an older (6 months+) CVS on OSX.
Thanks!
b>
#N canvas 604 283 541 542 10; #N canvas 79 562 455 304 gemwin 0; #X obj 132 182 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 198 112 destroy; #X msg 132 112 create , 1; #X obj 207 134 loadbang; #X msg 207 155 lighting 0; #X connect 2 0 3 0; #X connect 3 0 4 0; #X connect 3 0 7 0; #X connect 3 1 5 0; #X connect 3 1 6 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 connect 8 0 9 0; #X connect 9 0 0 0; #X restore 26 61 pd gemwin; #X msg 26 42 create; #X text 22 21 Create window:; #X obj 27 118 gemhead; #X floatatom 55 161 5 0 0 0 - - -; #X floatatom 90 161 5 0 0 0 - - -; #X floatatom 126 161 5 0 0 0 - - -; #X floatatom 95 119 5 0 0 0 - - -; #X floatatom 143 119 5 0 0 0 - - -; #X floatatom 192 119 5 0 0 0 - - -; #X obj 27 182 rotateXYZ 0 0 0; #X floatatom 113 268 5 0 0 0 - - -; #X obj 28 221 colorRGB 1 0 0; #X obj 27 139 translateXYZ -2.5 0 0; #X obj 247 118 gemhead; #X floatatom 275 161 5 0 0 0 - - -; #X floatatom 310 161 5 0 0 0 - - -; #X floatatom 346 161 5 0 0 0 - - -; #X floatatom 315 119 5 0 0 0 - - -; #X floatatom 363 119 5 0 0 0 - - -; #X floatatom 412 119 5 0 0 0 - - -; #X obj 247 182 rotateXYZ 0 0 0; #X msg 267 291 set 0 0 0 0 $1; #X floatatom 333 268 5 0 0 0 - - -; #X obj 27 344 curve3d 8 8; #X obj 249 221 colorRGB 0 1 0; #X obj 247 139 translateXYZ -2.5 -2 0; #X msg 47 291 set 0 0 0 0 $1; #X obj 247 344 curve3d 8 9; #X obj 338 344 cnv 15 15 15 empty empty empty 20 12 0 14 -260818 -66577 0; #X text 23 407 If you change the second curve3d to 8x8 then it works as expected. Change back to 8x9 and then the two get confused again. Seems this is happening on my OSX machine as well (except only when using a 10x11 or bigger grid) , using a much older CVS version.; #X text 25 365 For OSX: 10 10; #X text 247 366 For OSX: 10 11; #X text 129 42 Curve3d is acting very odd when using lots of control points. My aim is at least a 32x24 curve3d.; #X connect 0 0 1 0; #X connect 1 0 0 0; #X connect 3 0 13 0; #X connect 4 0 10 1; #X connect 5 0 10 2; #X connect 6 0 10 3; #X connect 7 0 13 1; #X connect 8 0 13 2; #X connect 9 0 13 3; #X connect 10 0 12 0; #X connect 11 0 27 0; #X connect 12 0 24 0; #X connect 13 0 10 0; #X connect 14 0 26 0; #X connect 15 0 21 1; #X connect 16 0 21 2; #X connect 17 0 21 3; #X connect 18 0 26 1; #X connect 19 0 26 2; #X connect 20 0 26 3; #X connect 21 0 25 0; #X connect 22 0 28 0; #X connect 23 0 22 0; #X connect 25 0 28 0; #X connect 26 0 21 0; #X connect 27 0 24 0;
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
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
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,
i agree that curve3d does have lot's of problem : -it is slow, -(hardware) limited to few control points -not really easy to use (lot's of set $1 $2 $3 $4 $5 messages). -hard to control : the curve does not go throw the control points. (not easy to close shapes)
i think, the best thing would be to write an other object, using cubic bezier or other kind of curve.
so, does anybody know what kind of curve can be used (fast to compute, easy to use, etc)?
how to move lot's of control point without the "set" messages (using only native pd objects) ?
or maybe, vertex array is a better solution. i don't know yet...
cyrille
B. Bogart a écrit :
Thanks Chris for the clarification.
I got tired of creating large sets of "set blah blah" messages to curve3d, especially when I want to change the dimentions of the shape and have the control points evenly spaced.
What I have done is used numarray in pyext to generate the "set" messages automatically from a numarray of points in 3d. I'll be using this approach to get the most control over individual points while not creating too many messages manually.
I wonder if there is some way to connect the vertex arrays to the python numarray module. numarray is fast enough for signals so it should be fast enough for vertex arrays. I suppose the only issue is possibly faster-than-control-message communication between numarray and vertex arrays.
Anyhow thinking out loud.
B>
chris clepper wrote:
I was able to reproduce the issue; however, I don't think this is a bug in GEM. I have pretty much confirmed that each object in GEM has it's own correct values as passed to it from the patch. Like Cyrille, I suspect this is a driver level bug/limit which is where the curve control points are converted to vertices.
If you use draw control_line both objects will function correctly because it uses standard glVertex3() calls like the other GEM objects.
The best solution would be to remake the object using standard immediate mode or better yet vertex arrays.
cgc
On Jul 21, 2005, at 10:17 AM, B. Bogart wrote:
Hi,
For the first few versions I'll create one surface out of multiple curve3d patches. Since this is about the only option I have. I'll be controling the points of the curve3d using the python numarray extension.
Anyone else confirm curve3d weirdness? fixable? (should I post this to the bug tracker?)
B.
cyrille henry wrote:
B. Bogart a écrit :
Hey Cyrille,
The problem I had seemed to be related to the bug with control points not responding. I have come accross this so many times recently in different ways. The bug either represented itself as a lack of control of the point, OR controlling a second curve3d object. Both things always happening when trying to use control points beyond a certain size. I also had some problems with a single curve3d 32x24 not rendering at all! (as if there was no gemhead connected)
I think the size is machine dependant, did you try counting up from 8x8 to 30x24 to see if the patch caused the bug at any point?
i did not try all possibility, but it look like the bug is as soon as a curve3d is created with more than 30 points (X and/or Y).
I downloaded gem0.90 for linux as well and it still does the same thing.
i don't thik there was any change in curve3d object since the 0.90 release, so it's not surprising.
why would 32x24 control points be a problem if #1: less res was used, 32x24 for example, #2 if the points where not moved very often, #3 if we're drawing only the control points and not the curve itself etc.. ?
on my computer it does work with any size if i draw only the control points. So, i think the opengl command : glEvalCoord2f is limited to a sepecific size, depending on the openGL implementation of your hardware (or driver, as this is usualy not hardware accelerated).
Size is limited in the curve3d code to 50x50.
Hopefully someone out there can reproduce this problem. I do think it is the same bug as the control point issue you talk about,
i think so.
cyrille
just another effect of it. seems to be display-list related...
B>
cyrille henry wrote:
hello,
your patch works for me. i've got a problem with more than 30x24 control points : changing control point does have no effect. it's the only problem i've got.
anyway : curve3d is very slow, creating a 32x24 control point will use all CPU of a standart computer.
i've got a standart gem version.
hum, strange. cyrille
B. Bogart a écrit :
> Hey all, > > In trying to build a 32x24 control point curve3d I realized a nasty > bug. > > Seems that if you use curve3d with more than 8x8 (linux) and 10x10 > (OSX) > points you get into some trouble. In some cases it seems that the > 8x9 > grid on linux will simply never render a curve3d shape. If you > have two > curve3d's in a patch and one of them is 8x9 or bigger it actually > interacts with the other 8x8 curve3d. > > The attached patch shows the interaction bug. Changing both to 8x8 > fixes > the problem. If your on OSX you'll need to change the curve3d > size to > 10x10 and 10x11 respectively. > > Happens on my fresh gem CVS on linux and an older (6 months+) > CVS on > OSX. > > Thanks! > > b> > > > ------------------------------------------------------------------- > ----- > > > #N canvas 604 283 541 542 10; > #N canvas 79 562 455 304 gemwin 0; > #X obj 132 182 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 198 112 destroy; > #X msg 132 112 create , 1; > #X obj 207 134 loadbang; > #X msg 207 155 lighting 0; > #X connect 2 0 3 0; > #X connect 3 0 4 0; > #X connect 3 0 7 0; > #X connect 3 1 5 0; > #X connect 3 1 6 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 connect 8 0 9 0; > #X connect 9 0 0 0; > #X restore 26 61 pd gemwin; > #X msg 26 42 create; > #X text 22 21 Create window:; > #X obj 27 118 gemhead; > #X floatatom 55 161 5 0 0 0 - - -; > #X floatatom 90 161 5 0 0 0 - - -; > #X floatatom 126 161 5 0 0 0 - - -; > #X floatatom 95 119 5 0 0 0 - - -; > #X floatatom 143 119 5 0 0 0 - - -; > #X floatatom 192 119 5 0 0 0 - - -; > #X obj 27 182 rotateXYZ 0 0 0; > #X floatatom 113 268 5 0 0 0 - - -; > #X obj 28 221 colorRGB 1 0 0; > #X obj 27 139 translateXYZ -2.5 0 0; > #X obj 247 118 gemhead; > #X floatatom 275 161 5 0 0 0 - - -; > #X floatatom 310 161 5 0 0 0 - - -; > #X floatatom 346 161 5 0 0 0 - - -; > #X floatatom 315 119 5 0 0 0 - - -; > #X floatatom 363 119 5 0 0 0 - - -; > #X floatatom 412 119 5 0 0 0 - - -; > #X obj 247 182 rotateXYZ 0 0 0; > #X msg 267 291 set 0 0 0 0 $1; > #X floatatom 333 268 5 0 0 0 - - -; > #X obj 27 344 curve3d 8 8; > #X obj 249 221 colorRGB 0 1 0; > #X obj 247 139 translateXYZ -2.5 -2 0; > #X msg 47 291 set 0 0 0 0 $1; > #X obj 247 344 curve3d 8 9; > #X obj 338 344 cnv 15 15 15 empty empty empty 20 12 0 14 -260818 > -66577 > 0; > #X text 23 407 If you change the second curve3d to 8x8 then it > works > as expected. Change back to 8x9 and then the two get confused > again. > Seems this is happening on my OSX machine as well (except only when > using a 10x11 or bigger grid) , using a much older CVS version.; > #X text 25 365 For OSX: 10 10; > #X text 247 366 For OSX: 10 11; > #X text 129 42 Curve3d is acting very odd when using lots of > control > points. My aim is at least a 32x24 curve3d.; > #X connect 0 0 1 0; > #X connect 1 0 0 0; > #X connect 3 0 13 0; > #X connect 4 0 10 1; > #X connect 5 0 10 2; > #X connect 6 0 10 3; > #X connect 7 0 13 1; > #X connect 8 0 13 2; > #X connect 9 0 13 3; > #X connect 10 0 12 0; > #X connect 11 0 27 0; > #X connect 12 0 24 0; > #X connect 13 0 10 0; > #X connect 14 0 26 0; > #X connect 15 0 21 1; > #X connect 16 0 21 2; > #X connect 17 0 21 3; > #X connect 18 0 26 1; > #X connect 19 0 26 2; > #X connect 20 0 26 3; > #X connect 21 0 25 0; > #X connect 22 0 28 0; > #X connect 23 0 22 0; > #X connect 25 0 28 0; > #X connect 26 0 21 0; > #X connect 27 0 24 0; > > > ------------------------------------------------------------------- > ----- > > > _______________________________________________ > 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
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
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
Hey Cyrille++,
For this application I would be happy with a something like a "multipoly" object that allows many many faces to be rendered and seperatly controled. Though nice smooth bezier curves would be very nice.
I think that this is a general problem though, efficiently controlling many many points in PD. I'm not sure what the approaches are. Maybe the fastest would be to have three signal inputs where each signal is a super-efficient stream of X,Y,Z then that would be hard to sync perhaps... Or the possiblilty of some kind of matrix type in PD which is perhaps a multi-dementional signal. (Now this is what numarray does, and the new VASP will pass pointers to these numarrays and be very fast) numarrays are multi-dimentional.
Is one long list of points faster than a bunch of simpler individual messages?
In vertex arrays (Chris, correct me where needed) I think the problem is that the current objects are very easy to control and very fast BUT since the arrays are in C we still have to use PD messages to control them. Looks like the approach in vertex_arrays is to have one message control multiple vertexes. Problem with this is that you loose the individual control (rather if you had a range of vertex 1 to 1 then you would be back to the same problem of many many messages). I posted some ideas about more complex ranges, and the ability to rotate/translate/.. vertexes based on their normal rather than global axes.
I have to say using python numarrays has been very satisfying in terms of how efficient it is to create arrays of messages [set 0 0 -4 -4 0< to [set 100 100 4 4 0< but perhaps this is not really all that much to do with Gem and a general PD soultion to creating such things would be better. I find using "repeat" still awkward myself...
I'm also looking forward to doing things like matrix rotation, convolution etc in numarray...
B>
cyrille henry wrote:
hello,
i agree that curve3d does have lot's of problem : -it is slow, -(hardware) limited to few control points -not really easy to use (lot's of set $1 $2 $3 $4 $5 messages). -hard to control : the curve does not go throw the control points. (not easy to close shapes)
i think, the best thing would be to write an other object, using cubic bezier or other kind of curve.
so, does anybody know what kind of curve can be used (fast to compute, easy to use, etc)?
how to move lot's of control point without the "set" messages (using only native pd objects) ?
or maybe, vertex array is a better solution. i don't know yet...
cyrille
B. Bogart a écrit :
Thanks Chris for the clarification.
I got tired of creating large sets of "set blah blah" messages to curve3d, especially when I want to change the dimentions of the shape and have the control points evenly spaced.
What I have done is used numarray in pyext to generate the "set" messages automatically from a numarray of points in 3d. I'll be using this approach to get the most control over individual points while not creating too many messages manually.
I wonder if there is some way to connect the vertex arrays to the python numarray module. numarray is fast enough for signals so it should be fast enough for vertex arrays. I suppose the only issue is possibly faster-than-control-message communication between numarray and vertex arrays.
Anyhow thinking out loud.
B>
chris clepper wrote:
I was able to reproduce the issue; however, I don't think this is a bug in GEM. I have pretty much confirmed that each object in GEM has it's own correct values as passed to it from the patch. Like Cyrille, I suspect this is a driver level bug/limit which is where the curve control points are converted to vertices.
If you use draw control_line both objects will function correctly because it uses standard glVertex3() calls like the other GEM objects.
The best solution would be to remake the object using standard immediate mode or better yet vertex arrays.
cgc
On Jul 21, 2005, at 10:17 AM, B. Bogart wrote:
Hi,
For the first few versions I'll create one surface out of multiple curve3d patches. Since this is about the only option I have. I'll be controling the points of the curve3d using the python numarray extension.
Anyone else confirm curve3d weirdness? fixable? (should I post this to the bug tracker?)
B.
cyrille henry wrote:
B. Bogart a écrit :
Hey Cyrille,
The problem I had seemed to be related to the bug with control points not responding. I have come accross this so many times recently in different ways. The bug either represented itself as a lack of control of the point, OR controlling a second curve3d object. Both things always happening when trying to use control points beyond a certain size. I also had some problems with a single curve3d 32x24 not rendering at all! (as if there was no gemhead connected)
I think the size is machine dependant, did you try counting up from 8x8 to 30x24 to see if the patch caused the bug at any point?
i did not try all possibility, but it look like the bug is as soon as a curve3d is created with more than 30 points (X and/or Y).
I downloaded gem0.90 for linux as well and it still does the same thing.
i don't thik there was any change in curve3d object since the 0.90 release, so it's not surprising.
why would 32x24 control points be a problem if #1: less res was used, 32x24 for example, #2 if the points where not moved very often, #3 if we're drawing only the control points and not the curve itself etc.. ?
on my computer it does work with any size if i draw only the control points. So, i think the opengl command : glEvalCoord2f is limited to a sepecific size, depending on the openGL implementation of your hardware (or driver, as this is usualy not hardware accelerated).
Size is limited in the curve3d code to 50x50.
Hopefully someone out there can reproduce this problem. I do think it is the same bug as the control point issue you talk about,
i think so.
cyrille
just another effect of it. seems to be display-list related...
B>
cyrille henry wrote:
> hello, > > your patch works for me. > i've got a problem with more than 30x24 control points : changing > control point does have no effect. it's the only problem i've got. > > anyway : curve3d is very slow, creating a 32x24 control point will > use > all CPU of a standart computer. > > i've got a standart gem version. > > hum, strange. > cyrille > > > B. Bogart a écrit : > >> Hey all, >> >> In trying to build a 32x24 control point curve3d I realized a nasty >> bug. >> >> Seems that if you use curve3d with more than 8x8 (linux) and 10x10 >> (OSX) >> points you get into some trouble. In some cases it seems that the >> 8x9 >> grid on linux will simply never render a curve3d shape. If you >> have two >> curve3d's in a patch and one of them is 8x9 or bigger it actually >> interacts with the other 8x8 curve3d. >> >> The attached patch shows the interaction bug. Changing both to 8x8 >> fixes >> the problem. If your on OSX you'll need to change the curve3d >> size to >> 10x10 and 10x11 respectively. >> >> Happens on my fresh gem CVS on linux and an older (6 months+) >> CVS on >> OSX. >> >> Thanks! >> >> b> >> >> >> ------------------------------------------------------------------- >> ----- >> >> >> #N canvas 604 283 541 542 10; >> #N canvas 79 562 455 304 gemwin 0; >> #X obj 132 182 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 198 112 destroy; >> #X msg 132 112 create , 1; >> #X obj 207 134 loadbang; >> #X msg 207 155 lighting 0; >> #X connect 2 0 3 0; >> #X connect 3 0 4 0; >> #X connect 3 0 7 0; >> #X connect 3 1 5 0; >> #X connect 3 1 6 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 connect 8 0 9 0; >> #X connect 9 0 0 0; >> #X restore 26 61 pd gemwin; >> #X msg 26 42 create; >> #X text 22 21 Create window:; >> #X obj 27 118 gemhead; >> #X floatatom 55 161 5 0 0 0 - - -; >> #X floatatom 90 161 5 0 0 0 - - -; >> #X floatatom 126 161 5 0 0 0 - - -; >> #X floatatom 95 119 5 0 0 0 - - -; >> #X floatatom 143 119 5 0 0 0 - - -; >> #X floatatom 192 119 5 0 0 0 - - -; >> #X obj 27 182 rotateXYZ 0 0 0; >> #X floatatom 113 268 5 0 0 0 - - -; >> #X obj 28 221 colorRGB 1 0 0; >> #X obj 27 139 translateXYZ -2.5 0 0; >> #X obj 247 118 gemhead; >> #X floatatom 275 161 5 0 0 0 - - -; >> #X floatatom 310 161 5 0 0 0 - - -; >> #X floatatom 346 161 5 0 0 0 - - -; >> #X floatatom 315 119 5 0 0 0 - - -; >> #X floatatom 363 119 5 0 0 0 - - -; >> #X floatatom 412 119 5 0 0 0 - - -; >> #X obj 247 182 rotateXYZ 0 0 0; >> #X msg 267 291 set 0 0 0 0 $1; >> #X floatatom 333 268 5 0 0 0 - - -; >> #X obj 27 344 curve3d 8 8; >> #X obj 249 221 colorRGB 0 1 0; >> #X obj 247 139 translateXYZ -2.5 -2 0; >> #X msg 47 291 set 0 0 0 0 $1; >> #X obj 247 344 curve3d 8 9; >> #X obj 338 344 cnv 15 15 15 empty empty empty 20 12 0 14 -260818 >> -66577 >> 0; >> #X text 23 407 If you change the second curve3d to 8x8 then it >> works >> as expected. Change back to 8x9 and then the two get confused >> again. >> Seems this is happening on my OSX machine as well (except only when >> using a 10x11 or bigger grid) , using a much older CVS version.; >> #X text 25 365 For OSX: 10 10; >> #X text 247 366 For OSX: 10 11; >> #X text 129 42 Curve3d is acting very odd when using lots of >> control >> points. My aim is at least a 32x24 curve3d.; >> #X connect 0 0 1 0; >> #X connect 1 0 0 0; >> #X connect 3 0 13 0; >> #X connect 4 0 10 1; >> #X connect 5 0 10 2; >> #X connect 6 0 10 3; >> #X connect 7 0 13 1; >> #X connect 8 0 13 2; >> #X connect 9 0 13 3; >> #X connect 10 0 12 0; >> #X connect 11 0 27 0; >> #X connect 12 0 24 0; >> #X connect 13 0 10 0; >> #X connect 14 0 26 0; >> #X connect 15 0 21 1; >> #X connect 16 0 21 2; >> #X connect 17 0 21 3; >> #X connect 18 0 26 1; >> #X connect 19 0 26 2; >> #X connect 20 0 26 3; >> #X connect 21 0 25 0; >> #X connect 22 0 28 0; >> #X connect 23 0 22 0; >> #X connect 25 0 28 0; >> #X connect 26 0 21 0; >> #X connect 27 0 24 0; >> >> >> ------------------------------------------------------------------- >> ----- >> >> >> _______________________________________________ >> 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 >
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
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
hey ya'll,
On Jul 24, 2005, at 10:10 AM, B. Bogart wrote:
For this application I would be happy with a something like a "multipoly" object that allows many many faces to be rendered and seperatly controled. Though nice smooth bezier curves would be very nice.
I think that this is a general problem though, efficiently controlling many many points in PD. I'm not sure what the approaches are. Maybe the fastest would be to have three signal inputs where each signal is a super-efficient stream of X,Y,Z then that would be hard to sync perhaps... Or the possiblilty of some kind of matrix type in PD which is perhaps a multi-dementional signal. (Now this is what numarray does, and the new VASP will pass pointers to these numarrays and be very fast) numarrays are multi-dimentional.
Is one long list of points faster than a bunch of simpler individual messages?
In vertex arrays (Chris, correct me where needed) I think the problem is that the current objects are very easy to control and very fast BUT since the arrays are in C we still have to use PD messages to control them. Looks like the approach in vertex_arrays is to have one message control multiple vertexes. Problem with this is that you loose the individual control (rather if you had a range of vertex 1 to 1 then you would be back to the same problem of many many messages). I posted some ideas about more complex ranges, and the ability to rotate/ translate/.. vertexes based on their normal rather than global axes.
I have to say using python numarrays has been very satisfying in terms of how efficient it is to create arrays of messages [set 0 0 -4 -4 0< to [set 100 100 4 4 0< but perhaps this is not really all that much to do with Gem and a general PD soultion to creating such things would be better. I find using "repeat" still awkward myself...
I'm also looking forward to doing things like matrix rotation, convolution etc in numarray...
...ok, I'll have to jump in here and say that you are basically "rediscovering" many of inspirations that brought about the whole vertex_array stuff...the good news is that there is already something of a solution to your problem: the vertex_array tag has two interesting objects not well known outside of the IOhannes and myself: vertex_tabread and vertex_tabwrite...
...you can probably guess that this allows reading and writing of pd "tables" or "arrays", and then efficient uploading of the data as vertex arrays or vertex buffer objects with [vertex_draw]...this is all very important to the "shapeSynth" that I've been working on: basically calculating shapes via iemmatrix ops and other goodies...I apologize for not making it more well known: I'll try to get some patches out this week that demonstrate this kind of stuff, but I have some heavy early week deadlines that are looming atm...
more l8r! jamie
Heya,
Rediscoveries always seem that much more magical! ;)
ok tabread and tabwrite have potencial. I've not tried the vertex array stuff in some time. (maybe 6 months+ ?) Anyhow I personally find PD tables pretty anoying, I'm sure they make a lot of sense to audio people but I personally find them an obstical for multi-dimentional data storage. I guess you need three arrays one for each dimention and sync em. This is probably the very best way to deal with the problem in the short term. I'd rather use some multi-dementional storage/access system that is not so laiden with audio ideas. Of course I'm in the vast minority here not even touching audio at all.
I'm very much looking forward to the shape-synth examples!!! :)
<B<
james tittle wrote:
hey ya'll,
...ok, I'll have to jump in here and say that you are basically "rediscovering" many of inspirations that brought about the whole vertex_array stuff...the good news is that there is already something of a solution to your problem: the vertex_array tag has two interesting objects not well known outside of the IOhannes and myself: vertex_tabread and vertex_tabwrite...
...you can probably guess that this allows reading and writing of pd "tables" or "arrays", and then efficient uploading of the data as vertex arrays or vertex buffer objects with [vertex_draw]...this is all very important to the "shapeSynth" that I've been working on: basically calculating shapes via iemmatrix ops and other goodies...I apologize for not making it more well known: I'll try to get some patches out this week that demonstrate this kind of stuff, but I have some heavy early week deadlines that are looming atm...
more l8r! jamie
On Jul 24, 2005, at 9:10 AM, B. Bogart wrote:
In vertex arrays (Chris, correct me where needed) I think the problem is that the current objects are very easy to control and very fast BUT since the arrays are in C we still have to use PD messages to control them. Looks like the approach in vertex_arrays is to have one message control multiple vertexes. Problem with this is that you loose the individual control (rather if you had a range of vertex 1 to 1 then you would be back to the same problem of many many messages). I posted some ideas about more complex ranges, and the ability to rotate/translate/.. vertexes based on their normal rather than global axes.
The vertex_array objects do allow for a single point (vertex, color, texcoord, normal) to be modified as well as a range. It's very easy to do this by offsetting the pointer and counting from there. This does not allow for selecting two non-contiguous ranges or do anything more programmatic like skip every third point. You could use [repeat] to iterate through the same array each render pass but that is probably not very efficient.
Once you start loading models of any complexity into vertex_array chains it becomes apparent that these objects need to be very efficient. A model with 10,000 vertices has a 40k vertex array, a 40k color array, a 30k normal array and a 20k texcoord array. That is 130,000 floats or 520,000 bytes per frame to process. Multiply by 30 or 60 frames per second and that is moving a lot of data.
That example also points out the trouble with giving a user some sort of representation of all of that data. I don't think any of Pd's objects or external libraries are designed to deal with structures of this size.
cgc
Hi Chris,
Good to hear. Is there an example patch that shows how to offset each vertex by 0.1 units out along its normal?
Just as a point of discussion one of the arguments for numarray is that it is more efficient with arrays larger than 20,000 elements. I have a patch that simply subtracts 0.1 units from the Z access of a particular control point. What has amazed me is that I needed no interpolation because the numarray code ran fast enough to create smooth movement.
Indeed these are issues worth discussing. Also between iemmatrix, gridflow and VASP (numarray/python) seems arrays are "IN". ;)
Oh and here is some numarray info:
http://www.stsci.edu/resources/software_hardware/numarray
Thanks for the clarification Chris, I'll have to do update of my vertex stuff.
:)
chris clepper wrote:
The vertex_array objects do allow for a single point (vertex, color, texcoord, normal) to be modified as well as a range. It's very easy to do this by offsetting the pointer and counting from there. This does not allow for selecting two non-contiguous ranges or do anything more programmatic like skip every third point. You could use [repeat] to iterate through the same array each render pass but that is probably not very efficient.
Once you start loading models of any complexity into vertex_array chains it becomes apparent that these objects need to be very efficient. A model with 10,000 vertices has a 40k vertex array, a 40k color array, a 30k normal array and a 20k texcoord array. That is 130,000 floats or 520,000 bytes per frame to process. Multiply by 30 or 60 frames per second and that is moving a lot of data.
That example also points out the trouble with giving a user some sort of representation of all of that data. I don't think any of Pd's objects or external libraries are designed to deal with structures of this size.
cgc
-not really easy to use (lot's of set $1 $2 $3 $4 $5 messages).
how to move lot's of control point without the "set" messages (using only native pd objects) ?
That is the limitation I ran into with the vertex_array objects. The objects are fast and have very few limits but Pd really has no way to deal with the data effectively.
Using messages is not precise enough even though it does fit the more programmatic aspects of control in Pd. Maybe a special GEM data display window with dedicated mouse and keyboard controls could help with the viewing and selecting of data in the arrays?
cgc
On Jul 24, 2005, at 6:15 AM, cyrille henry wrote:
hello,
i agree that curve3d does have lot's of problem : -it is slow, -(hardware) limited to few control points -not really easy to use (lot's of set $1 $2 $3 $4 $5 messages). -hard to control : the curve does not go throw the control points. (not easy to close shapes)
i think, the best thing would be to write an other object, using cubic bezier or other kind of curve.
so, does anybody know what kind of curve can be used (fast to compute, easy to use, etc)?
how to move lot's of control point without the "set" messages (using only native pd objects) ?
or maybe, vertex array is a better solution. i don't know yet...
cyrille
-
B. Bogart -
chris clepper -
cyrille henry -
IOhannes m zmoelnig -
james tittle -
Thoralf Schulze