good thread, Per.

I'm not entirely sure what your first question is, are you asking if you have to orient your UV sections a certain way? If so, then in my experience the answer would be no.

Question 2, It generally does help to have bevels on the model, it makes for a cleaner normal map and helps avoid bends in light. Plus you get rid of sharp angles which can hurt the illusion the normal map creates. As far as pores and dents go, you can go ahead and put those into the normal map (if the pipeline doesn't use bump maps).

[ QUOTE ]

I would like to ask a question now: For those of you who see any advantages to building and optimizing a game model before you start working on the hipoly, what are they? I see a lot of people discuss this subject without ever stating what the advantages would be of finishing the lowpoly work first.

[/ QUOTE ]

Circumstance has forced me into working this way a couple of times. Not many, just a couple. In an nutshell, we were a 3 man team consisting of character artist, character TD and animator, working against a hard deadline to complete a demo to show our venture capitalists that we hadn't been spending their money in Vegas.
Now, in that instance, with each team member having a very specific role and little time, it made infinitely more sense for me to nail the mass and proportions of the game resolution model in a day and hand it off for rigging and animation, than to have those guys twiddling their thumbs for days while I sculpted leisurely and merrily away in Z. So really, it's a time management issue. It's definitely a bit more scary, since there isn't too much scope for tweaking stuff at the sculpting stage if someone else is well into walk and run cycles for the creature. But yeah, where possible I'd start with the sculpt.

Thanks for contributions!
Just a quick one before bed...
SupRore: Self intersection as I understand it would mean the rays are crossing at some point. Now, if the hipoly mesh is placed beyond that point, the end result on the normal map will be a mirror image of that area.

Again a ray-path visualization illustration thing would be super useful here. Basically draw a line from each vert to its corresponding cage vert. That's the path the ray is going to travel. All the rays between two verts will have angles that are interpolated between them. Wherever the ray intersects with the hipoly, is the are where the normal will be read and plotted back on the normal map.

For a cylinder, ideally you'd want all the top triangles to have normals that face upwards and the side triangles to have normals that face outwards, in a circle. That would give you the best result. However, when both top and sides are the same smoothing group, faces on the side and top share vertices, and since normal are per-vertex, you now have a 45 normal degree angle around the rim. For many cylinders, you'd want to grab the rim verts in cage and pull them down so they describe rays/paths that are perpendicular (stick out from) the cylinder sides. What will happen now is that you should get perfect cylinder sides.. the caps, on the other hand, will have rays that travel in a 180 degree arc on the extreme. In cases this may be ok, where the surface there is simple, or hidden by other geometry, like a tube is sticking out of it or something.

These things only tend to be worth playing around with only if you can't afford to add more faces to smooth out the normal transitions.

You can set the cap elements to a different smoothing group. You'll get a hard edge, which may not be too bad in some cases. Ok, this leads to another issue, which I'm going to describe just superquick now:

the render engine doesn't care for polygons as much as vertices. When your art lead gives you a poly budget, he's basically giving you an approximate vertex budget. When you use smoothing groups (I take it everyone's familiar with the term, even if it's max-centric), the engine breaks up vertices at that point, even though they seem connected in the 3d editor. This, of course increases the vertex count. Basically what this means is that instead of setting cylinder caps to another smoothing group, you might as well chamfer the whole ring there. The end vert count will be the same. The reality of performance is a hell of a lot more complex than polycount. Often by optimizing and triangulizing a mesh too much, you're creating something that is less optimal to render than if you actually ADDED geometry. One thing all this translates to is that once you've hit your 5000 poly budget for a model, you should in most cases be free to add a couple hundred tris to fix normal mapping errors, it's going to mean zilch for the render performance.
Well, better yet, always keep in mind that you're going to be adding geometry AFTER you've unwrapped and tested normal maps on your model. I always aim a little lower than my budget, then slightly exceed it after adding geo to fix shading. That's a lot better than being stuck at 5000 with no room to navigate since you've carefully balanced your tri usage so well that you can't remove a couple without the whole thing falling apart.

Phew, I'm gonna have to learn to be more concise

Ah, thanks for the excellent post. [img]/images/graemlins/smile.gif[/img]

The quick breakdown of verts/smoothing groups in engine helps a lot. I'd read before that separate smoothing groups would double the vert count on the edges, but for some reason it never clicked with me that this would mean chamfering the loop was pretty much the same performance-wise.

Per, on the subject of chamfer/bevel/hard edges, I wrote up a somewhat brief article a month or two ago:
http://www.twcenter.net/wiki/Beveling

hehe no per, glad somebody try to explain what lies behind [img]/images/graemlins/smile.gif[/img] please don't be concise ^^

[ QUOTE ]
In realtime rendering, vertex data is generally linearly interpolated between vertices.

Now, in offline rendering the interpolation does not have to be linear
Non-linear shading can be performed in realtime shaders, though due to the calculations involved it would often be more beneficial to rendering speed if you simply add more geometry instead.
When you use world space normal maps, the problem goes away, since you're no longer relying on the existing, crude vertex normals of the mesh.
edit: oh, and this is an advanced topic, Brice is just hardcore and you won't be expected to know this stuff to work anywhere... though it can't hurt.

[/ QUOTE ]

thx per for your answers [img]/images/graemlins/smile.gif[/img] I got your point about interpolation, but I still can't figure out why results vary from one software to another, both in realtime rendering. Maybe some do renormalize the interpolated vertex normals while some others don't? Is there different algorithms to generate normals?
For example max don't display seams on uvs borders most of the time, while maya does. I think it's because maya generates vertex's normal on the fly for cgfx rendering (highquality is basically a big cgfx), while max stores some kind of precalc normals. Since vertex are split on uvs borders as well as hardedges - as you mentioned above - the normals are slightly different, showing a seam.
What do you think? I do understand adding geo will help normal map covering a tighter angle, I just like to know hehe It will help me going more easily from one package to another.

[ QUOTE ]

Circumstance has forced me into working this way a couple of times. Not many, just a couple. In an nutshell, we were a 3 man team consisting of character artist, character TD and animator, working against a hard deadline to complete a demo to show our venture capitalists that we hadn't been spending their money in Vegas.
Now, in that instance, with each team member having a very specific role and little time, it made infinitely more sense for me to nail the mass and proportions of the game resolution model in a day and hand it off for rigging and animation, than to have those guys twiddling their thumbs for days while I sculpted leisurely and merrily away in Z. So really, it's a time management issue. It's definitely a bit more scary, since there isn't too much scope for tweaking stuff at the sculpting stage if someone else is well into walk and run cycles for the creature. But yeah, where possible I'd start with the sculpt.

[/ QUOTE ]

I've used this workflow before as well for more or less the same purposes. Getting work to the animator faster so that he could animate while I sculpted and we'd both finish for the deadline.

Okay, this thread is awesome, but I have a few (undoubtedly noobish) questions.

You say cage and low poly, I think I'm getting confused, and I think I'm about to answer this myself.. it just got confusing the way you guys were wording it..

CAGE is what you use to build the High Poly from, Right? and the low poly is obviously the model that will be used in game that the high poly is projected onto? I guess I just got confused with the term CAGE.

Ok, the other thing is you were talking about having intersections when you go to bake the normals in.. between the hi and low poly models.. and this is.. ok to do? having them intersect? Not sure I fully grasp that yet, but if that's true I guess you are trying to say that it shoots the rays out both ways and not just inside from the low to the high? (or whatever)

and here "Basically draw a line from each vert to its corresponding cage vert." I think I might be reading the context wrong but I believe you are talking about from the high to the low (vert coming from hi, cage vert being low?), how can there be corresponding verts because the high poly is going to have a shitload more than the low obviously

I hope I'm not getting too off-track or reading stuff the wrong way, any help is hugely appreciated, this info is gold for trying to learn and understand better.
Thanks!!

Projection cage, which casts the rays that determine the normal map's rendering -- from Ben's tutorial --:



Doesn't theoretically have to be your lowpoly, as far as I understand, the uvs just need to line up.

dumb question answered

Profanity on message boards is fine when its used with reason. Honestly, it makes you seem retarded when each sentence contains the f word, not to mention quite annoying, at least to me.

Cage is your projection cage, or a quaded-out low-res model that you sculpt from. Different contexts.

yeah, I'll cut the bombs, they are unnecessary, I was just getting flustered. I was thinking correctly when I was thinking about the 'cage' then, and wasn't even thinking about the fact that you can tweak the cage as much as you needed. d'oh. Thanks.

[ QUOTE ]
Again a ray-path visualization illustration thing would be super useful here. Basically draw a line from each vert to its corresponding cage vert. That's the path the ray is going to travel. All the rays between two verts will have angles that are interpolated between them. Wherever the ray intersects with the hipoly, is the are where the normal will be read and plotted back on the normal map.

[/ QUOTE ]

Thanks for explaining that, that cleared up a lot You talk about adding temporary geometry, how would I go about using that? I've tried using tesselate with tension: 0, so it has the same uv's, but it doesn't make my normal maps any better.
And sorry for the many questions but another:
Sometimes parts of the mesh can have the same uv chunk because of similar geometry, but it would not look good because the normal map. How do I know which parts I can mirror fine and which totally don't work?

Appreciate the questions and feedback, people. It's all good stuff.

I know it can be hard to go through all the info already in here and know what's relevant now. Call it brainstorming, we're just pouring out bits of info and discussing, it should all come together in the end.
Here's something from another thread:

Basically what happens is when drawing a new strip, the renderer only has to plot one new vert to describe an entire polygon.

The problem is.. it's not like you can spend time benchmarking every single model you make and tweak it until it has the optimal tri flow. Most of the time you'd be talking about such tiny performance improvements that it's not even worth considering.

There are so many other factors involved as well, when it comes to tweaking for performance, that you're better off just following the polybudget you're given fairly accurately.

The reason why geometry is split up and vertices doubled at UV and normal seams, is that the typically a vertex is stored on the graphics card as having only one uv coordinate and one normal.

On the topic of vertex duplications, it should be mentioned that vertex count is more important than triangle count. I know I'm not going to change years of habit. But vertex count is really where the rubber meets the road, not triangle count.

Overuse of smoothing groups, over-splittage of UVs, too many material assignments (and too much misalignment of these three properties), all these lead to a very different and much larger vertex count. Which can stress the transform stages for the model, slowing performance.

FatAssasin made a great Maxscript awhile back that gives an accurate vertex count, might be useful.
http://boards.polycount.net/showflat...age=0&vc=1

Kind of in the same ballpark, too many bones affecting each vert is bad (>4 per vert), and too many bones on one mesh is also generally bad (>30 or so. Better numbers here anyone?).

Cool thread Per2048.

Hah - just saw your posts about vert counts, after I posted about it in the tri-strip thread.

Anyways, just wanted to mention the way Maya uses's it's cage (called an envelope in Maya). It does NOT control the direction the rays are fired - it only limits them from passing (well... one option does that, the other chooses the intersection nearest the envelope) through. This is really what a cage should do - firing rays not along the surface normal is actually incorrect, but tends to look better visually in some cases. I think skewing the cast increases the parallax erros somewhat, but it's a sketchy area. A model will always look the best when viewing "down" the normals it was cast at. The old cyclinder with wobbly edges (a great test case) looks shitty when viewed from the side - but perfect when viewed at the 3/4 angle (where the smoothed normals are looking at you).

The one nice thing about Maya's envelope's are that they don't have to be the same model, shape, or anything. You can just throw a plane in between the character's legs and call it a day. You can edit the auto-created envelope (your pushed model), split edges to get around a tight crease, smooth the whole thing, whatever. Pretty handy.


Back to Eric's topic of vertex counts. UV splits, hard edges (smooth groups for you Maxians) inflate the vertex count. Material breaks & bones don't inflate the vertex count directly. Materials will cause a draw break, ie. even worse then adding extra verts. The renderer has to submit a new draw call, switch shaders, upload constants, etc. More draw calls per model = worse performance.

Adding more weights per vert kind of does the same thing (in our engine). A "chunk" of model can only have so many bones weighted to it, in total. This isn't as bad as a new draw call, as only the bone's matrices need to be uploaded, and can be streamed in with the vertex buffer streams. But it does add a small cost. The model gets broken down into mesh fragments, each using only a limited number of bones (I think ours splits at 40). A full human model can get split into 3 to 5 pieces if it's 1 whole model using 1 material. If it's already split into materials (shaders), sometimes only 1 or 2 of those needs to be split into a couple mesh primitives.

More bone weights per vert makes the problem above a little worse, as now there's a larger list of needed bones for each chunk of mesh, potentially making the chunks smaller (and greater in number). The vertex shader code also gets larger (an extra matrix mult and add per bone weight) and causes more data to be passed around per vert. 4 is usually enough per vert anyway - it's pretty rare to need more than that. The pipeline can auto reduce this as an optimization, and it's hard to spot the differnce. We tried limiting it to 3 bones in the pipe, and it was only a few spots that the person who weighted the mesh could even tell the difference. Pretty subtle.

Now, how I build my models. I usually do this:

1. Build proxy/cage/dummy model in Maya. Just a boxy thing with all quads, good layout for zBrush/Mudbox. Quick UVs, clean layout, no overlaps, good coverage. Helps if you want to extract displacements from other models to re-use, or for step 6.
2. Sculpt the shit out of it in Mudbox - get approval on this model from AD. Use lots of tricks like multiple meshes, floating bits, different rezzed sections, etc to make it manageable.
3. Bring the mid-rez version (usally anywhere from 50k to 300k - whatever hold all the detail I need to see) into Maya as a reference.
4. Build a new low poly model. Sometimes it starts from scratch, sometimes it start from a low level of the high rez model, and usually it's a combination of both. For a character (say an arm), I usally just create a cylinder, align it to the model, and shrink wrap it to the surface. Then I cut all my muscles in, add edges where I need them, cut all the folds & wrinkles in, etc. Optimize the inner areas (where silhouette doesn't matter), add any cuts I need for deformation, and stitch it all up. Really focus on the solhouette edges, and internal occlusion. Follow the surface as close as you can, I like to exaggerate the surface more than the high-rez (ie for wrinkles: deeper in the cracks, higher on the highs) to help with parallax and self-shadowing.
5. UV map - as few breaks as possible. Mirroring is OK depending on the engine/pipeline. I move all mirrored stuff over a unit in UV space to make the sampling easier.
6. Generate AO off the high-rez model. I sometimes do a few passes and blend as needed. Ie no floor, floor, arms up, arms down, etc. This help shape the model a bit. Place this as a colour map on your highest high-rez model. If no UVs, just autogenerate and bake a huge map.
7. Sample maps - grab normals and AO off the high rez.
8. Paint bump textures, Photoshop nVidia filter for fine details, overlay this normal map onto the sampled one. Paint other coulour maps, etc.
9. weight model, export, finish...

