RobPerkins wrote at 2012-11-08 17:28:
I'm trying to think of a way to add something like a BillboardVisual3D such that its position stays fixed relative to the camera. Ultimately it would have an ArrowVisual3D reaching from the Billboard into the model space itself, pointing at a feature.
This would mean that as the camera is rotated, panned, zoomed, etc, the control would stay "stuck" to the front of the frustum, as it were.
If I understand things correctly the camera in Helix3D is the thing doing the moving during panning, rotating, and zooming; no transformations are computed on the model itself.
How would you approach this?
objo wrote at 2012-11-12 22:15:
Yes, in this library the camera properties are modified, not the world or camera transforms.
You need to update the 3D positions of your visuals each time the camera move. I think you could create a plane at the camera 'target' position, with the camera direction as the normal vector. Then use Viewport3DHelper.GetRay and Ray3D.PlaneIntersection to calculate the 3D positions.
RobPerkins wrote at 2012-11-12 23:05:
Good; that signifies an approach I could take. What if instead of doing that, we simply position the control in the visual tree as a 2D ContentControl atop the viewport, and then extend an ArrowVisual3D from the frustum front to a world coordinate? Would the same ViewPort3DHelper and Ray3D methods be useful, or is there something simpler?
(Yes, I can figure this out on my own, but I thought the discussion here would be beneficial to others.)
objo wrote at 2012-11-13 06:05:
Yes, that should also work - I have tested 2D overlays in the ExampleBrowser/OverlayDemo. The "target" adorner and "zoom by rectangle" features in HelixViewport3D are also 2D overlays.
Customer support service by UserEcho