I can not do the normal baking in the blender
here is the .blender file upload
blusa.blend (598.6 KB)
I can not do the normal baking in the blender
What you’re doing makes no sense. What’s the point of this?
Yes I’m confused as well, there’s nothing to bake really. No details or anything.
Guys, if you would stop marveling at the ridiculousness of trying to bake a cylinder onto a man, and noticed there is something very fishy going on with the Ray Distance setting, maybe we can help him, or at least file a bug.
Here’s a file that shows the weird behavior on a less ridiculous example:
ray distance error.blend (542.4 KB)
Only with a ray distance of 1 or 0 should the whole sphere be baked. On any other setting only part of it should get baked because the ray distance should limit the ray length.
I haven’t been baking anything in Blender for a long time now, but this used to work correctly.
(Unless of course I haven’t baked in Blender for so long I somehow forgot how this works)
wanted it seems as simple as possible I updated the image and the upload, now can either help or not?
Wouldn’t any ray distance cause the same thing, as the mesh is intersecting?
You’re right. I did forget how this worked.
Blender is functioning correctly. Those aren’t errors @andre111, that’s just the huge margin setting you picked. When you’re doing a partial bake like this, set it to 0. Also get some bevels on those squares and whatnot, or they just won’t show. And remember to bake at higher resolution than you need since Cycles doesn’t do antialiasing for baking.
That said, you’ll still get the bakes of your floaters on the back of the clothing because inward casts appear to be infinite. Ray distance is just an offset for the starting point. You could get this to bake correctly in the old Blender Render, because unlike Cycles, it has a bias setting.
Forgive my ignorance. Why would you want or need to bake a normal map in Cycles anyway? I can’t think of an advantage. Other than the up setting of the map I can’t think of a reason. And even that can be adjusted later.
Cycles actually lacks very little to make it a competent baker. Antialiasing, displacement, bias, a better UI and you’ve got yourself something that can give xnormal a run for its money. It’s a pity the feature was abandoned half-baked (if you forgive the pun).
But you’re right, I just use Substance for baking these days.
Cool. Actually we just use Blender internal for baking. I don’t normally mix texturing and rendering. Two completely different processes. So it never occurs to me to bake in cycles unless I want to bake lighting. For normal maps it is way better than Xnormal or even other apps we have tried. So I was asking about cycles over BI.
Oh. Well, one reason to bake in Cycles over BI is that BI is gone now
But seriously, outside edge cases like this one, there’s just no downside to baking in Cycles, so why not. Texture painting is also better in Cycles if you’re using an addon like BPainter and don’t have Substance (though BPainter still needs porting to 2.8).
Well if that is the case then there are more reasons than not to just bake in BI. And hopefully EeVee will keep this advantage. As I said, I never mix baking with rendering or even painting (unless of course using Substance). There are also more times I have to point to my artist who is having and issue with baking that they forgot to switch back to BI. There are a number of very small differences in baking features. I can’t think of all of them right now. But some things are available only in BI and completely missing in Cycles. I think of the baking process as a very specialized process in the pipeline completely separate from anything else. And not only that we rarely if ever use the same mesh for baking that we use to export to Substance, and again an entirely different mesh configuration used for setting up materials in Cycles. And also again, if that mesh is also to be rigged it will get special treatment to account for that. In short. I think it is best to think of all of these process as separate and don’t mix them. I think this is where most of the problems happen. People try to keep the same mesh all the way through. Quite simply this is not necessary. Nor is it necessary to bake in Cycles if you are rendering in Cycles or even if you are texturing using some parts of Cycles. Baking is just baking. It has a specialized purpose. If there is some feature you need from Cycles for this, then, yes. Use Cycles. But if not, you don’t need to. And the question and issue, asked here, is reason enough. It is actually creating the problem. The simple answer is use BI. Done.
For me, just take this for what it is worth. I can’t count the number of hours I use up debugging pipelines. Once something is working, I have a tendency to stick with it. One small issue that might be causing lost time sorting out, I will simply go back to the last thing that was working when it becomes apparent that that new change was causing more problems than it solved. So it is a constant balancing act. And of course I am always open to insight from others where I might have missed something. Which is why I asked.
Yeah, using the same mesh for baking out normals is just pointless and bothersome, you’re preaching to the choir here.
That said, I don’t think there’s any current plans to implement baking in Eevee (because Cycles can do it), so I suggest you start lobbying with the devs to fix up Cycles baking if you ever intend to switch to 2.8.
The .blend file format is changing because of collections and such, so going back and forth between versions might cause you some grief.
lol… well. Good point… though likely we will just keep baking in 2.79 BI in the mean time.
This error does not happen only with an object, so where can I report this bang of blender 2.79
Bugs are normally filed at developer.blender.org. However, there will be no more releases of Blender 2.79, and 2.8 doesn’t accept bug reports yet. As suggested, just use BI to bake this.
Also, this is not a bug, it’s just how it operates.
Right. More like a feature request, as @Piotr_Adamowicz, suggested.