Hi

I'm thrilled to see the import level FBX feature is coming up. I have been doing something similar using a tool written by Ventilator than cracked open a multi-object OBJ file, converted each object to MDL, then made one big WMB that reproduces the level.

One feature that I really like is the ability to imbed properties like behaviors, skills and flags into the object names in my modelling tool. So, for example, I have a cactus model in my 3D editor, and it follows the folllowing naming scheme:

objectname__behavior__scale__rotate__skill1__skill2__skill3__skill4__skill5__skill6__skill7__skill8

So it's named this: cactus0__cactusSway__0__0__25

When exported, it creates an mdl from the scene with name cactus0, gives it the behavior cactusSway, and makes skill1 = 25.

We also have a substitute model here command

subst__playerModel_mdl__playerAction__scale__rotate__skill1 etc

This substitutes a dummy object with playermodel.mdl into the level, gives it the action playerAction, etc. The advantage of all this is that I never ever have to use WED. The tool goes so far as to running the map compiler, and all I have to do to run the level is execute a simple command line from Maya or XSI to run it in the engine.

I highly recommend a similar naming system which allows the user to insert behaviors and skills, so that he or she doesn't have to open up WED each time to re-insert these values whenever he or she changes the level design. I highly, highly recommend this.

Otherwise, I'll personally probably stick to my old way with vent's script, since I am constantly changing and rebuilding my levels in my 3D app, so much as 10-30 times a day.

i think the fbx format also supports custom attributes which you can assign to objects in most 3d applications.

using such custom attributes probably would be the nicer solution than encoding data in the name.

it would be great if the whole process could be automated. it shouldn't be necessary to manually select if an object is supposed to be a static mesh or an entity. the importer should be able to figure that out from certain attributes.

it also is very important that the importer (and the light mapper) handles smoothing information correctly!

While the ability to set skills and the such right in your program(3ds Max) would be nice, it wouldn't quite be as necessary as we once had to do. I use max2gs, and I'm assuming your OBJ importer also re-wrote the wmp scene every time you exported, thus erasing all the skill/action information, and then re-applying it.

I'm quite sure the importer Conitec made doesn't rewrite anything when you import. So you should only have to import your model once for positional placement, apply it's action and skills in WED, and then if just re-export the model itself if you need changes. Your paths will also stay in WED, which is quite important to some. This means you shouldn't have to put in the actions and skills more than once.

But if the FBX file has these attributes, it really would be a great time saver! I also think the less usage of WED, the better by far, if you've the right tools to make your scenes(lightwave, max, maya).

Quote:

---

it would be great if the whole process could be automated. it shouldn't be necessary to manually select if an object is supposed to be a static mesh or an entity. the importer should be able to figure that out from certain attributes.

---

I don't think this importer creates the mdl's from the fbx data, but rather it expects them to be in a folder. If this is true, then you should be able to just put the path of the folder, and the importer will automatically compare names from that folder with objects in your fbx scene and place them accordingly. Though, I still hope theres a way to do it manual as well.

the beta text says that for every object you can choose if it should get imported as static mesh or if a mdl7 file should get written.

how updating should best get handled is a good question too. i guess we should wait for the first version and give feedback then.

another thing is instanced objects...

If it checks for the models in the folder(it does not create mdls), then instancing is easy as it'd just place a model for every object of the same name in the scene. If it can make .mdl models as well(which would be awesome), then it might be more tricky, as it'd have to take only one object of the same name, export it's model, then place that model for all the rest of the objects in the fbx scene with same name. Either way, any objects in the fbx scene with the same name should be instanced. But yeah, would have to try it out before too much discussion.

Have a look at this. (in case not seen)

I get the idea that this will be ok if it works good, but all is heading towards XML XAML etc.

http://www.erain.com/products/zam3d/DefaultPDC.asp

export 3d objects to file format XAML ?

This would probably be easy to implement in A7 as they
are going this way already.

A naming system for skills and behavior won't be necessary. But names will be used for import options that can't be handled automatically, such as differentiating between level geometry, models and instances, and for assigning a model in the FBX file to a certain already imported entity in the level.