MWLL|Criminal
07-14-2007, 04:13 AM
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
-Third Person (World) Player Models with weapon: 2000-3000 Polygons
-First Person weapon and hands: 6000 Polygons
-Static buildings: varies
-Interiors: varies
Note: These are approximate counts that Splash Damage is 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 and 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 automatically 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.
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
-Third Person (World) Player Models with weapon: 2000-3000 Polygons
-First Person weapon and hands: 6000 Polygons
-Static buildings: varies
-Interiors: varies
Note: These are approximate counts that Splash Damage is 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 and 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 automatically 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.