Cycles node editor, nodes position not maintained after Material panel changes #44921

New Issue

David Black · 2015-06-02T04:28:38+02:00

David Black commented

2015-06-02 04:28:38 +02:00

System Information
Linux Mint 17.1 Cinnamon x64
Windows 7 x64
Intel HD 3000
NVIDIA GTX 580m

Blender Version
Broken: Official 2.74 (Hash 000dfc0)
Worked: None that I know of

Short description of error
Node Editor - Material panel:
While nodes are changed in the Material panel, their previous node editor position is ignored, nodes jump to a new position next to a connected mix node; furthermore, while replacing more than one node connected to a mix node, both nodes jump to exactly the same position (on top of each other).

Exact steps for others to reproduce the error
Open the attached blend (simple instructions are provided (only 2 steps to follow))
Node position change example.blend

For those not wanting to use the blend, please see example screen captures below

.

While discussing Cycles node editor:
Wondered about this for a while. Adding a new Cycles material, nodes always appear off-centre in node editor space (upper right, instead of centralised), is there a design reason for this?

One area where this can be problematic; If the viewport is split and contains a small node editor window, 'new material' nodes can appear off-screen, as if nothing has been added.

Present behaviour (centre of node editor space highlighted)

Expected behaviour?

Zoomed and magnified view to help highlight the present 'new material' node placement

Above is not a complaint, (as mentioned) just something I've wondered about and not known where to ask until yesterday/today.
Thank you for your time,

David

**System Information** Linux Mint 17.1 Cinnamon x64 Windows 7 x64 Intel HD 3000 NVIDIA GTX 580m **Blender Version** Broken: Official 2.74 (Hash 000dfc0) Worked: None that I know of **Short description of error** Node Editor - Material panel: While nodes are changed in the Material panel, their previous node editor position is ignored, nodes jump to a new position next to a connected mix node; furthermore, while replacing more than one node connected to a mix node, both nodes jump to exactly the same position (on top of each other). **Exact steps for others to reproduce the error** Open the attached blend (simple instructions are provided (only 2 steps to follow)) [Node position change example.blend](https://archive.blender.org/developer/F183198/Node_position_change_example.blend) For those not wanting to use the blend, please see example screen captures below ![01 Node position change example.jpg](https://archive.blender.org/developer/F183209/01_Node_position_change_example.jpg) ![02 Node position change example.jpg](https://archive.blender.org/developer/F183212/02_Node_position_change_example.jpg) . **While discussing Cycles node editor:** Wondered about this for a while. Adding a new Cycles material, nodes always appear off-centre in node editor space (upper right, instead of centralised), is there a design reason for this? One area where this can be problematic; If the viewport is split and contains a small node editor window, 'new material' nodes can appear off-screen, as if nothing has been added. Present behaviour (centre of node editor space highlighted) ![03 New material, nodes not positioned centralised in the node editor space (always slightly upper right).jpg](https://archive.blender.org/developer/F183214/03_New_material__nodes_not_positioned_centralised_in_the_node_editor_space__always_slightly_upper_right_.jpg) Expected behaviour? ![04 New material, nodes expected position, central in node editor space.jpg](https://archive.blender.org/developer/F183216/04_New_material__nodes_expected_position__central_in_node_editor_space.jpg) Zoomed and magnified view to help highlight the present 'new material' node placement ![05 New material, nodes not positioned centralised in the node editor space (always slightly upper right).jpg](https://archive.blender.org/developer/F183218/05_New_material__nodes_not_positioned_centralised_in_the_node_editor_space__always_slightly_upper_right_.jpg) Above is not a complaint, (as mentioned) just something I've wondered about and not known where to ask until yesterday/today. Thank you for your time, David

David Black commented

2015-06-02 04:28:38 +02:00

Changed status to: 'Open'

David Black commented

2015-06-02 04:28:38 +02:00

Added subscriber: @david_black

Thomas Dinges commented

2015-06-02 07:09:09 +02:00

Added subscriber: @ThomasDinges

blender-admin commented

2015-06-02 09:32:43 +02:00

This issue was referenced by 89025958af

This issue was referenced by 89025958af5fc23fd2119557856446e8d527bcf6

Sergey Sharybin commented

2015-06-02 09:35:36 +02:00

Added subscriber: @Sergey

Sergey Sharybin commented

2015-06-02 09:35:36 +02:00

Placement of new nodes is a bit arbitrary. It could be improved for sure, but it's a bit tricky to do if we want to support both automated nodes editing and manual one. Surely it'll be improved, but not as a part of bugfixing.

Sergey Sharybin commented

2015-06-02 09:35:50 +02:00

Changed status from 'Open' to: 'Resolved'

Sergey Sharybin closed this issue

2015-06-02 09:35:50 +02:00

David Black commented

2015-06-04 01:33:57 +02:00

Wow that was quick!

Thank you for the rapid commit. Just tried the GNU/Linux version, massive improvement. :)

