Page MenuHome

cyclesbakind-uvs
Closed, InvalidPublic

Description

System Information
Operating system and graphics card
osx 10.8.5
intel hd graphics 4000 512mb

Blender Version
Broken: 38a430c

Short description of error
baking to active image node doesn't respect the vector socket...

Exact steps for others to reproduce the error

add two uv sets to the default cube unwrap or project uvs differently on each
change render engine to cycles.

in uv /image editor create a new image.

in node editor create an image node and pick the new image

add a uv node set to first uv channel
connect output to input of image node

in mesh properties make sure the second channel is set to active
in node editor ensure the new image node is selected
use cycles bake in the render properties tab to bake to image

despite the first UV channel being connected to the node input socket the render uvs of the second uv channel (which have the render icon in the mesh properties) are used for the bake.

this may be "correct" but is the opposite of expected behaviour for teh node editor so I'm filing this bug report..

Details

Type
Bug

Event Timeline

michael williamson (michaelw) raised the priority of this task from to Needs Triage by Developer.
michael williamson (michaelw) updated the task description. (Show Details)

You should add a blend file
Anyway, I confirm this.
It doesn't make any sense.
This"temporary" UI solution goes more and more inconsistent.

test file


@michael williamson (michaelw): it helps us when you upload such a test file right away when you can, just drag it onto the comment/bug report window.

About the bug: this might be a bit cumbersome, but it's not a bug. Nodes are a lot more ambiguous than the classic buttons in properties panels, so it's usually better to use those properties for the active element in a list, rather than the active node (which can be a lot harder to find).

I would rather like to see the Bake operator/panel moved closer to the UV maps buttons (mesh properties tab). It may be a render feature technically, but in terms of data it is very closely connected to the UV maps, unlike the rest of the render buttons which don't relate to any specific piece of scene/object data.

In addition to that it could be a nice usability feature to add this operator also to the node properties for UV Map nodes. This should be in the extended sidebar buttons rather than on the node itself. That way you can use baking directly from the node editor too without having to leave context.

Lukas Toenne (lukastoenne) lowered the priority of this task from Needs Triage by Developer to Normal.

Quite! why use the active node at all? it seems a little redundant...

the ui problem is thorny though... being a combination of object, mesh, uv and material stuff... and of course render settings...

wouldn't it make sense for the bake to just generate an image and to have a picker so the user can choose which uv set to use and a filepath? why create an empty image first? why the node shenanigans?

if it's worth anything, I'd agree, just make a dropdown for at least the UV map selection- its too ambiguous working with active uv maps, and selected nodes.

In addition to that it could be a nice usability feature to add this operator also to the node properties for UV Map nodes. This should be in the extended sidebar buttons rather than on the node itself. That way you can use baking directly from the node editor too without having to leave context.

@Lukas Toenne (lukastoenne) That doesn't make much sense as it is, since bake at the moment is per object, and more than one object can have the same UV Map node.

@Dalai Felinto (dfelinto): Ah yes, i didn't consider that. It should then use the active object, which admittedly is another implicit external context access, but imho more transparent than using the active uv map slot. Was just a suggestion anyway, it's not so crucial.

As stated by @Lukas Toenne (lukastoenne) this is not a but. closing the report. UI design discussions can be done elsewhere.
If this is to be considered as a wrong behaviour it should be filed for the projection painting and viewport as well, since they all follow the same design.