Baking normal maps. A bug, or is it me?

Ok, so I ran into this problem with baking.
I Unwrap the low poly mesh, create a new Image for the UVs in the Image editor.
Select the Highres model, Shift select the lowres model, click bake. the render progress bar appears for a second.
Suddently the image Turns off to blank, like there is no image assigned to the UV and the progress bar shows an error “There is no Image to bake to”.

Did i forget some step in this?

Did you select ‘Selected to Active’ in the bake settings ?

Oh, that’s one step I forgot… Are there any situations where this checkbox wouldn’t be used in normal map baking anyway? If there is no, the checkbox shouldn’t be there. (just a thought).

But still, same thing happens, still drops the image off the UV and gives the error.
I also noticed, that if i go to edit mode and bounce out of edit mode on the low poly model, the image reappears assigned.


Oh, that’s one step I forgot… Are there any situations where this checkbox wouldn’t be used in normal map baking anyway? If there is no, the checkbox shouldn’t be there. (just a thought).

An interesting point, imo. “Selected to active” is self-explanatory, and gives different results in most cases (or a crash). However “tangent space” won’t give any result without two objects selected and “selected to active” marked. :confused:

Other than using the support forums?

Youu shouuld post a blend

And there are quite a few situations. Like diffuse>normal baking or combining all the normal, detail, bump maps, multiple UVs on a model into one.

I thought about that as soon as i clicked “Submit”, but it was to late. My apologies for that. :frowning:

There’s the blend:

What i want to bake is the Tangent normal map.

Have you saved the new image you created before baking?

You shouldn’t have to save the image first.

I tried appending the objects to a new blend and got the same results.

Then tried setting up my own scene and it worked fine.

So it’s got to be the objects themselves. Some setting not set right or something.

I had the same problem. I selected the same image in the UV editor with the low poly mesh selected first and in edit mode, then with the high poly mesh again. Sometimes it works, sometimes it doesn’t…
I think there is a bigger problem at play. The way of creating an image first, then rendering to it is not very intuitive, at least not for me. Why do I have to create an image first? With several images as textures, it often renders to a different image than the one currently selected in the UV editor. It would be more logical IMHO to set the size of the image in the baking window and let Blender create a new image, which can than be saved by the user.

I tottaly, agree with you, Shortlord.

How ever, instead of creating a new Image for every bake, usually you want to overwrite the last bake, so you don’t have to go out there and delete the previous pictures.

I did write this suggestion (for better baking workflow) in the GUI improvement Thread.

I just had a though - A little delete button next to every image for the image drop out menu…

The one thing that’s really necessary is that the image is assigned to the unwrapped mesh in the uv-editor-window. You don’t have to assign it to the object itself in the texture panel or anywhere else. You may, but it’s not necessary.
It always works then, at least for me. Like here:
You can then swich to object mode and continue with the normalmapbakingprocess, just make sure that you don’t accidentally change the mesh assigned to the image you want to bake to in the uv-editor when changing to edit mode again while having selected a different mesh or something like that.

I am trying to do that on blender 2.5
I never had any problems with 2.4 …

I had the same problem after getting a newer build, and the only way that I fixed it was to append the objects to a new scene and they stopped, which is different than Shatter’s outcome. It may just be a bug in the newer builds though. Blender went from crashing after every other bake to not applying or finding the UV to apply the bake to in some cases. In the new scene things went without crash or problems.

If someone’s successful with baking my normal map, please post it here, thank you =^.^=
Ill make a bug report in the mean time.

EDIT: It seems the bug report doesn’t appear in the bug tracker for some reason :confused:

Move the “hat high” mesh to a different layer.
Un check “restrict renderability” for “head high”.

Here’s your file fixed and ready to render.

Oh snaps!!
Thats where the solution is hiding! I was searching forever, can’t believe i missed that. I didn’t have to move the hat to another layer. It’s just the renderability button.
Thanks, pappy.
But I believe, this is still undesirable behavior and should be considered a bug, right?

Good question, and it goes straight to the heart of many Blender usability issues. Do we ask the developers to code in coverage for our lack of understanding of what makes a feature work?.. (in ALL the many possible variations) or do we work with the attitude that Blender is a tool that requires a thorough understanding of what is happening “behind the curtain” as it were. Which in my opinion is one sign of a “pro” application.

Personally, I’ve found that HAVING to understand what’s going on has made it possible for me to have confidence in my ability to get things done in Blender. I’ve had previous experience with an a different app. (Animation Master) which went to get lengths to hide most of the realities of working in 3d behind an “easy to use” interface. There anything that went wrong WAS a show stopper, with no understanding of how things worked beyond “click this / and set that… etc.”

So, to answer your question… if there were a developer free (who was interested) in setting up the many possible error conditions with some form of warning as to the error condition and how to resolve it, I guess I wouldn’t mind the help. But I generally would NOT want automatically assumed conditions to be set based on the users input. As an example of this look no further than the “no image to bake too” error message. In this case it’s totally misleading!

I’m sure a lot of people would disagree with my position, so you should keep this in the bug tracker as a usability issue.

Good documentation would/should make this a moot point.

Oh, I moved the hat as it was making the render very slow. Don’t know why I pointed it out as part of the fix.

Wait, if you click the ‘restrict renderability’ button and the render (or bake in this case) fails this is what you’re calling a bug?

The Error that it gives “No image found to bake to” is misleading and wrong and I take it as a bug, because the actual image is set correctly. The Error should be either changed to something more descriptive, or it should simply work, because there is no condition where you wouldn’t want it to work with normal maps.

I think, that one of the main goals of high quality software is that the user DOES NOT HAVE to know how it works behind the scenes, to work with it. This way you can concentrate on the art itself, without extra information. That’s a sign of good design imho. Pixologic (zbrush) are going by this logic and they always brag about it in their feature videos…

I see perfect software as Powerful, beautiful, easy, quick, and bugless. Blender has a long way to go to become perfect.