Hi guys, From my experience with modding, there are a lot of people that do like to model, but do not necessarily like/know how to create UV-maps and textures. If you are starting a modding team and are missing out on a UV/Texture artist, you can consider calling me on board , or buy the tool from Orbolt and have a go at it yourself. I like to lend a hand in this, by creating an automation for this. It will not create perfect UVs, but they are way better than standard unwrap mappings from 3dsmax/Maya, as well as optimized for vehicles in particular (or any object that symmetrical across one axis) Documentation: http://www.twandegra...Vgen_Manual.pdf Orbolt page: http://www.orbolt.co...raaf::TdG_UVgen Note that the tool will work with the free learning edition of Houdini. The UV's generated are suitable for the use in video games, alternatively, they can be used as a base to manually edit. The process is almost completely automatic, with various settings to suit particular needs. Apart from UVs, the generator is also capable of creating base-textures, to speed up the texturing process. UVing Features: - 6 axis UV projection. - Projection based on Smooth groups (or vertex normals). - Automatic detection and mapping of cylinders. - UV mirroring across a plane of symmetry. - Limited support for UV relaxation. - Automatic detection and overlapping of identical shapes (wheels for instance). - Automatic UV welding to limit the amount small shapes. - Automatic UV layout. - Automatic UV compressing. - Support for Non-Commercial Houdini licences (UVs can avoid watermarked areas) - Support for manual tweaking of the UVs. Texturing Features: - Reference map, to see which texture area's correspond to the model. - Limited support for Tangent/Object space normal maps and Bump maps. - Ambient occlusion map, tries to prevent texture overlapping automatically. - Highlights/weathering map, tries to prevent texture overlapping automatically. - Plate map, uses a given angle to divide the model up into plates. (texture changeable) - Rivet map, uses the same angle to create rivets. (texture changeable) - Automatic rendering setup. - Automatic rendering and saving of the layers as separate textures.
not a pro modeller, but I took some classes in college where we used this tool, it was very effective and super fast http://www.uvlayout.com/ i've also heard good things about this one http://www.pullin-shapes.co.uk/page8.htm thoughts?
I know there are these 3rd party tools, like those you pointed out, as well as roadkill, but I believe those are more specialized in organic shapes . I am building my own tool, targeted for more angular shapes, as well as allowing for overlapping/mirrored UVs, which I believe those tools generally are not really useful for. Also, my tool creates UVs totally automatic, you do not need to edit them at all (though you still can if you want). The result in the example above can be generated in about one minute. I do not know how exactly to help others yet, as Houdini has a bit of a steep learning curve. I may want to eventually be able to send you a processed model + base textures back if some people send me their models, if I join one/some of the teams possibly. Note that the tool is not at this stage yet.
I do not know what exactly you mean by charting, if you mean UVmapping, basically what it is currently capable of, is shown in the picture above. It is by no means perfect yet, or will it ever be better than a professional doing it manually, but I think it way better than nothing and could lower the barrier to actually finishing a mod, as in my experience, the texture work is what bogs down most modding projects, including ones of my own in the past. Or alternatively a more seasoned modder could speed up the process by starting from the generated UVs, rather than creating them from scratch. If you mean automatically converting the files when someone would upload them to me, that is not what I meant, while I could go into that depth of making that work, I do not really have experience with that yet. I do know Houdini has support for stuff like this though. I meant if someone sends me an .obj file for instance, I can simply put it in the pipeline and save the output automatically, however I would still have to manually upload the file and send it back, as well as importing the file.
also, not many people know that, when more you make cut in UV then less optimal model will be. But i dont know exacly if this has any meaning in PC games. every vertex have Position, Normal, Color and UVW information. If any of this information is diffrent, then vertex will be saved and rendered as diffrent vertex. For example: If we have Cube, we see 8 vertex. But if has hard normals, than every vertex have diffrent information for all faces he is connected to - and becouse of that we have not 8, but 24 vertexes. Same thing is with UV and color. So when we get simple unit from PA, that has this simple gray texture with white borders, it propably have all vertexes duplicated many times. We need to cut out almost all quads. And for what? To reduce texture size from many 1024x1024 to one, single, small texture. But question here is, if we need so many power from textures, instead bigger vertex count? Well... its for sure easier to batch units with same texture and material. And also all this units are made from hard edged bricks. Maybe there is not to much more vertexes.
What you say about duplicate vertexes is mostly true I think, but I don't think there is not much you can do to avoid it, when going for a hard edge style. Except from using connected vertexes in the inner surfaces, but those that do not really add much to the surface anyway should most times be removed in the model to begin with. except in some specific cases of very long triangles (causing lighting issues) I don't know if PA is doing much in letting units share texture-maps, as I have seen a one-unit texture map of the air engineer. While it is easier on the video card, it is harder to maintain for developers, for instance if a texture map is used for 20 units, only one artist can edit one of those 20 units at the same time, or they need to recombine the textures again with all the problems associated with that and version control. I also do not know how much adding say 100 vertices to one unit is going to cost in terms of performance. When there are a lot of those units, 100 vertices could multiply quite fast, but I heard about the engines using some nice instantiation tricks.
Adding 100 vertices shouldn't add too much memory overhead if you don't have to many attributes assigned (uniforms are fine) and you use instancing. At least not in comparison to all the other stuff you have in memory, e.g. all the textures and the face list. While it does increase memory usage, it should still be safe in terms of computational overhead (at least for full LoD levels!) as the number of faces doesn't increase and the expensive stuff happens not in the vertex, but in the fragment shader. It does have an impact though if the screenspace of the object is so small, that the workshare of the vertex shaders exceeds the workshare of the fragment shaders, e.g. because multiple vertices map to a single pixel. Building a cube from only 8 vertices and using a normal map in the fragment shader instead of normal attributes on the vertex should help a lot when you have many, many instances, e.g. if you are going to use the cubes as voxels. Assuming that most objects are partly hidden and you have many instances where a full object maps to a single fragment, this can can save you up to 66%, compared to using cubes build from 24 vertices. (Note that you shouldn't remove the original normal attribute from the vertices. Although you are not using them in the fragment shader, they are still useful to OpenGL as they allow efficient backface culling.)
Almost all of our units are hard edged, which means they have a ton of split edges to begin with. The other way to handle this is with normal maps on a mesh with a single smoothing group. This is how we handled things in SMNC. For PA we want to be able to render thousands of units at once (right now we're doing hundreds). In the current version of the game each unit is being rendered by itself which is slow, but in the future we plan on rendering them in large batches of several hundred at a time. This is one of the bits of tech we implemented on trees / small rocks / etc. on the planet currently that was a big win for performance. For this kind of batching, or instancing, can only group together models that all have the same single model, single material, and single set of textures. That means that while we could do stuff like all light grey panels share the same texture across all units, what that actually means is we would have to render that section of every unit separately from the rest of the unit as it's a different texture. We could atlas all the textures together into one giant shared texture, but really texture memory storage is not where we're hurting on performance.
One of the reasons that we bake down into a single texture per unit with a unique UV space per unit is that we may want to virtually texture the units eventually. This makes it almost trivial to do that (or at least a lot easier).
I thought atlasing was done because swapping between several different texture files was slow. Wouldn't there be a performance benefit from atlasing? I don't know much about 3d games, but I developed as asteroids game with procedurally generated asteroids, and I had to create something that would properly do UV mapping to the polygons. After making a function for doing the UV mapping, the rest was easy. The hardest part was understanding how atlases and UV space worked, and even that wasn't difficult. Now, I know that you're not going to be doing dynamic UV mapping, because you're not generating units on they fly, but I can't imagine that atlasing is so difficult that it's not worth doing... Or is it planned but not priority? Off topic: how are the units positioned? The only way I can imagine you positioning units on a sphere is with a lot of trig, and that is inherently inaccurate, not to mention hard on the processor. I'm assuming it's probably some fancy matrix work that I don't quite understand.
Updated , see first post: -Improved Layout. -Implemented UV mirroring over world origin. -Added Uv patch to reference texture generator.
