Yep, already got past the scene rotation issue.  It's pretty easy to
move the camera.  I convert to polar coordinates and then back to get
it to act like it is stuck to the outside of a sphere.

I'll bet you are on to something here with the camera.  For the time
being, I am just using the more common camera and it's working very
nicely.  I would like to get back to Orthogonal at some point, so
hopefully someone will look into it.

Cheers,

BW

On Sun, Sep 12, 2010 at 6:38 PM, Joshua Granick
<[email protected]> wrote:
> 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
>

Reply via email to