 |
Author |
Topic: 3d depth sorting (Read 458 times) |
|
mawend
|
3d depth sorting
« on: Jan 29th, 2003, 5:47am » |
|
Seems like P5 doesn't have a consistent approach to 3D depth sorting right now. It is easy to draw lines and objects, altering fill and stroke and noStroke statements to get the objects you want, but it seems a bit hit-and-miss to get the proper depth sorting at the same time. For example, check out the little work-in-progress below. When it is running, click the mouse to switch between lighting mode and noLights mode. In non-lighting mode, the center line draws over the boxes, while in lighting mode, everything depth-sorts correctly.
What is the current logic behind the sorting behavior? Is this the desire behavior, or is something else planned?
Also, will there be ways to get to the camera model (transform, lens info, clipping planes, etc...) eventually?
Also, the current 3D camera doesn't handle objects that pass through the near clipping plane very well, and you get a frozen (or slow) display as the object xforms go wacky. Just set numverts to something higher than 300 in the code below to see this happen.
-----
// sqiggle1 - string of boxes on a random walk line
// -- work in progress by Mark Wendell
float stepscale = 15;
boolean lighting = false;
int numverts = 3 * 300;
float[] verts = new float[numverts];
void setup()
{
size (500,500);
background(100);
//stroke(250);
noStroke();
if (lighting) {
lights();
} else {
noLights();
}
fill(10,50,100);
// preload verts[] with random-walk positions
for (int i=1; i<numverts; i++) {
if (i<4) {
verts[i] = 0;
} else {
float step = random(-stepscale,stepscale);
if (step < 0) {
step = min(step,-stepscale/2.8 ;
}
if (step>0) { step = max(step,stepscale/2.8; }
verts[i] = verts[i-3] + step;
}
}
}
void loop() {
stroke (255,200,50);
translate(width/2,height/2);
rotateX(millis() * .0005);
rotateY(millis() * .0003);
push();
beginShape(LINE_STRIP);
for (int i=0; i < numverts; i+=3) {
vertex( verts[i], verts[i+1], verts[i+2] );
}
endShape();
noStroke();
for (int i=0; i < numverts; i+=3) {
push();
fill (i/3 * mouseX/width, 28, 126);
translate(verts[i], verts[i+1], verts[i+2]);
box(stepscale/1.4);
pop();
}
pop();
}
void mousePressed() {
if (lighting) {
noLights();
} else {
lights();
}
lighting = !lighting;
}
|
|
|
|
|
fry
|
Re: 3d depth sorting
« Reply #1 on: Jan 30th, 2003, 3:33am » |
|
there are some bugs in the drawing of stroke() around objects. to keep the rendering engine fast, there are all sorts of special cases for things.. one of them is that when lines are of a single pixel in width, and not lit (noLights()), then it drops to a fast line drawing algorithm, rather than calculating colors and z values for every point.
this is one of several things i need to fix (all at once) when i get a couple days to hack on the graphics engine.. it goes along with antialiased lines, alpha, and some other tidbits like it. hoping that day will be soon.
(i'm gonna move this to the bugs section of the site, hope you don't mind...)
|
|
|
|
|
fry
|
Re: 3d depth sorting
« Reply #2 on: Sep 18th, 2003, 4:25am » |
|
stroke issues fixed for rev 60.
|
|
|
|
|
|
