Creating Static Meshes With Special Compile Tools?
Lazer
Join Date: 2003-03-11 Member: 14406Members, Contributor, Constellation, NS2 Playtester
Join Date: 2003-03-11 Member: 14406Members, Contributor, Constellation, NS2 Playtester
<div class="IPBDescription">An idea I had. (XP-Cagey check this out)</div> I've been doing a bit of ut2k4 mapping and I really like their system of static meshes. What a static mesh is is a model that gets compiled into the map and makes it part of the geometry rather than an entity. Now here's my idea:
We create a new entity called a "func_staticmesh". It has a parameter for the model to use with it. Now, when the compile tools start compiling, they convert the model into bsp and then compile from there. This would allow much more efficient building of prefabs and much more detail can be added to the map a lot quicker without having to mess around with brushwork. (although you would still have to watch your r_speeds)
Here's an example of why this could be so useful. Say you want nice looking infestation, but brushwork just takes you too long and just doesn't look as nice as it could if you built it in 3dsmax. With this idea you could simply add the entity to wherever in that room you want (the origin has to be in the correct place otherwise the whole geometry would get compiled in the wrong place) Now compile to have perfect infestation without having to bother with all that brushwork.
So, with a little work, do you think this could be possible?
We create a new entity called a "func_staticmesh". It has a parameter for the model to use with it. Now, when the compile tools start compiling, they convert the model into bsp and then compile from there. This would allow much more efficient building of prefabs and much more detail can be added to the map a lot quicker without having to mess around with brushwork. (although you would still have to watch your r_speeds)
Here's an example of why this could be so useful. Say you want nice looking infestation, but brushwork just takes you too long and just doesn't look as nice as it could if you built it in 3dsmax. With this idea you could simply add the entity to wherever in that room you want (the origin has to be in the correct place otherwise the whole geometry would get compiled in the wrong place) Now compile to have perfect infestation without having to bother with all that brushwork.
So, with a little work, do you think this could be possible?
Comments
Well, kinda... They still remain as 'entities' - unless specified by collision and antiportals (if applicable), they simply are polygons rendered on the screen. They have their own lightmaps, but the useful part is that they are instanced geometry - each static mesh in a level is only loaded once, then applied to each location in the level. This is why the Unreal Engine can handly very large polycounts when loaded with polys - most times meshes are re-used quite a bit and therefore even though you're rendering a, say, 700 poly model 12 times, you're only using that memory once.
The system you're proposing shares a name but none of the benefits of the static mesh system in Unreal. First off, even if HL could support Unreal-level instancing, the conversion to BSP geometry loses every benefit that modeled geometry gives, save that you will actually get lightmaps on it in HL, though most likely the detail level will have no clue what to even do with that.
Things that could actually be converted to brush work effectively would probably be just as easy to create in the editor, rather than adding extra stages of work in the meantime. Those that couldn't are better off being left as models anyway.
let's use your infestation example:
Why not just create, in your mapping program, a very simple wedge (simple 5 sided polygon) and then stick a model on top of it?
You'd get all the detail of your modeled infestation, and if you were to run at the infestation, your player would go through the model, but only for an inch until you hit the actual real wedge.
Basically, just make a very simple block, and then cover it up with the more complex model.
- Create a brand new empty map
- Create the brushwork that will eventually become the new MDL, or copy the brushwork from an existing map
- Export the map with just that brushwork
- Run an external program that reads in the .MAP file and converts it to a .MDL
However this method isn't perfect. The .MAP file lists all the brushwork as a collection of solid shapes, so the conversion would keep all the shapes intact. This means lots of extra faces that don't need to be there.
To make the converter more poly efficient, you could designate a certain texture(s) for culling. For example, any face with NULL would be ignored and chopped out of the MDL by the converter, leaving only the other faces.
The mapper could also designate where they want the model origin by placing an unnamed info_target in the map file. The converter would read in the location of this point entity and place the origin point there in relation to the brushwork.
The converter could also read in the texture information from the .MAP and attempt to skin the .MDL accordingly (The texture axis, scales, and coordinate info is all listed in the .MAP). This would probably be the least efficient process of the converter, since it would have to place the rectangular textures together into a single skin image. If the mapper used too many textures in the brushwork (Minus the NULL texture) then the skin image would be heavily bloated in size or not fit at all. The mapper would have to be mindful of the size of the textures he/she is using, and try to minimize texture usage or make custom textures.
Good Example: A patch of infestation that only uses one 256x256 infestation texture will work perfectly.
Bad Example: A block of machinery that uses a small strip of a 128x128, a corner of a 256x256, and a repeating pattern of a 64x64 is bad. Far better to make custom textures that are just the parts you want, so that they take up less space.
The tool should be assembling the map components into a series of bsp trees before it outputs the mdl faces -- this is the best way to make sure that there aren't a lot of unused face fragments. The tool should ignore the worldspawn when converting from bsp to mdl; the model would be built out of a series of func_wall and func_illusionary entities.
The tool should have a scaling option so that builders can work with a finer precision than the normal 1:1 map unit scale allows -- after all, models are meant to have more geometric detail than brush work anyway. The origin would be set with an info_target as Yama suggested.
The tool should also generate a map file containing clip brushes that fit the model--it would simplify any solid geometry in the input map and scale it to fit the model.
For simplicity, the tool would require that the entire object being converted use a single texture no larger than 256x256 -- that way I wouldn't be pulling out (as much) hair about converting from one texturing format to another.
I'd like to be able to store lighting information in the mdl (possibly multiple skins with multiple light settings) and use a fullbright light value in the engine for a new model entity, but I don't know if that's practical since it would probably drastically increase the texture requirements to premultiply lighting into the skin -- any part of the texture used twice with different lighting would need to be stored twice.
Now that I've talked about what *should* be done, I'm not going to do it any time soon. I have some more work to do on p14 (found that *&@#^ HLBSP clipping problem yesterday!) and a lot to get done for the next NS beta release; I'm also trying to get the new tools to an alpha ASAP. I think those projects will keep me busy for the forseeable future. <!--emo&???--><img src='http://www.unknownworlds.com/forums/html//emoticons/confused.gif' border='0' style='vertical-align:middle' alt='confused.gif' /><!--endemo-->
Legal copies of Max are outside the reach of the casual level designer. Besides, if you want to make a clip hull for a static mech you end up having to use a map editor anyway.
You could make the mesh in Milkshape at the moment, but there are parts of the interface (of the last version I downloaded, at any rate) I personally feel are poorly designed--if you want to make a static mesh that integrates into map geometry, you're going to want exact scale control and grid snapping to make pieces line up properly with actual map items--that's not an option in Milkshape the last time I checked.. I wouldn't want to guess-and-check to see if I have things properly aligned.
Interesting... just to make sure I haven't got this all wrong...<ul><li>The new program takes as input a .map file containing a "shell" of a map, with the static mesh as a series of brush-based entities.</li><li>It builds a BSP tree (<u>not</u> a Half-Life BSP file with nodes, leafs, etc), ignoring the worldspawn brushes (and possibly faces textured in NULL?).</li><li>It uses the BSP tree to create a .mdl file with only the required faces. It also produces a set of CLIP brushes (possibly simplified?) to be placed in the map. The .mdl is skinned using the WAD texture combined with the face's lightmap.</li><li>Special code is added to NS to always display static meshes fullbright, so they are lit using the "baked-in" lighting. This has the side effect of making them not react properly to flashlights/dlights (although they will be affected by elights).</li></ul>The only really difficult bit I can see is generating the model skin - it would need to convert the lightmap data from the BSP (or light the model itself). CLIP brushes don't block light, so the static mesh wouldn't create shadows in the map. I think NULL blocks light, but doesn't that also split faces?
Interesting... just to make sure I haven't got this all wrong...<ul><li>The new program takes as input a .map file containing a "shell" of a map, with the static mesh as a series of brush-based entities.</li><li>It builds a BSP tree (<u>not</u> a Half-Life BSP file with nodes, leafs, etc), ignoring the worldspawn brushes (and possibly faces textured in NULL?).</li><li>It uses the BSP tree to create a .mdl file with only the required faces. It also produces a set of CLIP brushes (possibly simplified?) to be placed in the map. The .mdl is skinned using the WAD texture combined with the face's lightmap.</li><li>Special code is added to NS to always display static meshes fullbright, so they are lit using the "baked-in" lighting. This has the side effect of making them not react properly to flashlights/dlights (although they will be affected by elights).</li></ul>The only really difficult bit I can see is generating the model skin - it would need to convert the lightmap data from the BSP (or light the model itself). CLIP brushes don't block light, so the static mesh wouldn't create shadows in the map. I think NULL blocks light, but doesn't that also split faces? <!--QuoteEnd--> </td></tr></table><div class='postcolor'> <!--QuoteEEnd-->
I thought it would just be simpler to convert the .MAP coordinate/texture info into a .MDL, by tesselating any surface that wasn't a triangle, and ignoring any surfaces that were textured with NULL.
No need to come up with lightmaps and other such things, the whole point was just to have an easy way of making MDLs so that you could make use of their benefits (better framerates when working with details).
Anyway, seeing as a static mesh .mdl is going to receive the rather basic lighting system (all of its polys take on the colour of the lightmap at its origin), how about a way of applying a 'lightmap' to the skin? HLRAD calculations are applied to the models mesh, but instead of writing to the lightmap, it would alter the skin of the model (or output a modified .bmp, whatever). You would then need to render the model in game as Additive 255, to disable the default lighting system.
Now the only other thing we would need is to use client side entities to display these meshes. I think a recent thread showed this is impossible though <!--emo&:(--><img src='http://www.unknownworlds.com/forums/html//emoticons/sad.gif' border='0' style='vertical-align:middle' alt='sad.gif' /><!--endemo-->
Why not just extrapolate data from the .mdl file and use that to create lightmaps, cliphulls, etc. for the map and save the lightmaps back to the mdl?
As for modelling stuff, Milkshape 3D is NOT an expensive program at all and it is very easy to use, especially for the casual level designer.
Legal copies of Max are outside the reach of the casual level designer. Besides, if you want to make a clip hull for a static mech you end up having to use a map editor anyway.
You could make the mesh in Milkshape at the moment, but there are parts of the interface (of the last version I downloaded, at any rate) I personally feel are poorly designed--if you want to make a static mesh that integrates into map geometry, you're going to want exact scale control and grid snapping to make pieces line up properly with actual map items--that's not an option in Milkshape the last time I checked.. I wouldn't want to guess-and-check to see if I have things properly aligned. <!--QuoteEnd--> </td></tr></table><div class='postcolor'> <!--QuoteEEnd-->
Max might be out the way for casual level-designers but Maya certainly isn't, well not for those people that bought UT2k3. You Get v4 for free and downloadable updgrades for free, although its so complex I got no time to learn it <!--emo&:(--><img src='http://www.unknownworlds.com/forums/html//emoticons/sad.gif' border='0' style='vertical-align:middle' alt='sad.gif' /><!--endemo-->
Anyway, seeing as a static mesh .mdl is going to receive the rather basic lighting system (all of its polys take on the colour of the lightmap at its origin), how about a way of applying a 'lightmap' to the skin? HLRAD calculations are applied to the models mesh, but instead of writing to the lightmap, it would alter the skin of the model (or output a modified .bmp, whatever). You would then need to render the model in game as Additive 255, to disable the default lighting system.
Now the only other thing we would need is to use client side entities to display these meshes. I think a recent thread showed this is impossible though <!--QuoteEnd--></td></tr></table><div class='postcolor'><!--QuoteEEnd-->
Yes, it's just a way to automatically generate .mdls. The main benefits would be the use of epolies rather than wpolies and greater detail in the visible mesh. The clipbrushes would probably have to be simplified (not sure how complex this would be to do automatically), and the model's skin would have to have the lightmaps baked into it.
Client-side studio models aren't impossible (DoD has them), they're just a lot of work to do properly. Client-side BSP models, however, are impossible without restricting yourself to OpenGL mode only.