Page MenuHome

Baking ray distance do not work.
Open, Confirmed, MediumPublic


System Information
Operating system: win7x64

Blender Version
Broken: 2.80 (sub 47), a0f2923fd821, 2019-03-08 21:52
2.79 main too

Short description of error
Baking emissive from object causes strange additional lines.

With cage it becomes even worse

Exact steps for others to reproduce the error
Here the file. Try to bake Emissive from Donor to Recipient with Cage or without



Event Timeline

Vyacheslav (hitrpr) added a comment.EditedMar 10 2019, 5:45 PM

Ok. It seems, that ray distance do not work for backface and inside of mesh. So cap and border baked on the bottom. And side was baked on the top:

Here the file with success baking

And i forced to put cage inside recipient.
Should it work this way?
Why ray distance do not work at all?

Vyacheslav (hitrpr) renamed this task from Baking artefacts object to object to Baking ray distance do not work..Mar 10 2019, 6:04 PM
Vyacheslav (hitrpr) added a comment.EditedMar 10 2019, 8:06 PM

As I found it works now back way: rays shooting from selected to active and hits inner cage.
Ray distance is not working at all.
Ofcourse cage extrusion is not working with backray: it extrudes only outside as it should.

Sebastian Parborg (zeddb) triaged this task as Confirmed, Medium priority.

I can confirm that ray distance doesn't seem to work.
No matter what distance the bottom face of the active object will hit the top of the bake object even though the rays should be able to reach.

At least that is what I think should happen by reading the manual:

@Sebastian Parborg (zeddb), I felt that is something wrong before manual. Then I read it. And it is still not working as in manual or as expected(intuitive way).

There should be a rewriting of the manual concerning "ray distance", because it's not clear what the difference is between "ray distance"("cage" not checked) and "cage extrusion" ("cage" checked):

Could it have to do with split vertex normals as explained generally here (left image):

This could be the case since the blender manual (
writes for "cage extrusion":

"The inward rays are casted from a version of the active object with disabled Edge Split Modifiers."

Then, "ray distance" would automatically create a cage object but without removing any Edge Split Modifier like "cage extrusion" does?

NOTE: I've tested it and didn't find the Edge Split Modifier beeing removed with Cage Extrusion active (Blender 2.8 Beta). Marking edges as sharp always affects Cage extrusion (even without Edge Split Modifier)

According to Blender's source code in (blender-git\blender\intern\cycles\blender\addon), lines 1866 to 1871,
"ray distance" also is some kind of cage extrusion:

col.prop(cbk, "use_cage", text="Cage")

if cbk.use_cage:
    col.prop(cbk, "cage_extrusion", text="Extrusion")
    col.prop(cbk, "cage_object", text="Cage Object")
    col.prop(cbk, "cage_extrusion", text="Ray Distance")

If I understand it right, the manually created cage object replaces the cage object created automatically "extrusion", since the Blender manual writes:

"Object to use as cage instead of calculating the cage from the active object with the Cage Extrusion."

Member cgCody on blenderartist (link above) sees "extrusion" as on offset to the manually created cage object.

If "ray distance" and cage "extrusion" aren't the same, is there an example to illustrate this?

Vyacheslav (hitrpr) added a comment.EditedMay 17 2019, 4:15 AM

Thanks for explanation, but in this specific case only cage/extrusion fail, because there is no ray-limit.
As I can understand, it should work like this:

Purple is size of manual cage or extrusion. Black is object with semitransparent parts (baking source) and length of cyan ray will prevent backside baking.

Also there should be such image in the manual. It will work much better than hundred words. And I can do nice scheme, if you need.

Vyacheslav (hitrpr) added a comment.EditedJul 10 2019, 1:47 AM

I hope, it will be fixed for release at least :(

Bear with me: I promise, this is relevant.

TL,DR: The "Ray Distance" setting in Cycles for texture baking, that seems to have replaced the "Distance" setting in Blender Internal, does not do the same thing. If it's supposed to do the same thing, it's broken and should be fixed; if it's supposed to do something different, then the old "Distance" setting should be brought back in some form.

There are two ways to bake textures onto an object. The usual way, the default way in Blender, is to ignore the other objects in the scene and just render, for example, the lighting, shadows, and/or textures that are visible on the active object. This method is best for capturing detailed, expensive lighting and effects by rendering them once as a texture, instead of every frame; baking a full render of an object's shading to save time rendering animations or game assets, or isolating certain effects to tweak them without affecting all of the others.

The alternative way, enabled by clicking the "Selected to Active" checkbox (Render settings -> Bake panel), renders all other selected objects onto the active object's surface. This method is best for transferring textures from one object to another; baking high-poly detail onto a low-poly mesh, or baking decals or stencils onto a model. That last application is the one that makes this bug most obvious.

Using Blender 2.79b and Blender Internal, if I set up a model to receive a baked texture, along with one or more "decal" objects to generate textures from, I will get the following results by default:

Obviously no good, but I can easily clean these results up by changing the "Distance" setting (also in Render settings -> Bake panel). By default it's 0.0, which is treated as infinity. If I make it a much smaller number (0.01 for the airplane, 0.02 for the head), I get this instead:

Much better. The stars and stripes appear (mostly) where they're supposed to on the airplane, and the eyes, brows and lips no longer show on the back of the head model. However, when I bake the same objects in Cycles:

Somehow the airplane actually looks worse than it did in Blender Internal. The head model looks okay at first*, as long as you don't look too closely at the hairline, which shows some improper baking. But if I pull the hair portion of the mesh away from the main head:

the face that was on the back of the head is still there, it's just hiding on the inside now!

When I look for the "Distance" setting in the bake panel, all I see is a "Ray Distance" setting. I'm not sure whether that's supposed to be the same thing or not, but it doesn't seem to do anything in this case. I get exactly the same baked result whether "Ray Distance" is set to 0.0, 0.01, 0.02, or anything else I've tried. And it doesn't matter whether I use Blender 2.79b or the 2.80 release candidate, I get the same result in Cycles regardless.

It looks like I may need to report a separate bug, too. I noticed it when I was looking at the way the eyes differ on the head model when baked from Cycles vs. Blender Internal: See how the Internal version, the iris butts up right against the top of the sclera, but in the Cycles version, there's a little line of brown where the iris is almost hanging off of the top of the sclera like a pendulum? When I mess with the margin: becomes obvious that Cycles is actually rendering a margin around my source decal objects, instead of around the UV islands in the target object, the way Blender Internal does:

...but that's a separate bug, probably related to the way that Cycles omits the active object from the bake when "Selected to Active" is enabled. If no one else beats me to it, I'll report that one too, when I have some time. But anyway...

I'm attaching six versions of my .blend file, but you probably won't need them all to confirm the bug; there are files with "Distance" or "Ray Distance" set to 0.0, and set to 0.01 or 0.02 ("No Distance" or "Small Distance"); there are files for Blender Internal or Cycles; and there are files for 2.7x and for 2.8x.

*I do realize that the harsh shadows on the head model in these images is a result of my UV map, not necessarily a Cycles render bug. I used "Smart UV Project" to quickly get a map for baking. If this were a production model, I'd unwrap it by hand, which would probably eliminate those artifacts.

.blend files:

EDIT: Someone else did beat me to the other bug report: