Bug 695 : potentially insufficient ellipse detail with P3D/OPENGL when scale()'d
Last modified: 2008-09-04 09:56



Assigned To:

Attachment Type Created Size Actions

Description:   Opened: 2007-11-30 10:26
As of Beta 0135, but I think it's been around for a while, can't find anything in the
bugs database though...

The metric used to determine number of segments for ellipse rendering doesn't take
into account scale, so may create very chunky ellipses when low radius is used with
high scale. (P3D/OPENGL only, does not apply to JAVA2D) Is this
intentional/known/by design? The following is a very contrived example, but there
might be legimate reasons to draw small ellipses at large scale ;)

void setup() {
size(200,200,P3D); // or OPENGL

void draw() {

// scale==1, radius==180
ellipse(0,0,180,180); // enough to mimic circle

// scale==180, radius==1
ellipse(0,0,1,1); // clearly a septagon

Or maybe you could add an "ellipseDetail()" to the api -- if never called and left as
default then continue using existing metric, but if user gives a specific decimation
then use that instead? Just a thought.
Additional Comment #1 From fry 2007-11-30 10:29
yeah, the adaptive algorithm that it's using isn't working too well (in
fact it may be commented out by now since it was working so poorly). it's
on the todo list but just hasn't been in the bugs db so far.
Additional Comment #2 From davbol 2007-12-04 13:47
when this comes up for consideration (i know its low priority, even for me! :D)
another issue is with pdf/dxf export where you might like to be able to manually
bump up the resolution even without any scaling in the sketch, but where scaling
might occur after, fe a 10px diameter circle may look ok on screen at 72dpi but if
you then import the pdf elsewhere at higher rez it might not be enough (ie, a 300dpi
import after sketch equiv to 4x scaling during sketch), not sure if the fix for this
might-could address that at the same time? just food for thought.
Additional Comment #3 From fry 2007-12-04 23:14
yes of course, though understand that begin/endRaw() will always have
issues along these lines, as they only handle tesselated geometry such as
lines and triangles. to get full resolution, you have to use
begin/endRecord() (which is not supported by DXF, and not supported by PDF
when recording from 3D).
This bug is now being tracked here.