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

[cyrille henry]

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