Sometimes I jump back and forth, ie I might paint a colour map between step 4-5, transfer that to the high-rez, to help place details on the high-rez model that align to a specific colour map.


(I can't believe PC still has the bug where if you take too long to write a response it gets lost - fucking hell I typed this up twice, excuse the typos but I'm tired!)

Great post whargoul. So it was in max that I'd seen the envelope feature.
Eh, yeah the lost message thing happened to me too, kind of discouraging eh?

I'm gonna get around to older stuff in the thread when I have the time kids

Whargoul, nice post. I like the sound of Maya's envelopes. Smart.

When PC tells me the post is invalid, usually the Back button gets me back to my text. Anyhow, I'm paranoid here, I always Ctrl-A Ctrl-C before hitting that Continue button.

hehe whargoul, I am trying to make (ctrl+a,ctrl+c) before posting big stuff a habit for that reason, or writing into notepad [img]/images/graemlins/wink.gif[/img] (like this one), but thx for retyping!

about the vertex-bone-assignments. As whargoul suggested limits like 2-4 make sense, because anything beyond normally is not visible. Sometimes this weight reduction can be done in code (find the most dominant weights, and evenly spread weight of too subtle ones), but in general to have a true wysiwyg experience you can check for the limits yourself.

now concerning rendering performance, there are many "ifs" and "whens" when it comes to rendering. Engines might do things different, the hardware generations often are different as well. Here is just some general statements

