{Spam?} Re: [GEM-dev] curve3d acts very very odd with lots of control points OSX+Linux)
B. Bogart
ben at ekran.org
Sat Jul 23 23:33:49 CEST 2005
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/20050723/31665968/attachment.pgp>
More information about the GEM-dev
mailing list