I'm running Processing 1.0 in Leopard (10.5.5) on a Macbook Pro.

Aiming a camera seems to distort the model functions severely. Below is the example code
from modelX() on the website with an added camera that tries to continually "look" at the
floating cubes:


// Adapted from http://dev.processing.org/bugs/show_bug.cgi?id=486
void setup() {
size(500, 500, P3D);
noFill();
}

void draw() {
background(0);

pushMatrix();
// start at the middle of the screen
translate(width/2, height/2);
// some random rotation to make things interesting
rotateY(1.0); //yrot);
rotateZ(2.0); //zrot);
// rotate in X a little more each frame
rotateX(frameCount / 100.0);
// offset from center
translate(0, 150, 0);

// draw a white box outline at (0, 0, 0)
stroke(255);
box(50);

// the box was drawn at (0, 0, 0), store that location
float x = modelX(0, 0, 0);
float y = modelY(0, 0, 0);
float z = modelZ(0, 0, 0);
// clear out all the transformations
popMatrix();

// draw another box at the same (x, y, z) coordinate as the other
pushMatrix();
translate(x, y, z);
stroke(255, 0, 0);
box(50);
popMatrix();


//Try to aim a camera at that point and everything explodes
camera(width/2, height/2, height/2, x, y, z, 0, 1, 0);
}

no, the example just needs to be fixed--the camera is far too close to the
object.

Thanks for the quick reply, but I'm not sure I follow. Even pulling the camera way out shows
that the boxes aren't superimposed as they should be:

camera(width/2, height/2, 2500, x, y, z, 0, 1, 0);

Is it possibly a mac thing? I'll attach a screenshot.

No, the blowing up is partly that clipping planes don't work perfectly in
P3D (see the differences when you switch to OPENGL).

See Help > Environment for more about the coordinate system.

I'm actually using OPENGL for the main sketch that I'm working on and I'm afraid even
changing the example to OPENGL shows that the boxes are not superimposed.

Maybe I'm not understanding something? The base example shows two superimposed boxes
flying around thanks to the miracle of modelX/Y/Z. My expectation was that I should be able
to point a camera at their location and still see two superimposed boxes, but that is not the
case. Changing the eye of the camera to follow the target makes things even more insane:

camera(x, y, z - 2500, x, y, z, 0, 1, 0);

Does that make sense, it seems weird to me that changing the camera around would effect
modelX/Y/Z's ability to superimpose as shown in the base example. It seems to be affecting
the values these functions return.

OK, I modified the initial translation to:

// start at the middle of the screen
translate(width/2, height/2, -200);

edit]
Another screenshot of broken cubes.

This change:

translate(width/2, height/2, -200);

Admittedly makes things less jumpy, but the cubes are still not superimposed in
the same way they are if no camera call is made. I'll work out another sketch
to illustrate this.

I think maybe I'm explaining myself poorly. My point in all of this is that aiming a camera
messes up subsequent calls to modelX/Y/Z. Here's another sketch with no movement at all.

You can see that there is a single, simple translation and the modelX/Y/Z values are saved to
move a second cube to that spot. This works fine on the first loop. However, with each
subsequent loop, the values returned by modelX/Y/Z become erratic and the culprit seems to
be the camera I am aiming.

Incidentally, things work fine if the translation is half of the width and height (160, 120), but
that's not the point I'm making. Camera() is somehow affecting the coordinate space in a
way I find confusing and the result is that modelX/Y/Z is unreliable.

Am I just missing something? Is this by design?


import processing.opengl.*;

void setup() {
size(320,240,OPENGL);
noFill();
}

void draw() {
float eyeX, eyeY, eyeZ;

pushMatrix();
translate(160, 160);
box(50,10,10);

eyeX = modelX(0,0,0);
eyeY = modelY(0,0,0);
eyeZ = modelZ(0,0,0);

//Correctly prints 160.0,160.0,0.0 the first time
//Subsequent loops print weird stuff like 160.0,115.894684,31.789322
println(eyeX + "," + eyeY + "," + eyeZ);

popMatrix();

pushMatrix();
translate(eyeX, eyeY, eyeZ);
box(10,50,10);
popMatrix();

//Nothing fancy here, I'm just trying to point the camera at the cubes
//It doesn't make sense to me that pointing the camera would ruin modelX/Y/Z
camera(width/2, height/2, height/2, eyeX, eyeY, eyeZ, 0, 1, 0);
}

Ben and Casey,

I confirm this broken behavior. I'm procedurally drawing an object whose
dimensions and bounding cube I can't know until it's finished, and
attempting to use modelX etc. to compute the centroid. Moving the camera
changes the values returned by model[X|Y|Z] erratically, even though the
object itself is drawn the same way in the same place each time.

I note that the status is FIXED, but I don't see in what version. I'm using
1.0.1. How can I get and test the fix?

Demo of problem:

http://mrfeinberg.com/hilbert/

The original bug report was incorrect, which is why this was closed. The
problem was the example itself because the camera dimensions were wrong.

In your code, aren't you setting the camera after you've finished drawing?
That's likely to cause erratic behavior.

But if you think it's a bug, please file a new entry with the description
so we can try to track it down. (And/or be my guest at looking into it!)

> In your code, aren't you setting the camera after you've finished drawing?
> That's likely to cause erratic behavior.

