0

Transforming a ModelVisual3D vs transforming a GeometryModel3D

Anonymous 10 years ago updated by ไอยดา สุรีวงค์ 3 years ago 1
This discussion was imported from CodePlex

Vicente wrote at 2010-08-03 20:00:

I'm working currently on a 3D project and I'm using Helix for the cameras and the viewport (great work :)). I have noticed a strange behavior that I don't understand much regarding the camera, the movement of the camera and the ZoomToFit method.

For the first part of the project I was working with GeometryModel3D objects, creating the geometry by hand (positions, triangle indices,...) and assigning them their transforms. Everything worked right. Now I have refactored the code base and I have started using ModelVisual3D and I assign the transform there instead of transforming the GeometryModel3D. Now the ZoomToFit doesn't catch the object, the camera moves strangely and when that transform is big enough, everything starts doing pretty weird things.

I have looked at Helix samples and the behavior is similar to the one in the Simple Demo, in the Transformed Model tab. So I suppose that is by design, but I don't really understand the difference or what's happening behind the scenes :)

Could you give me an explanation of why are both things giving so different results? Regards!

Vicente


objo wrote at 2010-08-04 09:02:

hi Vicente! It is good to hear you find the toolkit useful! I just added support for transforms in the ZoomToFit method, and an example in the SimpleDemo. Make sure that your viewport control is loaded before calling the ZoomToFit method. It seems to behave correct now :) Also note that you can use mouse double right click to set the camera LookAt point.


objo wrote at 2010-08-05 00:54:

I corrected a bug in the transform calculation. It should work now, also for combinations of transformations :)


Vicente wrote at 2010-08-06 18:52:

Hi objo!

thanks a lot for the changes :) I have been playing more with the transformations and I have hit another weird thing. It seems the camera translation (middle mouse button) depends on the translation of the object, rotation and zoom. For example, if you have a translation in the object of (200, 150, 100), sometimes moving the mouse to the left will move the object to the left, but depending on the zoom, in some other cases it will move the object to the right, as if the axis got inverted. It's easy to see in the Zoom to Fit tab in the Simple Demo. Also, if the translations are bigger, the camera starts behaving very strangely, and double clicking with the middle mouse button doesn't seem to work correctly.

It looks like a bug to me, but not sure, if you need more information on how to reproduce it let me know. Regards!

Vicente


Vicente wrote at 2010-08-07 03:18:

By the way, I have found also another strange camera behavior. If you try using ZoomToFit with an empty scene, the camera will get "not a number" values in the Position property, and from there it will go crazy, it will never work again. If you try ZoomToFit again after that, it will crash in CameraHelper.cs line 115. If you have an scene with something, then empty it and you try ZoomToFit you get the exception in the same place but related to the newPosition value.

Hope it helps :) Regards!

Vicente


objo wrote at 2010-08-12 09:56:

I corrected the bug when using ZoomToFit on an empty scene. If the bounding box is empty, it will do nothing. I will have a look at the strange camera panning behaviour later (the panning should only depend on the camera position/direction - it uses the Unproject method).

Vicente wrote at 2010-08-13 14:30:

Great news :)

ReedCopsey wrote at 2010-10-21 03:19:

objo,

 

Any progress on the strange camera behavior with panning?  This has been causing us grief lately.

 

Thanks,

Reed

 


objo wrote at 2010-10-21 06:58:

hi Reed,

no, I have not had any progress on that problem. It could be a problem in the Ray3D.PlaneIntersection algorithm... I'll add this to the issue tracker.

I just corrected a similar problem with the zoom - when scrolling very fast you might end up on the 'other side' of the object. The solution there was to clamp the zoom factor.

cheers objo