Modding Enemy Territory: Quake Wars
F.A.Q
Brought to you by the team of MechWarrior: Living Legends total conversion for ET:QW http://www.mechlivinglegends.net
MODELING:
Q: What is the approximate poly counts on vehicles, player models, first person models (hands + weapon), static buildings and finally building interiors.
A:
-Vehicles: 4000-6000 Polygons
-Player Models with weapon: 2000-3000 Polygons
-First Person: 1200-2000 Polygons (More could be spent
here as there is always only one of the screen)
-Static buildings: Unknown
-Interiors: Unknown
Note: These are approximate counts splashdamage are using, but keep in mind that if your mod has double the players/vehicles you should expect to half the count and if it mod has half you could double the count.
Note2: There are other factors that need to be considered as well, Splash Damage is attempting to keep the batch count as low as possible; the batch count is the number of materials | surfaces that is sent to the graphics hardware for it to draw. The technique being used by Splash Damage is a “texture sheeting” technique. This technique is essentially combining textures for most things that are seen together, for example, a building made the old way could have been constructed with 4 different 512X512 textures, 2 wall textures, a roof texture and a floor texture. This new technique is putting all of these texture on one bigger image one above another so now you end up with one 512X2048 (tall and thin) texture sheet holding all four of the textures. This, essentially, reduces load on the graphics card since it only has to call one texture sheet rather than 4. Another note is that it should be done this way rather than make a big square texture so that they can still tile horizontally.
Note3: Another very important factor will be the shadow complexity, for every animated model you should, though the game doesn’t require one, have a much simpler shadow model. The ideal poly counts for a shadow model will be as low or lower than 25% less total polygons than the full polygon model. There will also be support for multiple LODS, which will further reduce polygons, shadows and batches.
Q: Will player md5 meshes be separate from kit md5’s?
A: There will be one skeleton for all the players in the game. This skeleton will have 5 models per team (which breaks down to one per class) there can then be attached extra pieces of kit anywhere to the player model relative to the bone itself. Most of these pieces of kit will be attached twice since it needs to be attached once to the player hand and once for being attached to the players body and will be shown or hidden depending on the item currently selected by the player.
Q: What extensions will be supported for map objects? Will there be additional support for different extensions?
A: The engine will still support .ASE .OBJ and .LWO
-added by Hakuryu “jRAD stated they support .obj, .lwo, .ase, and our own .surf format”
Q: Will cockpit models and third person models be created using the same md5 mesh or will they be separate models by themselves?
A: The cockpits will be separate md5s that will only be shown one the player is inside the vehicle, the reasoning behind these it to avoid any intersection between the two models or “bad clipping”. However, the ability to model the actual cockpit into the vehicle model itself is still a viable option as the feature of separate cockpit meshes is not essential to use.
Q: Will the “world editor” have the ability to generate collision meshes and .af definitions for md5s?
A: md5s cannot have collision surfaces in them (the game will essentially ignore them) so the collision meshes will need to be paired with a collision model generated by a third party 3d package or the world editor itself.
Q: What will the In Game scale for modeling be?
A: The scale will be the same as Quake 4 and Doom 3 using 64X64X64 generic units per grid. “A world unit is 1 inch, or 2.54cm in RTCW and Wolf ET. Radiant units == Game units, so you can open up the goldrush.map that comes with the Wolf ET tools to get sizes for everything, and convert from there.”–Wils
Q: What system is being used for rendering building interiors vs. exteriors?
A: The interiors will be portaled off so they will not be rendered while outside, and the outside wont be rendered while inside. It is very important to bear this in mind while building interiors because if you want a close to doom3 level of detail you will not be able to any direct line of sight type views to the outside IE: windows and doors.
ANIMATION:
Q: How many bones influences per vertex will the engine support?
A: It will support 4 bones influences per vertex.
Q: Will the player rig being used for all classes in the game be shipped with the SDK?
A: It should be included. Unconfirmed.
Q: How will the animatons be done of the treaded tanks?
A: Like most games the treads will actually be animated UV’s that give the impression of motion. However, the wheels on these vehciles will be animated meshes.
Q: Will the mod teams be capable of creating custom model rigs for vehicles as well as for player models?
A: Yes! But they will obviously be harder to setup, as they will require more asset swaps between the modelers and animators.
Q: Will there be the ability to perform “per vertex” animations rather than bone animations for certain models?
A: Unfortunately no, though there will be “vertex deformation shaders”
TEXTURING:
Q: What will the max resolution of a vehicle/player texture in the engine?
A: The max resolution is only dictated by the video hardware of the client! The best technique to working your resolutions out (always remembering that the bump, diffuse and speculars are separate) will be to mock a map up in either Doom3 or Quake 4 using the same number of textures and resolutions and what res they are going to have to be to fit and if they are going to fit into the memory of the video hardware capabilities that you are working towards. Its also important to remember that the video card will also store the 3d data so its imperative to take this into account, thus game testing with placeholder assets will be very important. A good technique will be to duplicate all the assets you already have multiple times and sticking them into a map to simulate load on the card.
A good goal will be to aim for all the player models/vehicles/weapons to fit into approximately 60megs and all the map textures to fit into 60megs as well. It’s going to be important to make sure the models are going to hold up at this res and the UVS are focused in the important areas.
Q: Will ET:QW be similar to doom3 or quake4 in respects to materials and scripts.
A: ET:QW should be very similar to doom3 or quake4, more details will be here when the game ships and we can list any change
Q: Will the convention for ET: QW be .DDS texture or targa .TGA?
A: .DDS textures are essentially pre-compressed .TGAS so that they can be loaded on the video card faster. Essentially, you never work with .DDS, the game automaticly generates them; hopefully, we will see the TGAS included on the disk (provided they fit)
LEVEL EDITING:
Q: Will there be any capabilities of world edit to view total batch or polygon count per map?
A: As with doom3 there will probably be a current on screen polycount/batch view, which actually, is more usefull than a total count per level as not everything in a level is drawn at once.
Q: As far as system specs go will it be difficult for a modder with an “average” system to generate mega-textures or will it require beefier hardware?
A: Memory will be the principle concern when generating mega-textures, the more memory the better.
Q:What will be the ET:QW map format?
A:"The ET:QW map format (.world) is a new format that supports easily adding new primitive types, metadata such as grouping information, and arbitrary properties on everything. The base primitive data stored will be familiar:
faces have planes, a 2D texture matrix + offset, material, and texture bounds (a new little toy we’ve cooked up.) Patches have control points and UV data, as well as their own additional texturing info. The format also supports references to other .worlds (these can be nested inside of each other.) "–Birdawg
Q: Will the terrain be scripted similar to using trigger type brushes for vehicle/player collisions and reaction or will it require the use of a particular brush to generate certain texture reactions in individual type areas? IE: Slippery mud, snow concrete etc.
A: (ANSWER by: Hakuryu) traction information will be derived from the megatexture. An ice texture will be slippery, while a concrete one will give good traction.
CODING:
Q: Will there still be the use of the .def scripts?
A: The system will be extremely similar to the doom3 one; there are in addition .scripts as well.
Q: Still have the ability to create custom .mtr materials?
A: Yes, but the format will be slightly changed, however, it should be fairly easy to adapt too.
Q: Will there be any additional physics objects used in the code (sticky physics for explosives to vehicles or objectives etc…)
A: Unsure.
ADMINSTRATION AND ORGANIZATION:
These tips pertain pretty much to any mod team but they are some good tips that have been pulled together from various forums and FAQ’s.
One important tip about planning is to get assets in your game in a rough form ASAP and to test them to make sure that they work out ok and then to refine the art work later based on how its looking in game. A good concept will not necessarily mean a functional game asset, though this might not be the fault of the asset itself.
For example here is a nice concept.
http://www.mechlivinglegends.net/index.php?option=com_zoom&Itemid=34&page=view&catid=2&PageNo=1&key=1&hit=1
Here would be an example for the workflow:
-
Have the 3d modeler block out the cockpit model
-
Apply a “noisy” texture (making it easy to see the resolution of different points in the UV.) It should also be mentioned that when you put the texture into the game you need to make sure that it take up the same amount of space you expect it to. It really isn’t important if its boring or you simply do a copy paste job from another texture as long as it is a unique and fully setup with a material script and all maps associated (diffuse/normal/specular and any others you may want.) this way you can tell if everything is going to fit properly into the memory spec you are aiming for.
-
Implement the rough model in so that it work in the game with correct number of animations.
-
Review functionality, for example, is the screens big enough? Are they in the right place? Are they even going to be used? Have we used high enough resolution where the player’s attention will be focused?
-
Have the 3d modeler make the required changes and review functionality again. You could take a screenshot in game and send it back to the concept artist to paint over.
OPTIONAL(Though it’s a REALLY good idea): the final stage below could be delayed until all assets have reached the functional but ugly block out stage. -
Send all models back to the 3d modeler to remake the models with the new and hopefully finalized and perfect design.
The sooner the assets are inputted into the game the sooner you can check to see if you design is working and you refocus priorities in order to get the most important stuff done!
The problems you might otherwise face will be:
- And inefficient game asset. Textures and polygons may be placed where the player will never see them and the details won’t be focused in more important areas.
- A game asset that doesn’t fit the concept and design requirement
- A waste of time for the team members who the get bored and leave as they have to remake the model several times
- A large amount of time spent where the game is unplayable because there are no placeholder assets for game play to be tested, and as well all know if a mod or game is pretty it will be played for a week, if its fun it will be played for a year.
This workflow model also means that you could create a large number of placeholder type assets and decide which needs the most focus to make the mod playable. For example you might decide that cockpits don’t actually add much to the game play or “fun” factor and you could probably cut the cockpit models from the first release of your mod.
Of course these are only tips and no two mod team run things the same way, however, this is a very organized and professional approach to developing playable fun mods in a timely fashion.
This F.A.Q will be updated as more information becomes available and feel free to post any Question and answers to be added to this as it will be added to the ET:QW mod wiki site and the more complete we have it the better it will be for ALL mod teams working on their individual projects. The best mods are produced from strong mod communities that stick together and help each other.
This documentation has been brought to you by the, MechWarrior: Living Legends team, you can view our site by clicking on my signature. My hope is that this be added to the mod wiki or stickied in SD forums.
DISCLAIMER: This information may not be 100% accurate as it has been compiled using all published resources from Activision, Splash Damage and ID software.