Thanks also for your feedback, appreciate improvements / modifications are not possible during Bcon4 bug-fix phase, just wondered about the points raised for a while and not known where to ask.

"Also improved a bit behaviour of adding new nodes, now they will not overlap that
badly. Still not ideal, but further improvements better not to happen at bcon4.". Interesting! :)

.

Considering future node editor improvements:

Rather than needing to rely on the Material panel to replace a node, what are peoples thoughts on adding Shift R function to the node editor?

Shift A add a node
Shift R replace a node (only functional if a single node is selected (works in exactly the same way as currently replacing a node using the Material panel))

Unless I've missed a similar function. Replacing a node can be faster than removing a node, adding a new node, reconnecting sockets and re-entering data.
On that last point, replacing a node carries over compatible exchangeable data, for example diffuse / glossy roughness values and so on (this helpful feature already happens while using the material panel).

Shift R also removes the need to search through collapsed Material panel node groups.

Oh! Just noticed (didn't spot before typing all the above), you already use Shift R, oh well, was a nice idea. :)

Thanks for your time,
David

Wow that was quick! Thank you for the rapid commit. Just tried the GNU/Linux version, massive improvement. :) Thanks also for your feedback, appreciate improvements / modifications are not possible during Bcon4 bug-fix phase, just wondered about the points raised for a while and not known where to ask. **"Also improved a bit behaviour of adding new nodes, now they will not overlap that badly. Still not ideal, but further improvements better not to happen at bcon4."**. Interesting! :) . Considering future node editor improvements: Rather than needing to rely on the Material panel to replace a node, what are peoples thoughts on adding **Shift R** function to the node editor? **Shift A** add a node **Shift R** replace a node (only functional if a single node is selected (works in exactly the same way as currently replacing a node using the Material panel)) Unless I've missed a similar function. Replacing a node can be faster than removing a node, adding a new node, reconnecting sockets and re-entering data. On that last point, replacing a node carries over compatible exchangeable data, for example diffuse / glossy roughness values and so on (this helpful feature already happens while using the material panel). Shift R also removes the need to search through collapsed Material panel node groups. Oh! Just noticed (didn't spot before typing all the above), you already use Shift R, oh well, was a nice idea. :) Thanks for your time, David

Sergey Sharybin commented

2015-06-20 23:56:36 +02:00

For the further improvements the bug tracker is not best place actually. it all gets lost and because it's now becoming more a mixture of bug report and requests also not so easy to follow..

Please be welcome in bf-funboard (functional discussion mailing list) and #blendercoders IRC channel. That'd be easier to find more feedback about the features you want and even find a developer :)

For the further improvements the bug tracker is not best place actually. it all gets lost and because it's now becoming more a mixture of bug report and requests also not so easy to follow.. Please be welcome in bf-funboard (functional discussion mailing list) and #blendercoders IRC channel. That'd be easier to find more feedback about the features you want and even find a developer :)

Sign in to join this conversation.

No Label

Download

What's New

Blender Studio

Manual

Developers Blog

Documentation

Benchmark

Blender Conference

Development Fund

One-time Donations

Cycles node editor, nodes position not maintained after Material panel changes #44921