[GEM-dev] curve3d acts very very odd with lots of control points OSX+Linux)

Thu Jul 21 17:17:16 CEST 2005

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
>
-------------- 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/20050721/ae19e979/attachment.pgp>