------
short
------
Get it good looking with the least possible counts, but don't let some fixed counts prevent it from looking good (artefacts...).
And dont forget consistency. If your game enviro is fairly low (but mostly complete) it makes no sense to put some hi-res characters in it, eventhough the renderer can afford it.

Skip to end, probably redundant info for many of you...

------
long
------

memory-costs
------------
obvious, the textures used cost "most" in average. That is more true for characters than with their unique textures, then environment which reuses stuff, but still texture data will typically be the biggest videoram eater.

vertexdata is the other. Typical vertex-sizes are around 32 bytes, sometimes a bit fatter, sometimes less when not much attributes (normals,colors,uv channels) are used. Also skinned models, typically require a bit more (boneidx + boneweight) for each vertex-bone pair. 4 bytes thats a uncompressed RGBA pixel (compressed you can typically divide texture costs by 4). So to give you a comparison of costs, a 1024x1024 texture compressed would weigh as much as about 10 000 unique triangles (that is every triangle has its own 3 vertices, which is very unlikely, only particles have similar uniqueness of vertices).
As hardware likes 32-byte aligned stuff, coders pack as much in as possible, sometimes sacrifice accuracy and so on, just to get everything needed in. Now say they found the "perfect setup" for all needed attributes, and then some artist comes saying he needs a second UV channel, which would mean say a size of 40 bytes instead of 32, and that is "almost as bad as 64", not to mention the fact that the shaders involved need to take this into account, as well... Normally they will make different versions of vertexformats, like light,medium,fat. And different shaders, but maybe they wont have the one you would like, and I just want to hint that something rather simple, might create an avalanche internally, and therefore cannot be done.
In an ideal world communcation and exchange about information between artists and coders about engine capabilities and setups, will result less problems.

