The last I saw the source for Drag3D, it does ask the camera to interpret
the coordinates, so if that step didn't work correctly for the
OrthogonalLens, that could have an impact. I'm using a standard camera,
currently, which I tween to new positions based on the perspective I need.
The only problems I've experienced with Drag3D is that it doesn't work
correctly when the scene is rotated (I know, I should move the camera, not
rotate the scene) and if you are near the plane you're measuring against,
it reports Infinity instead of -Infinity when you move you mouse out far
enough
On Sun, 12 Sep 2010 14:04:56 -0700, Bob Warfield <[email protected]>
wrote:
On Sun, Sep 12, 2010 at 11:07 AM, Joshua Granick
<[email protected]> wrote:
I'm currently using the Drag3D class. It has a getIntersect () method
which
should return the coordinates in most circumstances. I don't think you
need
to be dragging an object for it to work.
Joshua, that Drag3D's pretty good!
But, some funny business of various kinds that I wonder if you have
some thoughts about.
If I just bring my app up and move the mouse around, I am updating
the coordinates on my status bar and it looks great. I have a visible
coordinate grid I can use to calibrate off of for these tests.
The one thing that is very odd is I have to divide the coordinate
values that come back by 8 to get the right answer. That seems weird.
FWIW, I am running the orthogonalLens for my application, rather than
the default. I have noticed a pretty fair number of things in Away3D
are a touch wonky with that lens and I wonder if that is the source of
the 8 or my other problems?
But things go much more awry if my camera changes position. It's as
if the coordinates do not reflect the camera moving, which they
should.
For example, my application has "Top", "Right", "Front" and
"Perspective" views that I can toggle. In fact, the display is sort
of a replica of Rhino3D, but looking at one view at a time instead of
all 4. In all the views except "Perspective", I pan the image when
you hold the right mouse button down. This is implemented by running
the camera along as though it were on tracks that stay a fixed
distance above the objects being viewed.
So, for example, a mouse move in X with the right button down will do
this in the "Top" view:
camX = setCamCoord(
camX+moveX );
camLookX += moveX;
This just moves the camera's location and where it is looking by an
amount proportional to how much the mouse moved in X--"moveX". Feels
good, works great. But after I make a move like that, the coordinates
coming back are now off by approximately however much I moved. If the
camera moved, why doesn't Drag3D get updated too?
FWIW, I tried switch to the other camera types. First thing, is I no
longer have to use that correction factor of 8. Second thing is the
panning now works properly. So something is wonky with the
OrthogonalLens. Sounds like a bug to me. I'd like to be able to use
it, because the perspective effect of the other lenses is a bit much
for me on this app.
Any thoughts on this would be much appreciated.
Also, I'm going to want a call that does the getIntersect() while
letting me pass in x, y (pity this one doesn't have default values for
the parameters of the mouse's position), but I
have already hacked my copy of Drag3D to work using the default
parameter style. Seems like others might like that change too,
Fabrice.
Thanks in advance for helping!
Cheers,
BW
