Some of this info has already been mentioned above, but I am too lazy to edit, so here are a couple of posts on the topic of mapmaking from an earlier conversation on the Magma forums(Mauglir) and from a Q&A about mapmaking that used to be on the Vista site.
Also, I think I grabbed the most relevant stuff but there might be a useful fact or two in one of these other
articles about Models.
------------- Mauglir said (in the summer of 2006):
I might be able to offer some additional advice, though it's been a while since I actually worked with any of this stuff and I'm not up to speed on the current state of the engine, so my figures might be out-dated.
A Myth model can have a maximum of 512 polygons. However, there is a bug in Vegas that causes it to spit out any models with more than 510 polygons.
Apathy has a lot of broken functionality. None of the vertex functions work, and the design of the interface makes it nearly impossible to use some of the surface editing functions. Also, the collection (.256) tags Apathy generates are shit. You must use Amber to replace all of the collection bitmaps if you want your models to look good.
With the above in mind, I also strongly suggest you not use individual collection tags for each model if you can help it. If your map has multiple models that all use similar color palletes for their textures, and/or different models that use identical textures, you can combine all of the textures into one master collection tag and discard the duplicate textures. Then scrap all of individual collection tags Apathy has generated. Then use Fear to change all of the models' collection reference (CORE) tags so they reference the master collection. This process can be time-consuming, but it will make the in-game performance much better because the Myth engine should less texture data to chew through. In case you didn't already know, the Myth engine does not pre-cache texture data--model textures are loaded on-the-fly as you play through the level. Thus, maximum efficiency is vital.
On the subject of using models to deform the mesh (i.e. sticking to the mesh), this isn't really necessary unless you are using a model to build a ramp or bridge, or similar structure. If you just have a basic building sitting on a flat mesh, the deform mesh setting isn't needed. Well, it can help keep things looking better if you have massive explosions that cause HUGE mesh ripples, but even then I don't think it's really helpful or necessary.
A long time ago I wrote up some directions on using Vegas. The text file might still be floating around the Magma Hotline server. Ozone might also have a copy.
If you are planning to have rooved buildings that units can walk in and out of, consider three possible ways to help prevent the units from disappearing entirely from the camera and getting lost by the player. The first solution is the simple Bungie method of making sure the building is tall enough so that when the camera zooms in all the way, it penetrates the roof of the building. Another method is the technique iggy used when making the Nionel buildings in Jinn. Basically, the buildings are annimated models with two frames -- the first being a the "roof intact" frame, the second being the "roof ripped away" frame. The annimation is triggered with a simple script that detects the presence of a player unit entering the building. A third option is to set part of the roof texture to be partially transparant. You can also use different texture permutations: say 0% transparent and 50% transparent. The permutations can be scripted to change at the appropriate time just like with the annimated method described above. Note that the transparent method will only allow you to see the units inside the building, not click on them, so you will still want to make sure the building is of sufficient height so the player can zoom the camera in through the roof to interact with the units.
Models can have annimated textures. By default, textures in a model collection all have one frame each. You can easily use Amber to assign additional frames. I used this technique once to make the walls of a crypt have a flickering torchlight effect.
One last tip on optimizing models for Myth. Consider the angle of the in-game camera and delete all polygons in the model that the camera will never see. This will help you get closer to the 510 count and make the model quicker to load and easier to texture map. 510 polygons doesn't seem like a lot, but with a the right techniques, you can make some amazingly detailed models with far less than that number.
Good luck!
_________________
Mauglir
----------------------------------------- Vista Cartel said...
Model must be a triangle mesh provided in 3DMF format from Meshwork or from FormZ with optimiser.
The textures must UV mapped and be no larger than 256 pixels squared.
The textures may only have dimentions that are to the power of 2 (2 4 8 16 32 64 128 256).
The model may not exceed 512 polygons (in reality myth crashes around 509).
Be careful of normals on polygons. In myth they may not be two sided, one side will be transparent.
There is a limit of 128 models within Myth. This limit also includes animodels.
There is a set limit of the number of frames an animodel may have. About 32 frames for all animodels on a map (I believe).
And you may not have more than 8 unique animodels on a map. From this you may conclude that models are a pain and that Myth sucks. I would agree.