In my mental model, there's a "world space", in which one places vertices.
Then when rendering, one applies some transforms that we call "the camera"
when rasterizing. In my (obviously wrong) model, "modelX" is independent of
whatever "camera" transforms are currently in effect; there's a separate
reality to model space, and moving the camera shouldn't change what's
returned by modelX().

This is the exact thinking that caused me to file this bug in the first place and in my mind it's
still broken, but I've obviously done a poor job of articulating it. I don't understand why where
I'm looking from (camera position) should have any effect on modelx/y/z. If I put one box
inside another, it should always be there no matter where I'm standing when I look at it.

k, sounds like something is still off and i'll need to take a closer look.
i'll be doing some hacking on the graphics side later this week so i'll try
and sneak this in along with that. it sounds like at the minimum, we're not
explaining properly how a camera works, but i wouldn't be surprised if
there's something broken in there as well.

in the meantime, the primary matrix that you're working with is both the
model and the view (camera). so the modelX/Y/Z functions should be removing
the view (camera) portion, so that values that come back allow you to
realign objects back in space next to things that are already rendered. but
from jdf's description it sounds like that's still not quite working.

Hello there, I also found the modelX,modelY.. as broken, if it can help,
sending definite bug example of its behavior, example is running processing
1.0.1, so sorry if it has been fixed yet.

there is a code:
[code]
...
pushMatrix();

translate(x,y);
for(int i = 0;i<loms.length;i++){

xes[i]=modelX(0,0,0);
if(keyPressed) //just by reading modelY.. value of modeX is affected !!!
yes[i]=modelY(0,0,0);

translate(0,-step);

ry+=step;

rotate(radians(loms[i]));
line(0,0,0,-step);
}
popMatrix();


stroke(200,0,0);
for(int i =0;i<xes.length;i++)
point(xes[i],height-i);

...
[/code]

(In reply to comment #13)
>
>
>
> Additional Comment #13 From
> fry
> 2009-03-03 06:45
>
> <!--
> addReplyLink(13); //-->[reply]
>
>
>
>
> k, sounds like something is still off and i'll need to take a
closer look.
> i'll be doing some hacking on the graphics side later this week so i'll try
> and sneak this in along with that. it sounds like at the minimum, we're not
> explaining properly how a camera works, but i wouldn't be surprised if
> there's something broken in there as well.
>
> in the meantime, the primary matrix that you're working with is both the
> model and the view (camera). so the modelX/Y/Z functions should be removing
> the view (camera) portion, so that values that come back allow you to
> realign objects back in space next to things that are already rendered. but
> from jdf's description it sounds like that's still not quite working.
>
>

edit]
correct behaviour if only modelX is called

edit]
this happens when just modelY is called from whitin push/popMatrix

Huge apologize for messing with your bug database, please ignore my
comments here, it is complete piece of crap. Kof

*** Bug 1296 has been marked as a duplicate of this bug. ***

Was just wondering if there's been any progress made on this problem? It isn't mentioned in any
v1.0.x Release Notes, and I was wondering if it had dropped off the radar. I really, really want
to use some of the 1.0 features (and be able to give out my sketch to people without asking
them to do their own build of a legacy version), but my app is unusable because of this huge
bug.

No, I've not personally had time to fix it, and nobody else has given it a
shot.

(In reply to comment #20)

I think this problem is more general. The following sketch uses no camera, but produces
incomprehensible results. It is trying to rotate one end or a line around the other, rotating
around the z-axis.

float spx,spy,spz, fpx,fpy,fpz; // view vector coords
float[][] m = new float[4][4];
float a;

void setup(){
size(600,400,P3D);
noLoop();
spx = 0.; spy = 0.; spz = 0.; // values to edit & test with
fpx = 100.; fpy = 0.; fpz = 0.;
a = PI/4.;

// DIY version of Z-rotation

for(int i=0;i<4;i++ ){ // zero it
for(int j=0;j<4;j++ ){
m[i][j]=0.0;
}
}
for(int i=0;i<4;i++ ){m[i][i]=1.0;} // identity
m[0][0]= cos(a); // rotation about z
m[0][1]=-sin(a);
m[1][0]= sin(a);
m[1][1]= cos(a);

println("DIY matrix");
for(int i=0;i<4;i++)
println(m[i][0]+" "+m[i][1]+" "+m[i][2]+" "+m[i][3] ); // print it
println();
}

void draw(){
resetMatrix();
rotateZ( a );
println("Processing's 'printMatrix()'");
printMatrix();

println("Note! Same values as DIY matrix");

fpx = 100.;
fpy = 0.;
fpz = 0.;

float tx,ty,tz;
tx = modelX((fpx-spx),(fpy-spy), (fpz-spz) );
ty = modelY((fpx-spx),(fpy-spy), (fpz-spz) );
tz = modelZ((fpx-spx),(fpy-spy), (fpz-spz) );

println(" FP becomes "+tx+", "+ty+", "+tz );

fpx = 100.;
fpy = 0.;
fpz = 0.;

float cx = m[0][0]*(fpx-spx)+m[0][1]*(fpy-spy)+m[0][2]*(fpz-spz)+m[0][3]*1.0;
float cy = m[1][0]*(fpx-spx)+m[1][1]*(fpy-spy)+m[1][2]*(fpz-spz)+m[1][3]*1.0;
float cz = m[2][0]*(fpx-spx)+m[2][1]*(fpy-spy)+m[2][2]*(fpz-spz)+m[2][3]*1.0;

println(" FP should be "+cx+", "+cy+", "+cz );
}