Passing multi-dimentional arrays in PD? WAS: Re: {Spam?} Re: [GEM-dev] curve3d acts very very odd with lots of control points OSX+Linux)
B. Bogart
ben at ekran.org
Sun Jul 24 16:10:10 CEST 2005
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 at iem.at
>>>>>>>> http://lists.puredata.info/listinfo/gem-dev
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> GEM-dev mailing list
>>>>>>> GEM-dev at iem.at
>>>>>>> http://lists.puredata.info/listinfo/gem-dev
>>>>>>>
>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>>>> ---
>>>>>>
>>>>>> _______________________________________________
>>>>>> GEM-dev mailing list
>>>>>> GEM-dev at iem.at
>>>>>> http://lists.puredata.info/listinfo/gem-dev
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> GEM-dev mailing list
>>>>> GEM-dev at iem.at
>>>>> http://lists.puredata.info/listinfo/gem-dev
>>>>>
>>>> _______________________________________________
>>>> GEM-dev mailing list
>>>> GEM-dev at iem.at
>>>> http://lists.puredata.info/listinfo/gem-dev
>>>
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> GEM-dev mailing list
>>> GEM-dev at iem.at
>>> http://lists.puredata.info/listinfo/gem-dev
>>>
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 256 bytes
Desc: OpenPGP digital signature
URL: <http://lists.puredata.info/pipermail/gem-dev/attachments/20050724/cde51449/attachment.pgp>
More information about the GEM-dev
mailing list