Space Mouse auto-pivot problems

[zachary_ts3d]

Hi,
I'm using the 3dware web SDK and I'm having issues with the auto pivot features. It's my understanding that when auto-pivot is enabled there should be calls to setLookFrom, setLookDirection etc. followed by a call to getLookAt which should return a point, which will then be used as the pivot for the duration of the interaction.

In perspective projection there are calls made to the getLookAt callback I provide but the point I provide doesn't seem to be used when orbiting, unless I manually set it as the pivot using update3dController.

In orthographic projection there's never any calls to getLookAt, nor to setLookFrom etc. Even in the demo provided with the web SDK if I switch the projection to orthographic I see occasional calls to getLookAt, but it seems like it only happens when the camera is sufficiently close to the pyramid model, and it doesn't seem to be used as the pivot point.

I'm wondering what the intended behavior is and what the conditions are for the calls to getLookAt. Perhaps the 3d mouse server has incorrect information about the camera position and bounding? I'm not having problems with other functionality, such as pivoting about the model center, switching the view to the top/left/front/etc., so I'm wondering what the problem could be. I can provide code upon request.

[ngomes]

The "Auto" algorithm is fairly complex and depends on multiple variables. For example, it will check if the value returned by getLookAt is within the view frustum (perspective views). If the returned value (a point) is outside of the view frustum then, by definition, the point is not visible and it is discarded.

The getLookAt should simply return the closest point to the camera that is within the "cone" (perspective projection) or "box" (orthogonal projection) defined by setLookFrom, setLookDirection and the other "hit testing" methods.

The algorithm also kicks in only when the model is up close to the camera. If the model is in full view (as defined by the model extents "bounding box"), the algorithm simply uses the centre of the model extents.

[zachary_ts3d]

So perhaps I'm providing the frustrum / view extents incorrectly. I'll experiment a bit to see what could be going wrong.

[zachary_ts3d]

Okay, so I've made some progress. It turns out that if you specify a pivot point manually using update3dcontroller 3dxware will never try to update it, no matter what the hit test says.
Now I'm facing a different problem, Pivoting and movement work great when the hit test succeeds, it'll orbit about the point that was hit, and it works when auto-pivot is off, it orbits around the center of the model bounding. But when auto-pivot is on and the hit test returns null I get a command to set the pivot point to a garbage point:

Code: Select all

8.48798316396e-313,6.784834404724364e+266,5.832897643306141e-303

... Somewhere way off in the distance. After this if I use the space mouse it tries to orbit about this and setViewMatrix spits out a bunch of NaNs and Infs.
Any ideas as to why it may be trying to set this bad pivot?

[ngomes]

Any ideas as to why it may be trying to set this bad pivot?

It seems that when hit testing fails to pick a valid point, you may be returning a success code leaving a variable uninitialised.

[zachary_ts3d]

This is the WebSDK so all communication with the Navlib is done via JSON, I don't know that it's possible that there's an uninitialized memory bug on my side. I'm returning null correctly if the hit test fails but then the navlib sets this garbage point. I'm returning my model extents correctly, and the navlib correctly orbits the bounding center in other cases where the hit test is not used. It also works correctly if a hit test was preformed and after movement the model is outside of the view frustrum, it returns the pivot point to the bounding center. This is only when the hit test fails and the model is still within the view frustrum. I'm not sure where this could come from

[ngomes]

I don't know that it's possible that there's an uninitialized memory bug on my side.

Right. Not necessarily on your side.

We have the Navigation Library log you sent to API Support. One of us will be going through it tomorrow (Wednesday). You should expect an answer on that same day.

[ngomes]

We see that you are using v. 10.9.1 of 3DxWare 10. You may want to upgrade to v. 10.9.2, released yesterday.

The latest version is available to download here.