Node UX Redesign #382
Replies: 20 comments 81 replies
-
|
The new nodes are really nice after playing around with them for a bit and feel a lot more intuitive than the previous ones (it's especially nice that they now automatically convert between e.g. float & vec3). Test environment:
Tested components:
General feedback so far:
Some slight inconveniences I noticed:
|
Beta Was this translation helpful? Give feedback.
-
|
If it weren't for the other node systems I'd probably prefer Split/Join as names, but in this case I think consistency with the default blender nodes would make it easier for new users to find them (especially since they are just a mode in the math node). @Kolupsy Just tested it and your assumption is correct. |
Beta Was this translation helpful? Give feedback.
-
|
Some more tests:
I threw an old model (the original file was from back in January, so this shouldn't be a typical use case) into my test scene and tried to update the materials to the new malt version. In the viewport this worked quite nicely until I tried to start an f12 render which then got stuck on an exception. This in itself wasn't unexpected, but afterwards the only way of stopping the rendering process is to forcefully close the python window and restart Blender. When trying to cancel the rendering process in Blender it just keeps showing "Cancelling 0%" and the GPU usage of the Python process stays consistently high even when switching to the solid mode in the viewport. In my opinion it would be good if exceptions in the render process could be caught, terminate the render process and show up as an error message for the user (right now they only show up in the malt logs) if possible. For completeness those were the exceptions I got. They only occur when the objects/materials that I imported from the old project are included. When only the new objects/materials from my initial comment are being rendered they don't occur (so I probably just missed some remnant of the old shaders in my migration). This was the first error (restarting Blender and ensuring that I had no more dangling links to old mesh shader files fixed this one): Error Log 1And this is the current one (not quite sure what causes this one, but I assume it's also related to the fact that the shaders were updated from a very old version of malt): Error Log 2 |
Beta Was this translation helpful? Give feedback.
-
|
Could you upload reproduction files? |
Beta Was this translation helpful? Give feedback.
-
|
The actual exception was an error on my side as expected (I missed a material on one of the objects that still had a reference to an old glsl mesh shader). After I removed the last reference to that material it worked without issues. But if you want I can send you a small reproduction file tomorrow so you can check the exception behaviour. |
Beta Was this translation helpful? Give feedback.
-
@Niruja-bit ok that is great. I think with the performance update by @pragma37 the subcategory cycling function should be a lot more performant overall. That way you should be able to use it comfortably at any given time. |
Beta Was this translation helpful? Give feedback.
-
|
Hardware info I've been experimenting with it since the PR was still in development. Seems stable as I haven't really found any bugs.. I adore pretty much all of the changes and additions.
This specific character really just uses the shader below. There's a unique copy specifically for the hair, but most of it is the same setup.
With this amount of nodes, which I don't think is very large, the performance can suffer in the node editor. There's a tad bit of delay when adding new nodes, reconnecting noodles, and undoing. Don't really know why, but the NPR Specular node kinda feels icky to use to me. I much preferred the functionality of the old Toon Shader node and the results it gave. Part of my dislike is that I don't really like working with the color ramps as a part of the nodes, something about that workflow doesn't really click with me. Have not really used the "cycle subcategories" thing much at all. Could just be out of habit, doesn't feel all that intuitive to use to me. Maybe a proper search function would be better suited? So rather than pressing a key multiple times, you just start typing out the name of the function you want.
Maybe I'm missing something, but I can't seem to figure out how to get a smooth result from the Ambient Occlusion node? Both of these UV spheres are shaded smooth, but the ambient occlusion is not. Don't know if it's functionality has changed since the previous release, I don't think I ever used AO on a smooth surface prior to this UX update.. EEVEE's implementation of AO does take whether or not the mesh is shaded smooth into account. The Wave and Gradient nodes would benefit from more clearly defined coordinate inputs, "value" and "a" are a little confusing at first glance 😄. I would also like to see the extra settings found on the Voronoi and Noise nodes in Blender's default rendering engines. Thank you Miguel and Kolupsy for spending your time on this project. I can't express how grateful I am that Malt is as high quality as it is. |
Beta Was this translation helpful? Give feedback.
-
@dibli-goost What would you suggest to use instead? Here is my proposal: Change the 'A' parameter on the Gradient node to 'Value' and the 'Value' parameter on the wave texture to 'Gradient'. Would that make more sense in your opinion?
@pragma37 it would be nice to support variants of the procedural textures to improve performance in many cases. Also the different Voronoi functions would be interesting. |
Beta Was this translation helpful? Give feedback.
-
Character Shader Blend File.zip Here's a quick little sample blend containing a mesh with the vertex color and normal transfer set up I use, as well as that material/node tree.
Yeah sure! Personally I prefer to use the various Shading nodes to output masks which mix between things such as surface color. Most of the time that means my gradients will be black and white, when the color ramp utility on those shading nodes I think is best suited for when you want to colorize the output immediately.. if that makes sense? If I'm already working in black and white, feels like a bit of a waste of space to have the color ramp visible. It's not really useful as a visual aid as I prefer to look at the viewport for the visual feedback of changing the look of the gradient. I don't really need more than 2 stops most of the time when it comes to defining my shading. Though I could see a use with more experimental designs, in those cases though I could just add a color ramp after the shading node. It doesn't like, destroy my workflow to have them there, but it feels cluttered to me. Assuming the "Toon Shader" node persists internally I'll probably just continue to use it as it feels better for my use case.
I think "Coord" would be best, as it'd be kept in line with the Noise and Voronoi nodes. All of the various texture sampling nodes use a consistent UV input, so I think some level of consistency should be applied to the generated textures as well. While I think I understand the intent behind using the relevant "float, vec2, vec3" etc, to define each gradient type for example. I think it is a little bit more confusing than the way Blender does it by default, which is just with a generic "vector" input. With just one input type throughout all the nodes, it creates little confusion as to what you plug into it. I think Coord is a bit better of a name but the idea is the same as what Blender is doing. Idk if i'm explaining this very well but I tried 😄 |
Beta Was this translation helpful? Give feedback.
-
|
Thank you! I'll test the file asap.
Keep in mind that the current node applies the ramp for each light, so it can handle lighting color and intensity correctly. I'd say that using a grayscale color ramp (probably shared across multiple nodes/trees) is actually the best way to use the NPR shading nodes, but I get your point. |
Beta Was this translation helpful? Give feedback.
-
That is true. Maybe an idea for a potential PBR Pipeline
I think the only reason for blender to have a common 'Coordinate' vector input on the wave and gradient texture nodes was to keep other nodes connected when switching their 'modes' instead of swapping out sockets (which has become a lot more popular recently with the blender dev team). Since this is a limitation, not a feature and since malt doesnt suffer from this limitation in the first place I dont think its a good idea to follow the blender design in this case. I would say a good compromise in this case would be to at least keep the input NAMING consistent by calling them 'Coord' or 'Coordinate' Any objections? @dibli-goost |
Beta Was this translation helpful? Give feedback.
-
|
I don't really have an issue with the type itself. Just the name. Maybe I should have been a bit clearer about that. The type not being consistent can at least let you know that a conversion is happening, say if you plug a vec2 into a float. The name should be consistent though yes, I think Coord is a good name. 👍 |
Beta Was this translation helpful? Give feedback.
-
|
Thank you for your work. Here are somethings for your considerations. Why MixRGB node is not included? I notice it is included in malt shading essentials. Switching different materials in the material panel, the malt node tree panel is not auto-refreshing unless we click the viewport window Overrided parameters lose min max clamp. |
Beta Was this translation helpful? Give feedback.
-
|
Beta Was this translation helpful? Give feedback.
-
|
Beta Was this translation helpful? Give feedback.
-
|
It's not RGB (it's RGBA) and it's not mixing (it's blending) so sticking to the Blender name felt super wrong. |
Beta Was this translation helpful? Give feedback.
-
|
fixed 3! |
Beta Was this translation helpful? Give feedback.
-
|
Hardware info: i9-9900k, Nvidia 2080ti, 32GB RAM running Windows 10. No technical issues for me, and it's difficult to express how much I appreciate most of these changes and how grateful I am that the two of you are working on it. A few of the nodes do give me some trouble, but most of it is fairly easy to fix. Color ramps, or at least the NPR diffuse, takes a value of 1 from the ramp handle and outputs it as a value of ~.64 even when set to constant interpolation, which necessitates the use of map range or similar in order to use it further. Kolupsy and I were talking about this on discord so they might have brought it up already, but equal functions in math nodes should probably have a tolerance value so that they work as intended even if two values are not exactly the same. One of the things that I haven't found a fix for yet though is that trying to tweak the normals too much, such as with a normal edit modifier, can result in choppy or blurry shadows when compared to the development branch. Regarding the Ambient Occlusion not using smooth shading thing brought up earlier, that has happened for a while and is not a result of these changes. |
Beta Was this translation helpful? Give feedback.
-
Yes, we can add that. 👍
Could you upload an example file?
That should be fixed already. 👍 |
Beta Was this translation helpful? Give feedback.
-
Please disregard. I forgot to turn off self shadows while normals are edited. There's nothing wrong. |
Beta Was this translation helpful? Give feedback.
-
|
I've updated the branch to avoid unnecessary node tree updates. Does that help on your side? @Kolupsy @dibli-goost @Niruja-bit |
Beta Was this translation helpful? Give feedback.
-
|
Not to sound dramatic but this is the best thing ever! It is very responsive, there is no performance hiccup from adding a node whatsoever. I have noticed that changing the subfunction enum is not unreliable in making the node tree recompile. I believe it is because |
Beta Was this translation helpful? Give feedback.
-
|
I think a clean solution could be to have all the checks that might cause |
Beta Was this translation helpful? Give feedback.
-
|
This is a very noticeable improvement to performance! It's been brought down to about half a second of delay on average)when adding nodes in Material View for me. It's still a bit laggy when attempting to make subtle adjustments, sliding sliders, but at least the delay is less impeding when creating the node trees themselves. |
Beta Was this translation helpful? Give feedback.
-
|
There must be something wrong there. Is this maybe a somewhat large scene? |
Beta Was this translation helpful? Give feedback.
-
Not particularly. With or without subdiv active, same amount of delay (as far as I can tell). About 30k tris with simplify on. If you want me to, though I really think it's the cause. I can send you the blend file over discord or something. (As long as I have assurance it won't end up elsewhere on the internet 😄 )
No. I think it being a hardware issue is a large possibility. I don't get great performance in blender to begin with, posing and simulation takes more time than I feel it should. |
Beta Was this translation helpful? Give feedback.
-
I meant more in terms of object count, material count and material complexity (as in number of nodes). In any case, I managed to get pretty bad performance by taking your previous example and duplicating the object and its material/tree many times. I think this branch should help: It's on a separate branch because it makes non-trivial changes to the way the node data is stored. Don't save anything important with that branch yet. https://github.com/bnpr/Malt/releases/tag/node-tree-properties-latest |
Beta Was this translation helpful? Give feedback.
-
|
It's near instantaneous adding nodes on that branch for me. The scene isn't that big in that sense either, very few separate objects, unique materials, ect. It's quite small. Irregardless, it is much better now. |
Beta Was this translation helpful? Give feedback.
-
|
After playing around with it a bit more, I have a couple things that are IMO core to procedural textures.
Relatively minor gripe, and I can understand why it's set up this way, but I'm not a fan of how color ramps are a parameter in Color Gradient nodes by default. In my opinion it gets cluttered quickly having to make so many new ramps, plus it doesn't sit right with me that this node remains linked to its duplicates by default the way image textures do when, unlike image textures, color ramps are often duplicated and then adjusted slightly to get slightly different results. That's just my experience though and other people probably set their nodes up differently. I would prefer that each Color Gradient be self contained by default and, in the event that you need them to share a ramp, to plug in the preexisting sampler1D parameter. At the moment I don't see any use for the sampler1D parameter either way, since you can just select the ramp you want from a dropdown menu directly in the color gradient and they'll stay linked until you specify that they shouldn't. Other than that I'm very much looking forward to the official release and once again I'm very grateful for all the work that has been put into it. |
Beta Was this translation helpful? Give feedback.
-
|
Beta Was this translation helpful? Give feedback.
-
|
Beta Was this translation helpful? Give feedback.
-
|
Beta Was this translation helpful? Give feedback.
-
Yep, that's likely the best option.
You could use object space normals or position for that too. (Geometry node set to object space) We'll add bounding boxes eventually, though. It's just one more of the hundreds of tiny things on the to-do list. |
Beta Was this translation helpful? Give feedback.
-
|
@pragma37 I was wondering, could we have |
Beta Was this translation helpful? Give feedback.
-
|
I think it would add too much extra complexity for a somewhat niche need. In your first example, you could just declare a "big enough" fixed size array and clamp the input to the max size. For your second example, I don't think it's reasonable to redesign the whole compilation model just to work around a Blender UI issue. |
Beta Was this translation helpful? Give feedback.
-
|
I see. Feared as much. I was hoping this might be just a little change. Yeah if not then that's ok too. I solved the issue before with the method that you suggested before. Moving the "clamped" down would be a good an easy solution. Maybe an easier compromise would be to fake parameters being constant by setting this in the META block. Then the parameter would be drawn on the node interface instead of the socket interface. Sockets can be disabled which hides them |
Beta Was this translation helpful? Give feedback.
-
|
I've been experimenting with the new Line Art node a bit more, previously I had refrained from using Depth Width due to it getting in the way of some details. It looks much better to me now though.
However, I'm getting rather, uh, inconsistent results when not locked to the camera or an orthographic view.
(Orthographic) The level of error seems to be dependent upon the viewport window itself:
Line art is being generated via this setup, it's quite simple as you can tell 😄 . Parameters are greyed out because the node tree is being linked from another blend file, so that I don't have to manually update the line art for every character. It's being generated within a screen pass on the Render Layer node tree. I don't think this is related to linking, broken in the original blend file too.
The level of error between the locked and unlocked view is wildly different for every project, some it's rather minor.
Surely this isn't intended functionality? Is it working this way for anybody else? I'm not on the most up to date version of the PR due to the "Don't Save Important Files" disclaimer, but I did test it on there too and the same result persists. |
Beta Was this translation helpful? Give feedback.
-
|
The new depth detection yields better results but is more dependent on depth buffer precision. You have an extremely low Clip Start value in your viewport, the default is 0.01. Also, keep in mind that the higher your Focal Length, the higher you will have to set the Clip Start to avoid artifacts. |
Beta Was this translation helpful? Give feedback.
-
|
Still, I can't reproduce the issue with your settings. |
Beta Was this translation helpful? Give feedback.
-
Ah, I didn't realize that they were connected! Setting the clip to be the same for both camera and viewport made the results consistent. It seems to be a problem with that instance of the Line Width node actually. Replacing it with a new one with the same settings seemed to fix it. Here's a project with the old instance of the node (top) and the new instance (bottom), in case something is gleanable from that. Changing the parameters on the old instance does nothing, though it was working prior to putting it in this project, not sure why it's broken now. |
Beta Was this translation helpful? Give feedback.
-
|
I'm 99% sure you saved the node tree at some point with the new node-tree-properties branch.
Opening it in the new branch works fine. |
Beta Was this translation helpful? Give feedback.
-
|
Hmm yea I guess I did haha, works fine on the new branch. Must of accidentally saved it when I was testing it before posting this thread. Oh well, problem solved. |
Beta Was this translation helpful? Give feedback.
-
|
On a newer version(the one from the download link on this page) I am encountering issues where changes in the node tree do not actually cause it to update all the time. It does once in a while but is fairly inconsistent as far as I know. Sometimes it fails to compile and gives me a bright yellow material instead but, due to the inconsistency of anything changing at all, it's hard to fix this. It only seems to do it in larger node trees from what I can tell. I hope putting it in a zip file works, if not I can upload it elsewhere. I'm on blender 3.2.0 rather than 3.2.2 if that helps. |
Beta Was this translation helpful? Give feedback.
-
|
Good catch! For "classic" function nodes these cases were handled already, but the new drop-down nodes didn't handle it right. It should be fixed now. 👍 |
Beta Was this translation helpful? Give feedback.
-
|
Yes, it works now! Thank you! Node trees are so very much easier to make now. |
Beta Was this translation helpful? Give feedback.
-
|
I have suddenly encountered(it was fine yesterday) two issues. One where map range nodes output only a value of 0 or 1 and where the settings in the material panel have completely vanished. It also seemed to get slower to launch and now no longer displays increased speed in the node editor and I am unsure why. |
Beta Was this translation helpful? Give feedback.
-
|
Good! I checked (in the commit before the merge) the material panel issue you mentioned, just to be sure what was the problem. On the performance side, I couldn't find any weird extra updates or anything like that. I couldn't check the map range issue since the node tree is too big and would take me a while to figure out how to test your issue.
I can reproduce it. I remember testing this specifically and it worked.
Sorry, I'm not sure about what this means. There's a parameter that resets to its default value after file reload? |
Beta Was this translation helpful? Give feedback.
-
|
The rename issue should be fixed now. |
Beta Was this translation helpful? Give feedback.
-
Glad to hear it!
I don't think so. The issue was from part of the node tree that didn't interact with the wave node last I checked.
One of the boolean parameters(the one labelled Hair 1 Switch) is always in its 1 state when the file is started, even if the file was saved and closed out with this boolean outputting 0. I deleted it and re added it and it works fine now, but this boolean was the only one outputting a value of 1 instead of 0 when I updated Malt so I think that might have had something to do with it. The others were all outputting 0 and behaved correctly the first time. |
Beta Was this translation helpful? Give feedback.
-
|
I'm not sure this is something you intended or not, but nodes are sorting in the material panel by node type primarily(all booleans in alphabetical order, all bright/contrast in alphabetical order, and so on) instead of purely in alphabetical order. Is this intentional or just something that happened to come up when node-tree-properties and node-ux were merged? |
Beta Was this translation helpful? Give feedback.
-
Good catch! |
Beta Was this translation helpful? Give feedback.
-
|
I have finally merged the node-tree-properties branch into node-ux. I've also updated the material examples to use the new nodes: #94 (comment) The trees are a lot tidier now! |
Beta Was this translation helpful? Give feedback.
-
|
I noticed that the curvature node has the same issues that the AO had of clearly revealing the topology / flat shading underneath. Is that something we can fix as well? Currently the curvature feature only works well on objects that don't have a lot of normal detail in the first place. |
Beta Was this translation helpful? Give feedback.
-
|
In the case of AO, it was caused by using the "true" geometric normals, but in this case, I'm not sure why it happens.
Do you have an example? |
Beta Was this translation helpful? Give feedback.
-
looks good on a cube but not so much on the monkey
oh interesting. It seemed like it would come from the same source since the results were similar. That is too bad though |
Beta Was this translation helpful? Give feedback.
-
|
It's almost an exact match of the Blender Workbench engine behavior. With contrast filter: |
Beta Was this translation helpful? Give feedback.
-
|
hm my theory to why this is happening is that since normals are linearly interpolated and curvature could be describes as the magnitude of the derivative of the normal, the resulting curvature is a step function. had a quick search and this pretty much confirms that: https://forum.unity.com/threads/how-to-get-smooth-curvature.818340/ maybe there is a way to have 'incorrect' curvature that looks a bit better though |
Beta Was this translation helpful? Give feedback.
-
|
OR, accept the fact that smooth normals are a hack and subdivide the mesh. 🤯 |
Beta Was this translation helpful? Give feedback.
-
|
Is there a way, in the current build, to change the order in which parameters appear in the material panel? |
Beta Was this translation helpful? Give feedback.
-
|
Nope, they're sorted alphabetically. |
Beta Was this translation helpful? Give feedback.
-
|
Ok that's what I was wondering. Glad to hear that it's fixed. |
Beta Was this translation helpful? Give feedback.
-
|
Alright, I've gone and tried a bunch of things out on my CyberGirl model as a test, and its working well. This is a single material with a bunch of the original colors baked to vertex colors, and some masks. I didn't recreate the whole shader yet and most things have the same parameters for everything but diffuse and gloss color. But its still a good test. (Metal has nothing to reflect so looks mostly grey.)
This is using all non-internal nodes except for an internal Toon Shading that I used to isolate the Shadows so that I could make them less dark on the hair. It uses Bevel, AO, and Curvature. Generally, I am very pleased with how it is all working, and I'm looking forward to doing a full setup that will come together better artistically! In the mean time, here's comments, questions, and bugs I noted down while setting this up. I am using the latest UX build from a few hours ago, but built most of the setup in the previous build. So if something has changed I may have missed it. Bugs/Unintended?
Comments:
Questions:
Thank you again for all the work you've put into this! I have nearly completed all the Geonodes stuff that I've been working on for most of the year so far. Which means I'm not far from starting to build a new character, which will mean a lot of Malt! And some videos on using it once the Geonodes ones are done! |
Beta Was this translation helpful? Give feedback.
-
|
Looks good! |
Beta Was this translation helpful? Give feedback.
-
Personally, I only use the overrides. As I recall having issues with the index before. I think your second suggestion is better overall, would create less confusion around the index order.. Maybe name the parameter on the Vertex Color node to "Override Slot", to make it clearer that you need to use them? It does add an extra step to the vertex color workflow, but I mean you're gonna be in the Mesh Data Properties tab to create the Vertex Colors anyways, adding the Override doesn't take too long. Maybe extra slots could be useful too? 4 seems like a low number to me. |
Beta Was this translation helpful? Give feedback.
-
|
Thanks for the clarifications! So it sounds like I'll be able to do what I want with Internal and Custom nodes.
Hmm. Personally, I'd rather be consistent with the rest of Blender. But I'm biased because I don't use painting programs >_> |
Beta Was this translation helpful? Give feedback.
-
Thanks! I'm always lurking, just juggling too many other things. But as they conclude, it'll be more Malt time!
I've never run into space conversion issues in the rest of blender. So its handling them under the hood somehow. We should probably match whatever that is. I don't seem to be having the F12 render issues in fresh files. I'll try to nail down what could be the cause. My file is a bloated mess.
I've been using Base Normal and Custom Normal. Base Normal is used in the Mikkelsen bump mapping paper I learned about them from. Custom Normal makes sense for the typical use case in blender of using them to apply a Normal Map made for the Base Normal onto a Custom Normal. But they can be used in lots of ways beyond this, especially if multiple Custom Normals become involved (but it is statistically likely that nobody other than me will use them that way.)
In this case, I mean only the Cast Shadows, not the shading. I reduce the darkness of shadows cast onto the hair since real hair doesn't really show hard cast shadows. Thanks for the rest of the clarifications! I'll also experiment with the Vert Color overrides. I'm currently working on a video about Surface Gradients. And then will be Normal Mapping, and then Bump Mapping. So I'll be working on the Bump Map for Malt as part of that video since I'll need to use it to break down how bump mapping actually works. So hopefully I'll get to that in a few weeks, but I'm also starting a new job, so who knows what will happen. |
Beta Was this translation helpful? Give feedback.
-
I agree, that's the one I ended up using.
This has been brought up before. It's the same for UVs.
Hopefully, once you realize how much more powerful the Layer Blend node is, you will change your opinion. XD
I updated the node-ux branch to assume sRGB for byte colors are sRGB and linear for float colors.
I think it was related to AOVs in your Render Nodes.
Sounds good to me, I'll update the nodes.
I see. I tried adding extra controls for controlling the shadow sampling "position" and its "range" in the color ramp, but it felt too convoluted.
Awesome! |
Beta Was this translation helpful? Give feedback.
-
|
For me, the IDs dont really work either. Using the deprecated nodes is a little bit better but the w channel does not work and the resulting color is off |
Beta Was this translation helpful? Give feedback.
-
Each ID channel is 16-bit only, so the z and w channels will always be 0. |
Beta Was this translation helpful? Give feedback.
-
|
Then should the ID node not output vec2 values? |
Beta Was this translation helpful? Give feedback.
-
|
#319 is still persistent on the latest version of Malt. Every generated object ID is the same. Though I can still replace the generated one with a new one through the Pack ID node. Inputting shadows, textures and the like into the pack ID all seem to work fine, generate lines properly and such when needed. There is noise banding on gradients though, is this expected behavior?
While I don't really see how IDs with smooth gradients would really be useful, I did kinda expect for the output to reflect the input more accurately here. |
Beta Was this translation helpful? Give feedback.
-
I'll upload a custom version that logs extra info to see if we can figure out what's going on.
Yes, it generates a hash for each color. You can use Snap to control gradients:
Then, if you plug it into Pack ID the w would be set to 1 and the ID would be changed. In hindsight, it would have been better to simply use a plain rgba unorm as Object ID and another one for Custom ID. |
Beta Was this translation helpful? Give feedback.
-
Random Per Object does not work either. It does generate a random value of course, but it's the same for all objects. So far I've been using Vertex Colors to replace them manually, creating an ID Vertex Color, then packing that value in. |
Beta Was this translation helpful? Give feedback.
-
|
The latest node_ux version, can we still have the settings on top of other materials parameters? |
Beta Was this translation helpful? Give feedback.
-
|
They should be available. BUT you dont get 'Receive Shadows' or 'Self Shadows' unless your graph contains a node that uses these settings (which are the NPR Diffuse and NPR Specular nodes) |
Beta Was this translation helpful? Give feedback.
-
|
@Kolupsy I think he means that the material Settings used to be at the top of the UI, and now they're sorted alphabetically. @HSDSZ I've hardcoded the UI sorting so Settings are always drawn at the top. |
Beta Was this translation helpful? Give feedback.
-
Thanks |
Beta Was this translation helpful? Give feedback.
-
|
I used the branch on a slightly larger project (actually still a small project but at least not just a test) and I found some issues:
|
Beta Was this translation helpful? Give feedback.
-
|
1&2. Can't reproduce it. |
Beta Was this translation helpful? Give feedback.
-
|
1&2: thought as much. I'll try to find a reliable way to reproduce the error. I have found that problems start creeping up the more complex the file gets so it's tricky but hope I can find something |
Beta Was this translation helpful? Give feedback.
-
|
I found some issues when renaming a node tree after a duplication (including default node tree presets). |
Beta Was this translation helpful? Give feedback.
-
|
Beta Was this translation helpful? Give feedback.
-
|
The node-ux branch has been merged into the Development branch. |
Beta Was this translation helpful? Give feedback.
-
|
awesome! This is great news. Time to make new PRs 😋 |
Beta Was this translation helpful? Give feedback.
-
Node UX Redesign
As many of you may already know, @Kolupsy and I have been working on a Node UX redesign
with the goal of providing a more polished and familiar experience for Blender users.
After almost 200 commits, the work is pretty much completed at this point.
Now is your time for testing and providing feedback.
DownloadEdit: Merged!
All the changes are already in the Development version.
What's new?
More powerful nodes
Our main goal was to enable richer node features while maintaining the convenience of declaring them from plain GLSL functions.
Most nodes have been completely redesigned to take advantage of these new features and provide a better workflow.
Improved Node Categories and Node Labels
Search functionality
Shift+A search functionality, including node drop-down functions.
Drop-down nodes
Math Node style drop-down function selection.
You can easily cycle through functions by pressing its first letter key.
Sliders and drop-down options
Node-Wrangler style Preview (Crtl+Shift+Click)
Many more tweaks
Nodes outside the Parameters category now hide their parameters by default in the material panel.
Visibility can still be toggled in the Node Tree side panel.
All Internal engine functions can now be accessed by enabling the Show Internal Nodes option.
Old nodes have been marked as internal, so your existing node trees still work.
Socket types can now be hidden by disabling the Show Socket Types.
Socket colors have been tweaked to match the Blender defaults when possible.
New Node Trees now have a minimal default setup.
Node Tree Local Libraries have been deprecated. (Old node trees that used the feature still work)
New Rendering Features
While the main focus were the UI features and the re-design of already existing functionality, there are some new rendering features too.
Improved Shading Nodes
All the previous shading functionality has been merged into 2 main nodes.
In addition, there are two main new options, Ramp Offset and Max Contribution:
Improved Line Width Node and Line Detection algorithm
The Line Width node has been tweaked and simplified.
Now it's also possible to specify the units of the line width (pixels, screen relative units and world space units).
The line detection algorithm has been improved too.
Layer Blend
MixRGB-like node with support for alpha blending and different color space modes.
Kuwahara Filter
Kuwahara filter
Original image
Other Features
Feedback and testing
What do you think of the new nodes?
Do you like the overall direction?
Did we miss anything important?
Please, keep in mind that the Node UX branch could still have breaking changes based on your feedback.
Your current node trees from the Release and Development branches should still work. If they don't, please report it.
Beta Was this translation helpful? Give feedback.
All reactions