This doesnt mean you are save off throwing around with vertexcounts, but it shows that textures are more evil. I think the one important thing about textures is keeping consistent texel-density. That is the size of a texel (pixel of a texture) in your world. A) it looks better B) it performs better especially when at the end it is similar to screen resolution. It makes no sense to have hi-res textures of characters that are tiny on your screen at the end, or if their vertex count matches pixels...
Be aware that to minimize drawcalls sometimes meshes are "dynamically" batched to bigger ones. Think of a "copying" a mesh but "not instancing" (only newer hardware can do that easily). Then of course the copying process is faster with smaller vertexcounts. And when not copied dynamically but statically, the static costs will be higher too. Think about level geometry, it makes no sense to instance every "box brush", but generate one giant triangle mesh out of all boxes. Characters normally dont fall in this category.

Who else eats videoram?
your framebuffer window, (color+depth, that is 64 bytes per pixel), then all those new cool post processing fx also tend to have "render-to-texture" so those rendertargets reside in vram, too (think floating point for HDR stuff you got 64 or 128 bytes per pixel for color alone). And of course shaders (which is somewhat negligable so).

state-changes
-------------

Graphic Cards are stream processors, ie they are super at doing "the same thing, very very often". They dont like it so much if you change "the task" often. Hence material/shader changes result into more drawcalls, as state cannot be changed during a drawcall, and less drawcalls is good.
However coming back to the statement that multi-materials and so on,require a new drawcall, that is not always the case. Think about all surfaces using the same "shader", that is say 1 texture + 1 lightmap. If you can manage to put the textures used into a bigger atlas, you can manage to render them all (same shader) with the same setup, and they will just pick their "subtexture" of the big atlas, hence requiring no new drawcall. Some engines might do this automatically (the atlas generation), some not. If not you can help packing multiple textures that are likely to be used with others in a bigger one. (Think trashcan + park bank + mailbox +...). This works easily for "non-tiling" textures, once tiling is involved as used in terrain (big walls..), this very often has to be handled on the codeside, as the tiling itself needs to be done in pixelshader, and not all might support/do that.

