Loading a model into VE3D
Note: this entry references code for an older version of VE3D. The newest code samples are here.
Commonly the models seen in any 3D product are created using specialized software packages, exported to a file, and then loaded into the end product. Unfortunately this version of Virtual Earth 3D does not yet have full support for this process, but by being a little more adventurous (than you already are), you can do it.
Although in theory the mechanisms in place in VE3D for specifying vertex buffers, index buffers, materials, etc, could be used to import most file formats by writing the converter yourself, most people don’t want to do that, especially given how complex the formats can be. Until such mechanisms are solidly in place, we will use DirectX’s ability to read X files, as exposed by one of our internal classes. We’ll convert that using relatively simple code into a MeshGraphicsObject (the same as used in SimpleObjectPlacement), wrap it in an Actor, and add it to our world.
The code shows how to do simple intersection tests against the mesh and animate it. We also demonstrate one way to do labeling of objects.
Will it break?
There’s an important point to be made here: the whole API here is officially “unsupported”, which mostly means that we are happy to help you here on the blog, but we don’t, for example, have official documentation on MSDN. One reason we’re not calling it official is that we’re still working on refining the code, and we do expect to make changes. We’d prefer not to break anyone, but if we need to change things in order to make it easier to not break you later – once that word changes to “supported” -- we’ll do it.
Only part of the code is going to be supported even after we flip that switch, specifically the assemblies that have been referenced in the samples we’ve released so far. In this sample, we reference Graphics3D, which is considered an internal assembly. You can still reference things there, and they’ll work, but they’ll be harder to use, the documentation will be thinner, and the chances of breaking changes happening across versions will be higher.
In short, everything now is “use at your own risk”, but some things are riskier than others, and this sample is in that category. When we do break things we will release information on this blog about how to fix them, and update our samples as well.
Comments
Anonymous
June 04, 2008
MSBuild DevSource Article: Automation with MSBuild [Via: Steve ] WPF The Missing .NET #4: Cue Banner...Anonymous
March 25, 2009
Are there any examples of how to 'drag and drop' actors? Thanks...Anonymous
March 25, 2009
In the BezierSurface sample you can drag and drop the control points. The outline of how to do it is like this: 1 Determine that your mouse is over the actor (for example, in a mouse move). 2 On a click event in this case, switch to a new set of bindings that is designed for dragging. 3 In the mouse movement handler, set the position of the actor. 4 On mouse up, switch back to the default bindings. 3 can be a little tricky because you need to determine how exactly to translate the 2D mouse movement to a 3D movement. The 3 options I normally consider are: maintain the object's distance to the camera (ControlPoint does this), translate the object along a plane perpendicular to the camera lookat at the object's distance from the camera (helper class: Plane3D), and along the earth surface. Also, there is a concept in Bindings called "Spatial", which is designed to help with 1 and 2. I hope to expand sample coverage more fully to Bindings soon, but for now the code in BezierSurface should get you started.