Hia.So I just created a simple model and then went and did something really simple to it in Mudbox (my first time using Mudbox, you see)
So I created the bump map and imported the model into unity but it looks aweful… Please have a look at what it looks lke in Mudbox and what it looks like in unity and please tell me what I am doing wrong…
Much appreciated…
Whats the low poly mesh and uv map look like?
(I ask because I see some weird n-gon’s in the mudbox screenshots)
And also the normal is inverted (the “bumps” are caving in instead of bumping out) and will need to flip a channel.
I am uploading a scaled down version of the UV map. The original is 1024x1024.
I was also curious about the inverted bumping because you can clearly see that the normals are pointing in the right direction on the model in Maya…
My workflow is as such:
I’ve got a feeling it might be a smooth uv issue.
Try xNormal
Export the highest subdivision level mesh from mudbox as obj.
Export the low poly mesh from maya as obj.
Bring those two obj meshes into xNormal and bake out the normal map.
Thanks for the link, bru… but unfortunately that is Windows only 
Have you got any idea why the arms are so wrinkly when I didn’t do anything to the arms at all? Or the face for that matter…?
Quick fix might be to lower the resolution of your bumpmap from 2048 x 2048 or whatever down to 256 x 256… then you’d lose that annoying little details and only get the big creases you want.
It’s a cheat, but it might work… maybe…
Or… go into photoshop or similar program and blur your bumpmap.
That’s an interresting idea… I was aware that people modify the bump maps in editors but I was only aware of duplicating a layer to increase an affect and not about anything else. I was under the impression that each pixel, as determined by the color thereon, dictates the direction the light would reflect and to go and manually modify the file would just result in chaos…
So… making the bump map res 256 from 1024 might actually INCREASE the quality??? That is not something I would have thought off…
I tried playing around with the various settings in MudBox last night exporting in all possible combinations on world space, local space and tangent space closest to the model, closest to the outside of the model and closest to the inside of the model… The results all just got weird with seams becoming really pronounced. So far it seems that tangent space closest to the model works the best (which is what I showed in the picture). Modifying the bump level in the import settings in Unity also makes quite a difference but I still get a shadow instead of a bump… Perhaps if i invert the bump map image…
Question, when I import a bump map into unity, should it be a grayscale or whould it be the actual map? I was thinking that since I import a coloured bump map and then tell unity to “Generate bump map” from the already generated bump map might be causing the issue. If this is the case, will converting an RGB bumpmap into a grayscale image work or will that just break everything?
Basically what I would like to know is this:
Also, I am looking at Mudbox at the moment but with it crashing at every 3rd button I press I am considering switching over and evaluating zBrush 4 instead. Could anyone give me a quick, all round pros and cons comparison between Mudbox and zBrush, please?
Would the move be justifiable or is the error on my side and not with the software?
unity requires normalmaps (tangent space if I remember right but I’m sure the reference manual includes that on the docs of the normal map shaders) and they should be rainbow colored (grayscale are either bumpmaps which are something very old school or alternatively displacement maps, which are not supported in unity unless you have an own shader for it).
if you have grayscale, there is a little field in the texture import settings that allow you to generate normal maps from that you don’t compress them unless you are on unity 3 in which case you can use DXT5 aside of uncompressed.
reason is that normal maps normally don’t work well after compression as they are trashed. DXT5 in U3 is an exception cause if it detects it to be a normalmap it will resort to a special version of DXT5 (dxt5_nm) which compresses the normalmap but in a usable format.
From reading this post I have gathered that since my nm is rainbow colored I should NOT check the “build normal map” check box and I should change my image format to RGB 16 bit… I will give that a try. I think I did change my texture format before but I had the checkbox on…
Cheers for that
P.s. When I was first trying to incorporate normal maps into Torque I was looking all over the place and each time I found source that I could incorporate into the engine they kept taking about bump-shading so I have always been under the impression that bump-maps and normal-maps are both interchangeable terms meaning the exact same thing…
The way I saw it, it basically acts as if each pixel has it’s own “normal” and based on that light reflects differently off of the respective pixels thereby giving the illusion of depth through fancy shadows on the polygons… Displacement maps actually modify the displayed pixels’s position, this much I have gathered (although I haven’t read about wether this is supported in Unity 3 or not) but then, if normal maps and bump maps are not the same, what is the difference?
I thought that bump maps used 256 shades of grey to represent the 256 values stored in the RGB values of a normal map. Since only the “R” for example would be enough to contain same info as the greyscale I was never sure what values are stored in the “G” and “B” but never bothered to find out since, at the end of the day, normal maps and bump maps are the same thing… but if I am wrong then perhaps I will have to investigate this a little more…
thats not the best idea, leave it at least at 24bit RGB, optimally on 32bit as the alpha channel is used too for other shaders if I recall right
Gotcha, so keep the size small and the bit depth high…
Hey, Dreamora, am I missing something here?
This to me suggests that bump maps / normal maps need to be greyscale images and I need to let Unity convert them to rainbow or am I understanding this wrong?
… but then again…
you understand it wrong
unity can generate the normal map for you in case you have a heightmap (-> grayscale). but that might not lead to exactly the kind of data you wanted, its normally easier, better and more straight forward to just export the normal map from your modelling application where you created it.
chances though are that you didn’t create any normal map there but displaced vertices in which case you would get a displacement / bump map which requires the normal map generation in unity
When I found that last quote I basically realized what you just said, yes. Thing is, when I imported the normal map directly without turning on the “Generate bump map” check box I saw nothing on the model.
Turning on the check box gave me very visible difference but with all those artifacts. It also gave me the bumpiness value slider whereas otherwise I have nothing…
Would you say that what I should do is:
I really am at a loss here at why the normal map that looks so good in Mudbox simply doesn’t work in Unity. I know I am missing something but I am just clueless as to what…
Regarding the generated map, at least that is the one thing I AM certain about. I have the option of extracting a normal map and the option of extracting a displacement map, each under their own menu option so having selected the normal map extraction option I am definitely sure about TAHT part 
Normal mapping is one of the coolest things to ever hit game graphics. As an artist, you should definitely make yourself familiar with how they work. They are different and better than bump maps. Here’s a link to get you started:
http://www.3dtotal.com/team/Tutorials_3/normal_mapping/normal_mapping01.php
This is usually due to UV Mapping problems. I’m guessing you’re modifying your model after you’ve created the uv map. Try this just to rule this out:
Mudbox should generate more than decent Normal Maps. They rarely need tweaking in Photoshop (unlike the built-in Maya/ Max render element).
You should also try to learn Normal Mapping in smaller increments. Try to do the all too common “space-cube” first then move on to a spherical object, then a slightly more complex object and so on. I used to practice Normal mapping on vegetables :lol:
Cheers, bru. Will have a look at that.
Made some progress on that model of mine. Turns out changing the import format from Default to rgb 24bit solved virtually all errors. 32bit had other issues but from 16bit you can clearly start seeing artifacts…
So by turning off the Generate bump map check box and changing the image format … magical… Getting some really weird things happening at the seams though, but it is looking TONS better already
Seams cannot be fixed because they are seams.
You might need to not model those areas that overlap joins in the UV.
Looks like one of the channels (green?) needs to be flipped to work properly.
What I find gives the best results, is to avoid creating the actual normal maps themselves outside of Unity completely. Instead create a displacement map or regular bump map rather than a completed normal map, then convert it to normal map inside Unity after importing it.
It’ll create all the channels the right way around and ultimately gives nicer cleaner results, plus you can then fine tune the amount of bumpiness later through Unity without having to mess around baking and reimporting files. Something you’d not be able to do if it was already in normal map form to begin with.
I’ve also noticed this method also tends to fix a lot of problems with discontinuous seam errors that’ll often appear.
Read this it tells you in detail what is going on.
It claims that UV rotation is the real culprit here.
This could account for the generation inside Unity working.
http://www.cgarena.com/freestuff/tutorials/maya/varga/index9.html