Shader changes are very costly changes. That is why we see not very different shaders (just with different tweak values) within a game. It is also a reason why "hey lets do my own .fx shader", do not always translate well, because they are too specific, and if there is too many "unique" ones, it isnt worth it. Also what makes it hard is that you need subversions of the same thing, like shadowed, skinned, both...
Other changes are like blending,alpha masking and so on.

vertex/pixel-operations
-----------------------
Before cards got a unified architecture (that is xbox360 & gf8/ati r600), there were dedicated units for vertex and pixel operations. This is still true for majority of hardware around, and basically means that if you "imbalance" operations, you can pump more time in the other. New cards share the same chips for all (pixel & vertex) operation, and do auto-load balancing.
For old, eg. you have a very complex pixel shader (normalmapping,subsurface...), then you could add more vertices for "free", as the pixel shader will slow things down. However if you have very simple pixel operations (think lightmap+texture), then vertex will cost a bit more.

Of course pixel costs directly relate to the pixels on screen, if your model is tiny, it shouldnt have too many vertices, as vertexcount would be too close to pixel count.
Be aware that vertex count is "all vertices" of the model, not only the visible! While pixel is only the visible (and even more if Anti-Aliasing is used)

What this means that say you have a bit more complex shader going, then very likely the pixel costs are much higher than vertex (because say you sample 4-5 textures in that shader, do lighting...), then adding a few vertices doesnt hurt. If that will get you a smoother surface (better bake result..) then dont think of polylimits as the ultimate law, but as a guideline.

