Hi @brecht , I am interested in joining Google’s Summer Of Code this summer. And I am particularly interested in improving the workflow for procedural content creation in Cycles by refactoring and adding some new nodes. But before I submit a draft of my proposal, I wanted to see if you might be interested in what I am hopping to achieve or if it is not suitable at all. Some of what I want to deliver is as follows:
Breakdown the Vector Math node into multiple nodes as follows:
Vector Math: A node that contains vector operations whose output is a vector like addition, subtraction, entrywise product, entrywise divide, cross product, snap, and so on.
Dot Product: A node that computes the dot product.
Vector Length: A node that computes the vector length.
Provide a Rotate node that have explicit angle inputs. Because Mapping node doesn’t allow variable inputs.
Provide a random generator, often referred to as White Noise.
Provide a Clamp node as an alternative to the Clamp option in the math node. The option is nearly never used and is unnecessary.
Provide a Map Range node similar to that of the compositor’s.
Provide a Constants node, returns pi and e.
Investigate dynamic node socket layouts. Why does math sin function have two inputs?
Expose object color in the Object Info node.
Investigate accessing custom properties through the Attribute node.
Expose information about splines in a Spline Info node. Spline indices, lengths, parametric vectors, and so on.
This could be a good project. Eevee nodes would have to be updated alongside Cycles since we keep these shading systems in sync.
Adding more operations seems fine. Splitting up the node is unnecessary I think. What could be improved is hiding/showing certain sockets depending on the operation.
The mapping node could be changed to provide dynamic inputs instead of adding a new node.
A requirement is that repeated renders give exactly the same result. But some node that hashes the position to provide a random number seems good, users often emulate this with a noise texture.
Sounds good.
I don’t think this is needed, it’s easy to type pi and e into Blender number fields.
Yes, it’s possible to dynamically hide sockets for this.
It would be good to have a general system to access any object property from shading nodes. Requires some kernel changes to allow storing general per object attributes.
Not sure what kind of spline you are talking about or what this would be for.
could be really useful because there is not any alternatives for polygonal displacement. it generate way too much performance dilemma’s.
note that since 2009 certain users generates their own parralax maps trough the shader editor, it could be cool if this feature would be officialized !
also the fact that blender is becoming more and more game-dev friendly, this could be a good idea to attrack even more of this types of users.
just throwing my two cents in here- I’ve always found it odd that we have a “Math” node and have to hunt around for the operation we’re looking to do. Then once we find it, the node is renamed to “Multiply” or whatever. A new user dissecting a graph will see those nodes and wonder why “Multiply” doesn’t show up in the add menu. It does make sense, functionally, to have math operators all live in the same node- so maybe a compromise would be to have some kind of “node alias” keywords that point to the correct node (and perhaps even select the correct operator for the user?).
This way, the user coming from Nuke, UE4, Unity, Houdini, Substance Designer, C4D, Modo, or literally any other software with node-based math can type “Multiply” in the search box and get exactly what they’re looking for.
Thats a very specific task and touches many more areas of blender.
Sure it would be cool, but there already are some user created Parallax shaders (not for Eevee though).
It would steal Omars time away from improvements everyone will use (general node editor improvements) for something only a marging of users will use (Parallax).
And this is already a Parallax user saying this.
Fantastic idea. Maybe it could be even called “Math (Multiply)” in the search listing specifically when searching for “multiply” ? other way around it shouldnt appear when only searching for “math”, i.e.
No clutter.
My proposal:
Scale the node sockets to a certain amount when zooming out,
not just graphically ofc, also for “hit detection”.
So its easier to connect them when zoomed out.
Omar, one thing I would add is a “Random per element” socket in the object info.
With this I mean that if I hace 1 object that has 2 separated pieces of geometry it will generate 2 different random value.
This could be very useful, for example if we hace an object that has a lot of leafs, we could assign a different color value to each leaf without having to separate them into multiple objects.
something that would be more useful and extensible would just be a “random” node with a variable input. then you could drive a random seed with a keyframe, object ID, uvs, world position, etc.
I am not sure how the system works yet. So I am not sure if this can be implemented efficiently or not. I think we can expand the proposal at anytime since the goal is general in nature. So I will look into it and propose it to the developers if I got accepted.
Regrading the proposal. I probably needs a bit more or perhaps a plan to gather feedback from community for further small improvements to do. The current changes may not be enough to fill an entire summer.
It may be good to check website like right click select for improvements that are most requested. Something like spline info is interesting but also fairly niche.
about the spline info node,
as we’ll be having more procedural tool ( everything node ) more user will need this node in the future, for now we separate the different curves so we can use a random object info and that’s slow, at work we use animation node to make particles trails and then to shade them it’s manual work )
Alright. Sound good. I am not sure if you—developers—agree with the proposed improvements, either on right click select or other places. Is there an official list? Also, should all improvements be related to a certain blender area (Cycles/EEVEE), can it include improvements to the compositor as well?
Also, assuming that the project didn’t get accepted. Can I still work on some of those improvements outside of GSOC?
“Automatic search after dragging a noodle”
173 votes in 9 month,top 9
(i’d like to highlight the fact that it could be cool if we dont break the actual shift a + two letters workflow)
03
Parralax occlusion mapping node “only a marging of users will use (Parallax)” but still on the top rated rcs idea hu okay okay i’ll stop insisting stop killing my dream please
111 votes in 10 month, top 22
also another topic below with 40 votes with the same demand
04
“using picker outsite of blender”
76 votes
(i related this to the node editor because its painly use there)
related to the color picker also with 52 posts
basically custom plalette support + blackbody integration
also related at 48 upvotes, color harmonies function for the colorpicker
related few post below,
users also want improvements for the colorramp with 42 upvotes
and 39
more cleaer pickers
08
Nodal baking, post of mine
51 upvotes
basically baking the texture through the node system as an output node and re-using the node directly after for vram optimisation and easier baking. this also play the role of a kind-of cache system
Related to the node group
At 27 upvotes we have a another nodegroupe proposition
For the nodegroup i think that it’s quite sad that some parameters like XYZ rot/scalding/transfo aren’t avaible inside of a group,
Same with color ramp, no way of interacting with it in a nodegroup.
11
at 39 votes post of mine,
basically syncing the image editor with the selected image texture in the node for quicker workflows
12
ive also seen a cool post that propose presets for bid nodes like the princripled BSDF
basically having a little preset menu on the top of the node like in the proprety editor
cant find the post anymore
13
Histogram overlay in color ramp and curve nodes - proposal
14
random seed
15
Comments of mine about some general improvements:
its kind of frustrating that some nodes are exclusive to the compositor and texture editor and other to te texture editor, why not giving us hue correct/ color correct/ color balance/ blur node/ sharpen nodes for the shader editor? i understand that some nodes are exclusive and we can’t do nothing about it, but some consistencies between the three editors would be nice. The code is already Written it’s basically done. Same nodes through all the three editors when we can.
highlight the Flow of the node like substance designer.
having colored wires as an option every wire from vector to vector are blue, from image to image are yellow, shader to shader green… ect
This could improve visibility.
fusionning the texture editor, world editor, brush editor together as outputs in the shader editor. This may be controversial, but look at lights, they share the same editor as shaders and it work perfectly fine, no need to have a « lights editor » it will require a rethink of how we access the different shaders, i can do a mock up if necessary.
Comments of others about some general node improvements:
Time/Frame node, an idea that could be expanded to a whole Scene info node if needed
“only a marging of users will use (Parallax)”