OTOY Forums

Just an update about this thread.
We're considering all the suggestions made, and planning to implement the changes pretty soon.

Terrific, thank you!

Sure!

Just chiming in to say a +1 to the points that AlexeyAdamitsky posed here in this thread. Very well put together and covered a few of the points I've wanted to bring up as well but never had the fortitude to put together such a comprehensive outline as this user has. Well done.

Thanks for paying some attention to the design side of things in Octane for Blender. I've been working with Octane lately exploring volumes and was very confused by panels and settings in volumes panel for Octane. I went ahead and cleaned up the design of the panels.



Have a look at the interactive demo here:
https://twitter.com/AlexeyAdamitsky/sta ... 1457182721

1. The big issue is that everything is visually crammed together, and it's very difficult to understand which options belong together.
2. Simplified the area to use interactivity to explain how setting work. The rest can be explained through tooltips. The dropdow is option is split further to group available options better.
3. Organized common settings in a group and used visual rhythm principle for easier navigation.
4. Made it a separate panel, since it's a more advanced setting you might not use often.
5. Found very little use for this setting. It feels like a legacy option. Probably from pre 2.83 time. You can easily transform Volume object in Blender. I find it very hard to find the use case for this option now. But I might be missing something. If it simply duplicates Blender standard functionality, then I recommend removing it. If there is a use case, then let's keep it in a separate panel. I'd recommend this panel to be collapsed and deactivated by default.

As we wrap up 2022, I will be working with the core team on simplifying how things are in standalone/core so we can also reflect this better in the plug-in UX. We should be moving to standard surface based workflows (which we adapted with ADSK/Arnold and now coming to RS, even UE), and that is also an opportunity to simplify the entire node system (at least on the user facing end).

Goldorak wrote:As we wrap up 2022, I will be working with the core team on simplifying how things are in standalone/core so we can also reflect this better in the plug-in UX. We should be moving to standard surface based workflows (which we adapted with ADSK/Arnold and now coming to RS, even UE), and that is also an opportunity to simplify the entire node system (at least on the user facing end).

It's great to hear this. It felt like Octane was doing a significant jump in 2021-2022 version in complexity. But it also decreased accessibility in many areas, I feel. I fully support ASDK/Arnold approach to shading. It's one of the most artist friendly systems I've seen. Very easy to understand and start using.

Would love to see for Octane to improve the accessibility. If there is a spot for a product designer or similar position responsible for making user experience better and creating a cleaner UI, I'd love the opportunity to help improve the core as well as Blender/Octane integration.

Please, improve the parity of design between Texture and Blackbody emission nodes.

Make the Texture field on the Blackbody Emission node (1) the same as with Texture Emission (2) node. Otherwise I have to do an extra step to add RGB Color node (3) to gain this level of control.



I understand, that you've probably kept Texture settings for Blackbody as a numerical value and not a color value to safeguard users from making unrealistic results. But having color value there allow for faster access and additional creative control when needed with one less node.

AlexeyAdamitsky wrote: I understand, that you've probably kept Texture settings for Blackbody as a numerical value and not a color value to safeguard users from making unrealistic results. But having color value there allow for faster access and additional creative control when needed with one less node.

This is set up in the same way as in standalone. The color is defined by the temperature. This drives the efficiency. If it was set to an RGB color by default then you can't directly read the number as an efficiency anymore.
It's unfortunate that Blender doesn't let you change the type of a field in place and we have to add an external node and connect it…

Goldorak wrote:As we wrap up 2022, I will be working with the core team on simplifying how things are in standalone/core so we can also reflect this better in the plug-in UX. We should be moving to standard surface based workflows (which we adapted with ADSK/Arnold and now coming to RS, even UE), and that is also an opportunity to simplify the entire node system (at least on the user facing end).

Is there any news about the UI rework of the blender UI.

Just started using it on blender to switch a large part of my job here, and as other have said it's a bit of a mess right now...
The greatest example is the triplanar node, every other version i used, standalone, 3ds max, C4D and even modo, they all have a little checkbox to use the same texture on all the axis, but here we are linking every socket one by one for every maps we need it. And there is a lot of small detail like this wich are annoying