Agreed metalliandy not a bug
Polycount has some good info
http://wiki.polycount.com/wiki/Normal_Map_Modeling
2 Likes
I figured it was so, but it’s the first time I use Blender to build normal maps, so I thought it was a problem @metalliandy , in fact we are no longer in 2000 with the construction of the low poly models 
I always have in mind when with 3dsMax I counted up to a maximum of 2000 triangles … I was left with this defect !!
Thanks for reply
1 Like
@Richard_Culver So, any proof for your claims? This problem doesn’t exist in Maya? I’d be very interested to see some examples that back up that claim…
Yes @Michael_Knubben, even in 3dsmax the result is the same, few polygons, not straight lines!
1 Like
Seeing that makes me immediately suspect your mesh, your unwrap or something in your process. Or even more of a Blender gremlin. Someimes Blender will just corrupt things. It happens. But the chances of this being an issue with normal mapping in general is not very probable. That you see it exactly the same in Max tells me it might be an issue with your mesh.
I would say start over and do some simple testing in Blender with a fresh scene and also newly created objects.
When you said higher resolution solved your problem I just recognized a similar artifact with the issue I described. I have seen it countless times. And it is a real issue. But usually with objects much longer.
We should stay focused on the problem. I am not trying to make an issue about Maya. Sorry but yes you will have to trust that i have seen the issue I have described. It is real. And provable. But it won’t solve this issue.
I invite you to try and first replicate this issue in Blender that you see there in the screen shots in this thread. If you can and can get artifacts from a properly unwrapped mesh using a low poly target mesh not subdivided vertically then we have a starting place. But I can’t replicate it.
If on your own you want to test what I am talking about, create a rectangular mesh about 1 to 8 something like that. Unwrap it with no subdivisions and try to bake some straight lines that go perpendicular to the long side. The lines will distort. And it has nothing to do with normal maps. You can get the same with any other bake.
Once you see that. Then subdivide it and bake again. The same unsubsivided mesh will bake with no distortion in Maya. And look like the one you had to subdivide in Blender.
It is just a little fact to know. And It has something to do with how Blender calculates it. I don’t know why really.
If you are using Blender and doing a lot of unwrapping and baking you need to know this.
It just so happens it is not the case baking in Maya. More of an asside. And maybe the new improvements to uvs will solve it.
As I mentioned above this isn’t a Blender specific issue or indeed a problem with the UVs, but rather a general limitation in regards to how ray projection works and how the number of sides in the meshes shown inaccurately represents the curvature of the high poly surface. You get the same result in Blender, Knald, xNormal, Substance or Toolbag when using a cage to bake.
I don’t use Max or Maya, but I suppose it’s possible that there is a way to control the ray direction along with the distance somehow. I vaguely remember max being able to control this by elongating the cage across the longest axis of the low poly, but that still wouldn’t mean that Blender has a bug.
Also, it’s rather inefficient to use custom cages in this manner and it’s something that I always recommend people do not do. With a properly constructed low poly mesh it should be possible to get a perfect bake using a simple push value on the cage without the need to do such specific adjustments simply by predicting where issues would happen and creating/modifying the geometry accordingly so the problems never happen in the first place.
There is no need to make very low poly meshes these days as geometry is pretty much a solved issue on everything but mobile when it comes to realtime and has been for a while (I remember Kevin Johnstone stating that removing 2m tris from a level only gained a few frame back in 2007 or so). The real bottleneck is now textures and shader complexity & as long as people are not wasting geometry (redundant geometry on flat areas or modelling in details that a normal map will handle) we are pretty much free to use whatever is needed to accurately represent the high poly surface in low poly form.
People really need to stop worrying about trying to make everything super low poly as for the most part it is a false economy. The time we spend over-optimising meshes for such little gain could be much better spent on other assets or tasks. 
3 Likes
This couldn’t be more true. The other part of this post is also on spot. The model is simply too low-poly. Make it more rounded and you get rid of the wavy lines. Not Blender’s fault at all.
Don’t be afraid to use more polygons. Especially if your model (in this case a barrel) is quite large in real live. Engines like Unreal Engine 4 can automatically create LOD’s of the model, or Blender’s decimate modifier. You can always go down in polycount, but not the other way around.
1 Like
Well let me reiterate. The issue I am talking about may not even be the issue that was encountered in this thread. It is real. Not about normals. And it is Blender only!
So I probably misspoke and sidetracked this thread into oblivion.
Regarding polygons. I will have to respectfully disagree. Currently, presently, 2018, I deal with real clients, who give me real issues I have to solve with polygons for real time and simulation which is a huge industry for those of us who make a living not in the AAA games industry. And I would say that is most of us here.
So do polygons matter? Hell yes they do!
I can give many real examples.Ever see a cockpit with all of those knobs? Hundreds. You subdivide one, they all get it. That is your issue multiplied hundreds of times. And it adds up.
I am currently in talks right now with a current client. This week, as we speak, about reducing polygon counts. Millions of polys? Not going to happen. Not even close.
Another client this year we did a huge stadium. He could not even include the thousands of seats where we mapped images onto a single polygon. Because in his business, in the real world, to the costumers he sells to, he has to take into account the lowest graphics cards and plan accordingly or people will complain about performance. And even then, he offers 3 tiers of performance/detail (polygon count) people can choose based on their graphics cards.
And even with the above said, there is draw time for objects. Unity has mesh combining and there are plugins to manage massive amounts of polygon and object data. It is still in 2018 a real issue for games.
Again these issues multiply exponentially when you get into real situations and you are not just making a few objects.
Also for the scores and scores of knobs (high details baked into s cylinder) we have made over the last 4 years I have never seen the issue posted here by the OP. Never. They are all clean. Done in Blender, unwrapped, baked in Blender.
This cockpit model on the first part of this reel shows what I am talking about:
For the record I kept that version for my reel. After this, I had to go in and reduce the polygon count by over 50% for the client.
Every client gives me a target polygon count. And it is never above 100K
That is just my game work.
For VFX this is another issue entirely. Again, you make one or two props, you are not dealing with any issues. You want to render a scene with scores and scores of objects you have to find a way to use instances. Polygon count eats up RAM very quickly. And Blender sucks at high poly counts.
So I hate to but heads with anyone here. But I just have to tell you flat out. About polygon, counts, it may not be as bad as 10 years ago. But it is still very much an issue. Very much an issue. This is a real, hands on report. I am not giving you this second hand. This is not theory or opinion.
2 Likes
Now I’m lost in the maze of hypotheses hahahahah 
.
I imagine however that slightly increasing the polygons you can have good results of normal map. I have worked hard to find a solution, and I think it is the right solution. Now, there is a little bit of truth in everything that has been said so far, so we should look into it with practical examples. Maya how work?
@CoconutStarDust , the Barel is perfect for the example, but the object that I have to build are others, so I have to understand how to move to make the best of everything 
Anyway, very interesting discussion
1 Like
Of course you should not go completely over board with the polycount. Especially if you have hundreds of the same object on screen, at the same time.
But the real bottleneck are usually complex per-Pixel shader, Screen FX and lighting. And thanks to automated LOD generation, you can greatly reduce the polycount in the engine.
It also depends on the purpose of the model. Hero props that are close to the viewer usually have a higher polycount, than background stuff. FPS weapons for example.
And Hero characters in Videogames exceed easily 100k These days. Or cars for modern racing games.
And this is really not a Blender specific issue. @metalliandy already explained that really well. That barrel is simply not round enough and lacks support loops.
I highly suggest this thread. It explains the issue in detail.
3 Likes
@Richard_Culver I thought some context here would probably be beneficial.
I’m not stating that we have unlimited vertex budgets or that people can make 100 sided cylinders for objects that are a few pixels wide on screen, but rather that people are no longer as constrained with vertex counts as they were in the past 3 generations of consumer hardware. We are all mostly running the same game engines these days no matter if we are in AAA or indie dev with Unity and UE being very similar in terms of visuals and performance.
No one is suggesting that we create a cockpit with millions of triangles and expect it to run efficiently. 100k tris is a large amount and is about inline with what is reasonable today. Kevin was talking about an entire level at the time.
What I’m trying to say is that we no longer have to aggressively reduce the number of sides on a cylinder so much that it massively impacts the quality of the object. 12 sides for an oil barrel that in the real world is a little over half a meter wide is aggressively low. 24 sides is not. 24 sides for a knob that is 15-20mm wide and replicated 100 times is probably a little unrealistic and 12 or so sides for the same knobs is probably more inline with what I would expect depending on how the scene is framed by the camera. It all depends on the target platform and the specification of the game. Optimisation is not the issue here…over-optimisation is.
Also, lets remember that much of the time there is no point in optimizing below 800-1000 triangles per object because anything below that and the draw call for the object is then the bottleneck. This is a little bit of an oversimplification but essentially this means that if you are not batching objects together and you draw a single object, the idle time on the GPU is identical to the time it would have taken to draw 800-1000 triangles, so you might as well use the GPU and render 800-1000 triangles. If you have multiple objects that are below 800-1000 triangles then batch them together so you do not have idle time on the GPU (two 400-500 triangle objects would render faster together as a single object than individually).
In the end, no matter what kind of game we are making the fact remains that hardware is exponentially more powerful and more efficient that previous generations and GPUs can push a vastly more geometry in realtime and by now everyone should be running DX12 level hardware. If anyone is running 8yr old hardware on current gen games they cannot reasonably expect to have good performance. Consoles are also a fixed entity and specific optimisations can be made to improve performance over time as developers become more familiar with their platforms (ofc, this is why console games always reach a peak in terms of visual fidelity during the last few years of their life).
Anywho, I would love to see some example of cylindrical objects where the waviness issue does not arise if you have any that you can show. It will probably be possible to tell exactly tell what is happening and why the problem doesn’t occur, or how it is hidden, if I can see the meshes.
1 Like
Here is a good bake on a lowpoly barrel using 12 sides for the roundness like OP did.
The trick to get this is to use a cage which is wider than the barrel but not much taller.
If the cage or envelope is taller the projection is wrongly aligned vertically and this bends everything.
But here is the thing: the resulting normal map looks exactly like it would look if i just paint these horizontal lines in with Substance painter for example or do it strictly in photoshop or gimp using an height to normal filter.
So it makes absolutely no sense to bake such an simple object from a high poly. You can just paint it on the actual model, sidestepping the High to Low baking completely.
1 Like
Actually you’re right, but quickly build a barrel full of detail to use it in game, the construction of normal with a baking is the best thing, at least I imagine…or am I wrong?
Anyway, thanks for your test, we discovered something very important
Lol… Well looks like we covered it all then. Tag team!
Thanks for your posts and contibution. I don’t really have more to add.
My initial point is moot since this is not what is happening here.
1 Like
Looks great! The only issue with it is that it’s rather impractical to do this on every cylindrical object.
As I mentioned above, I recommend that people do not make custom cages as there should be no need with a properly constructed low poly with more sides as we are only talking a negligible difference in triangles, so it shouldn’t even be an issue in the first place. In the time it would take to modify the cage so that it projects more uniformly you can already get a respectable result with the added bonus of being able to just hand over the asset to other workers in your team (or indeed a client) where they can rebake in any software without having to use your specific cage. Again, anything less than 800-1000 tris isn’t even really worth bothering about in isolation and we are only talking a difference of 48 tris in this instance (although, I’m aware that you only used the 12 sides to make your point).
You also have the problem of trying to get maps that are not generally supported via height to normal, such as bent normals, position, transmission etc. if they are needed. It’s a lot of extra work than just adding a decent number of sides in the first place.
2 Likes
I am totally getting your points here. And they make sense depending on your pipeline. But with the projects I work on we get a much more efficient workflow by never using the same mesh for baking or for export. So the mesh I deliver to Unity or client to use in Unity is not at all the same as any of the two or three versions we use for various baking processes. It solves more issues than it creates. And saves time overall. I think it was in another thread I went into the various configurations for AO baking. If I had a situation where a client needed to do baking I would recommend the same workflow and provide meshes accordingly. I have had to do this on occasion in the past.
It is not at all uncommon for us to create a completely differently subdivided and smooth version of the mesh to receive a map. At the end of the pipeline all that matters is that the map matches the output mesh and provides the desired polygon count. It is easy to have two meshes of different resolution and maintain the same UV for baking.
So I am just providing the balanced data from my experience.
I find that more often I have to think and work in a non-linear way to get a result. It also helps with parallel development. I find a lot of artists get tripped up trying to think linear. For example, how to export a mesh for Substance that has to also work for rigging. The answer is you don’t.
1 Like