Best way to optimise UV space for a cylindrical object

Cint128

Hi guys, I'm creating a light for model I'm working on and was wondering the best way to optimise UV space to get the most texture space for my model. In the image bellow I have done two unwraps of the ways I can think of to unwrap the model. Obviously Number two is more efficient due to it being overlapped but will that cause issues when I try and bake the normal and diffuse maps from the high polygon model?

What do you think is best or is there a better way to do it?

Thanks for you help

ZacD

Make sure you are paying attention to pixel density, throw a check board texture on each model.

More UV splits are going to increase your tri count, just remember that.

You shouldn't put 2 seperate uv islands right next to each other like you are doing with the side pieces on the bottom left side of your UV maps.

The sharp 90 degree angle wont bake to a normal map well with that few edges around the cylinder, read the Understanding averaged normals and ray projection/Who put waviness in my normal map? thread

MM

use a non-square texture to make the most use of UV space.

passerby

or just pack other thigns in the texture, a whole texture for a little light is kinda overkill

Cint128

Thanks for the advice everyone! MM good point about using a non square texture anything I have to worry about with a different ratio? Passerby, yep I agree and will probably put it into the train texture map when I have done that but for now just working out the best way to do it by itself.

ZacD thanks for the quick respoce with great information, that thread is really great, here a link if anyone hasnt read it.
http://www.polycount.com/forum/showthread.php?t=81154&highlight=Understanding+averaged+normals+ray+projection%2FWho+put+waviness+normal+map

I just have a few questions if thats ok...

1. When you say more UV splits are going to increase my try count what do you mean? How does having UV seams make the number of tri's go up?

2. In UVW map 1. you mean the two sections are too close together and should be moved apart a little?

3. by the sounds of it you think Map 1 is better but I need to make my low Poly model a bit higher res?

ZacD

1. UV splits mean there was to be a vert at that vertex for each UV island, so if a vert is a corner in 3 or 4 UV islands, it will be duplicated 3 or 4 times, it will only count as another vert in a game engine, but probably not show up as an extra vert in your 3d modeling package.

2. Do you see the bottom left where there is a horizontal green line? that line shows a UV split and should be separated.

3. I would probably use 1 but mirror the sides.

EarthQuake

If you remove the little ridge that you've modeled in at the bottom, you'l be able to increase the number of sides to say 16, still use less polygons and use significantly less verts (hard edges/smoothing splits means a lot of vertex use), get a better bake a nicer looking end result.

That ridge is so small that it likely wouldn't be noticeable in game anyway.

Cint128

Thanks for all your help guys.

So after trying to listen to everyones advice this is what I ended up with




I increased the number of sides and got rid of the hard edges as much as possible to reduce uv brakes and made it all one smoothing group.

Then I folded the sides and the top over itself so that it was symmetrical to reduce space. Not sure if that's ok to do or not but seemed to work ok.

The far right of the image shows the model in unity with normal and a AO diffuse map.

Any other suggestions?

marks

ZacD wrote: »

More UV splits are going to increase your tri count, just remember that.

Not true - increases vertex count NOT tris, two very different things.

Sinking

marks wrote: »

Not true - increases vertex count NOT tris, two very different things.

Right, I've heard that before, but does a higher vertex count in the UVs actually have a big issue on performance? I've always been wondering about that.

Xenobond

Here's what I'd suggest-

At 33 verts, I'd even go back and add more segments to the cylider (versus your first attempt having ~60 verts).

Cint128

Ok I did a test using your method Xenobond (nice name/dp btw haha) but with a couple more segments. I think the form is defiantly better but it does bump up the tris a bit. The first version I did (one in the middle) also had the wavy normal's problem so I added a loop in the next version (far right) one but this bumps up the tris and verts again.



Like Sinking said I would be interested to know how much a different tris vs vertex performance makes.

There was also the problem with the top of the models having seams which I didnt know how to fix?

ZacD

Yeah Xenobond's solution is going to have wavy issues unless you add an extra split, or paint it out or use handplane hacks.

Sinking

Cint128 wrote: »

Ok I did a test using your method Xenobond (nice name/dp btw haha) but with a couple more segments. I think the form is defiantly better but it does bump up the tris a bit. The first version I did (one in the middle) also had the wavy normal's problem so I added a loop in the next version (far right) one but this bumps up the tris and verts again.



Like Sinking said I would be interested to know how much a different tris vs vertex performance makes.

There was also the problem with the top of the models having seams which I didnt know how to fix?

Was it the problem where the normals on one side of the model point one way and another way on the other side of the model (this causes a harsh line of separation). This often happens on curved surfaces and the only way to prevent it is to make a cut through the nearest plane, instead of the edge. This may mean you have to add extra subdivision on that poly, though. But don't worry too much about polycount. As long as you can save on the materials and optimise those, the engine can deal with some more polys. In UDK it is said that anything up to 300 polygons isn't even causing the engine to slow down at all. And with round shapes you want the silhouette to be clear. so you need that subd.

Eric Chadwick

Too much optimization (do polygon counts really matter?)
+
http://wiki.polycount.net/PolygonCount