FAQ
Cover
\
Build
\
Source
\
Bugs
\
Reference
\
Libraries
\
Tools
The bugs database has moved
here
.
Bug 695 : potentially insufficient ellipse detail with P3D/OPENGL when scale()'d
Last modified: 2008-09-04 09:56
P
roject:
processing
trash
Version:
unspecified
Co
m
ponent:
android
book
core
libraries
pde
reference
tools
web
Status:
ASSIGNED
Resolution:
-
Pr
i
ority:
P2
Severity:
normal
Platform
All
O
S:
All
Windows
Mac OS
Linux
Other
Reporter:
davbol
Assigned To:
fry
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
ellipseMode(CENTER);
noFill();
}
void draw() {
background(255);
translate(width/2f,height/2f);
// scale==1, radius==180
stroke(0,255,0);
ellipse(0,0,180,180); // enough to mimic circle
// scale==180, radius==1
stroke(255,0,0);
scale(180);
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
.