Profiling (measuring speed of what takes how long) saves the day, good engines will offer you lots of data about "what the current frame costs", how many drawcalls, texture memory... Hence optimizing from a scene works fairly easy. The problem is you need the models/assets before to make that scene [img]/images/graemlins/wink.gif[/img]
Also think about following within production "oh that new cool shadowing technique came out and we want it". The shader changes and so on might shift the "vertex/pixel" balance before. Also different hardware generations will shift... That is why games will often see completely different codepaths depending on hardware capability. And especially shader versions. Now combine that with the "one shader for specific needs, like 1light,3lights,+skinned... and you will see that certain shaders explode to many more. And eventhough this is more true for "current/older" hardware, that is what the majority uses.


Both vertex and pixel operations have caches. Caches are needed, as graphics cards "never evaluate all vertices first, then all pixels", but each triangle on its own. The result of the vertex shader is interpolated linearly over the triangle (pixels within a triangle, get a mix of the 3 vertices' values) and passed to pixel shader.

Easiest to explain with a vertex. Say vertex A is part of 3 triangles, it would be very dumb to reevaluate the vertex with every new triangle. So cards will store results of like the last 32 vertices (or more/less depending on hardware). Coders normally resort polygon and vertex order of models to make best use of that (if not tell them to!!). However if we are passed that vertex cachesize, and come again with some triangle needing vertex A, we will have to reevaluate it fully again.

For Pixels there is such a cache for texture lookups. As fragments close to each other normally have similar UVs/mipmap and therefore similar texel.

end long
---------


---------
in context of normalmapping
---------

How complex is your game's normalmap shader, how many textures is it already "pulling from". Is you model residing "static" in memory, is it being "skinned by bones"... How big is the model typically on screen (ie how many pixels)... this somewhat influences how strict you have to look at vertexcounts.

When using tangent mapping, the "tangent space creation" is the key, if game's method doesnt match baker's, you are in trouble. Check with coders which tools they recommend for baking, how they create them... Even worse 3dsmax's viewport renderer version doesnt match the baker's (which is based on scanline renderer), so slight errors on extremas might occur in viewport, but not in renderer.

A "object normalmap"'s vertex shader is pretty simple, the "tangent" version, not, it needs to transform light vector to tangentspace, it needs normal/tangent (and sometimes binormal) as vertex attributes.

Texture compression might leave artefacts, make sure that you try your normalmaps without compression before, to avoid hunting "baking bugs" that are none.


As for texture pixel useage, Eric mentioned those special .dds textures, that come with differently colored mipmaps. Try substituting your "diffuse" with them, if you end up never seeing "toplevel", then you can resize your texture by a quarter...

PS: is that long-winded enough,Per [img]/images/graemlins/wink.gif[/img]

edit: I mixed up my vertex/texture weight comparison by factor 8

Very awesome thread here. Nice stuff Per, Whargoul, Crazybutcher - thanks! [img]/images/graemlins/smile.gif[/img]

I'll add in a little bit on object/world space normal maps, because most people seem to have incorrect information on this topic, i've wrote it before but i'll do it again for the sake of this thread.

Things you can do with object space maps:

1. Get perfect results regardless of the smoothing on your lowres mesh, amount of geometry you have, etc. Works great for making LOD's and reusing the same texture because the normals/binormals dont matter. And also is very good for mechanical hard surface objects, no need to split model into smoothing groups to get good results, or add tons of extra polygons(polys that you can then use to add even more detail to your awesomely rendered model)

2. You can animate meshes with object space normals, as long as the mesh is rigged and translated by the engine, and as long as the engine supports it. Definately not only for static props as some people will tell you.

Things you CANT do:

1. Mirror any parts of your mesh.
2. Rotate your model after generating in your 3d app, if this is done in your level editor/game engine, or just with animations on a rigged model its fine.
3. Add additional bump map detail. Combining these in photoshop can be a pain, because the normal map is using the full color range, not simply the blueish color....


If any of your programmers come and tell you you can't use these maps, they're just being lazy and refuse to take the 15 minutes it will take to add support for this stuff.

[ QUOTE ]
As for texture pixel useage, Eric mentioned those special .dds textures, that come with differently colored mipmaps. Try substituting your "diffuse" with them, if you end up never seeing "toplevel", then you can resize your texture by a quarter...

[/ QUOTE ]

And sometimes, you don't want the mipmaps -you only want the hires texture/1st mip level (main character who is never seen at a distance for example). In that case NOT creating the mip levels will save you both memory and disk space. I think it's around 30%

I'm on some random laptop in the middle of nowhere, just want to quickly suggest that it's important to describe what something is before detailing all the advantages of that something [img]/images/graemlins/smile.gif[/img]

world space normal maps bake the normals from the hipoly model directly, while tangent-local space normal maps bake the hipoly normal relative to the lowpoly normal, which means that the model can be freely animated without messing up the lighting.

To animate a worldspace normalmapped model you have to treat the onmodel normals differently. Iæm sure someone else can get into details here, but eq please stay sober and objective, if worldspace normal maps could save the world, nobody would bother with tangent maps. There are many things that CAN work, but aren't necessarily viable, well performing and scalable solutions

I think you're talking about object-space maps. World-space and object-space = same bitmap, different shaders.