X File bulk display

NikolaiF — Mon, 21 Sep 2009 00:42:00 GMT

I was asked the other day about how to load multiple x file -based models into VE3D without having to place each one manually. I've written up a sample here. The idea is more or less a fusion of the existing ActorDataSource and XFile samples, using the actor from the XFile sample rather than the bunnies. I've also mocked up a very simple data file that contains placement information, rather than generating data on the fly as for the bunnies.

The way I've done this, the parsing code for the x files is done in the actor. In this way, swapping out file formats should be straightforward so long as you have parsing code for it (sorry, only x files are directly implemented in the engine, but the results of any parse should still be easily convertible into VE3D graphics objects).

For the sake of simplicitly I did do one thing wrong. The flow of the code is like this: multiple background threads all execute QueryPrimitivesInternal at the same time, and when they are finished, they move through a lock into ActorBuilder. They are still on background threads, but they now execute serially. So, really the data retrieval (in this case, loading from resources, but probably a network request) and the parsing, as appropriate, should happen in QueryPrimitivesInternal, and the action in ActorBuilder should be kept to a minimum. I violated this rule in the sample code for the sake of illustration, but you should be aware of it.

Finally, an important consideration is level of detail. Dense and numerous models can slow down loading and rendering. DataSources take advantage of the ActorBounds and scale concepts, such that it is possible to use simplified models at certain LODs, and switch to more detailed as the user zooms in. If your needs are less extreme, then you can simply use scale to cause models to stop rendering when not in view, and at a certain distance, which is what I have done in the sample.

Have fun!

Loading a model into VE3D

NikolaiF — Tue, 27 May 2008 22:54:00 GMT

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.

Get Sample Code

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.

Virtual Earth 3D team blog : X File

X File bulk display

Loading a model into VE3D