Mapping for modular textures
I've recently been reading this article on the wiki, and though it discusses the advantages of the technique, the buildings all seem to be one mesh (excluding the roofs) how can you set up a mesh so that I can change the texture of individual sections like that? Do I use multiple UV maps for different sections, and if so, wouldn't that be a detriment to performance?
Replies
If you mean the wall sections between the beams when you say individual sections, then I'm pretty sure those faces are split according to the pattern of the beams (or at least some of them) and you can move the face around in UV space to get it where you want, seams don't matter all that much since they are covered up by the beams. You could also add a bit more geometry and get better vertex shading.
There is nothing saying you can't split these sections up to make them modular, but I think it should only be done to a small extent as it could end up being a nightmare trying to fit these things together. The style is also simple enough that you could create some unique designs fairly quickly.
I suppose there maybe some performance implications with using so many material ids, but if you're doing a whole village its probably worth it. Also if you break it up modularly into many objects along with many material ids, that will likely be more draw calls than the mesh merged together (depending on how the engine handles this).
This is indeed very bad for performance. Usually you should not use multiple materials for each model.
But it depends on how the game engine is set up. If it handles instancing really well, then you can make the buildings out of multiple separate objects. But if this kind of approach slows down the framerate, which it usually does, then it is better to use a single material for the whole house (or large chunks) and use a texture atlas.
Or worse, it bases it's visibility culling calculation on the objects local pivot and it culls the whole building while its still visible, which is more likely to happen with big meshes.
My original thinking was that, say for a city scene, all brick could be one draw, all generic windows could be another, etc. Based on that, you'd end up with way less draws than if each building was it's own texture, on top of which you'd benefit from the high resolution potential of a tiling texture. We've been doing some performance checks on another project, and our draws are our big downfall, so I'm proactively squishing these down.
The brick portions still tile, but they tile on the same map as the windows and other bits. However since they're tiling, I'm not able to put AO into this set. Alternatively, if I unwrapped the entire building in order to get unique UV's, I'm worried my resolution would plummet. Is there a way to get around this, or is the solution putting AO into a different UV channel, Vertex Color, or someplace else?
http://www.scriptspot.com/3ds-max/scripts/texture-atlas-generator
As for the problem with AO, the 2nd UV channel seems to be a logical way forward if you have a lot of unique shadow details. Keep in mind you can stack/offset UV shells that are similar(like the windows) saving you some space and allowing you to up res your AO without having to up your map size. If you have some unique shadow details (like a drain pipe, AC unit or planter box) you can give the affected pieces their own space, or it might be fine just to leave alone and forget about the shadow.
Stacking the lightmap gets you into trouble with UDK sometimes, because it bakes in 100% unique lighting info into the light map. You can still do it if you know UDK will calculate the lighting on each tile exactly the same. but if you're engine doesn't render/bake lighting into a lightmap, then you are free to stack AO shells.
If you lay it out properly you probably won't need a 2nd UV channel, you can add it to the diffuse atlas.
I don't think vertex color will net you very good results unless the mesh is fairly dense and I'm not sure if its any more efficient that an second UV channel? Also the workflow for baking lighting into the vertex color channel can be a long drawn out ordeal.
I ran it a few times on that model; if I do it per-part (the original mesh is about 150 boxes), then each face quickly turns into 50 faces, and my mesh gets spendy FAST. If I do it to the entire building, flattened to one mesh, it crashes on me. I have a lot of tiling of the bricks, so I'm wondering if that's causing me problems?
I guess the advantage of vColor AO is that you don't need to supply a map. You're not "resolution bound" by your image, but you're still bound by the number of vertices. Also, Radiosity sometimes does stupid things with intersections; one side is white, the other is black. I'm playing around with the idea of baking Radiosity and Light Tracer with a few bounces, then blending the results into vColor... not sure if that's a solution or not yet, though.
For example, if you run it on a single poly that has a brick material set to tile 2 times in both directions and you run the script it will carve the mesh in 4 pieces and stack the UV's. If your mesh is already carved up, then it could run into some problems.