I would also hope that Geometry Nodes eventually lets one split off data and later merge it in, and if you find @JuanGea and some comments he made earlier (in this thread??), I think that he was also wanting that. Even if it is him repeating himself, I would be interested to hear what his response to your post above would be after the development of T85655.
Just throwing my own 2 cents in here too:
I know itās not always the best to talk about other software, but seeing as Houdini, like Blender, has an attribute based system it is very interesting to see how they are similar/dissimilar. In Houdini there is also a āAttribute Processorā node, and I can tell you now that it is what is used more compared to the standard attribute nodes in houdini. Way more. It doesnāt mean the standard attribute nodes are not useful, we need them, but they are most useful for smaller tasks, where as the Attribute Processor node would be for, well:
I think this is perfectly summed up by the pretty well in T85655ās notes:
āWhile the attribute workflow is a powerful way to do complex operations, and its generality will make it useful in a lot of situations, but common feedback is that node trees will become very linear, because temporary values must be stored in attributes, rather than passed around with node links.ā
The Attribute Processor in Blender should make things
- A lot cleaner to store big trees
- Easier to read the āflowā
- Feel more āhands onā in mapping attribute to attribute
I think right now because we only have the individual attribute nodes, obviously we have no choice but to use them, but once we get the Attribute Processor I think the workflow will shift to using it more, and the attribute nodes for smaller operations.
As for whether the attributes should be always bound to geometry or not, Iām still of the opinion that they should be attached. Iām not going to put words in the mouths of the developers, but I do dream big, and I really hope we can get dynamics in the same space as geometry nodes, I want to plug in my procedurally made stuff into a rigid body solver, or a liquid simulation, or what have you. I want to plug my character right into a hair node and do it right there. I think having a ālinearā system might make it easier. Maybe thinking way way too far ahead, but one can hope.
4 Likes
I totally understand your concern, I am familiar with sverchok and have given it a go in the past, but Iām not NEARLY as versed as you in it, and evidently took more of a liking to the attribute style workflow. The nice thing is that blender doesnāt have to be exactly like other specific programs, and as this is in early development still has lots of room for improvements on other systems. All I can say is that I do not feel constrained in Houdini, and most anything one could do in sverchok I feel confident I could pull off. Of course anyone would say that about their own personal daily drivers, but you know what I mean. I just makes me more curious about how you think doors will be closed on certain aspects for modelling/animation/motion graphics etc.
I think an aspect of sverchok that is nice is being able to access things like, verts, edges faces, edge centers super easily and carrying out operations on them. But a lot of these things can be done with grouping and filtering nodes. I think we might have to wait for the procedural modelling to start rolling in for more enlightenment in this regard. But if you had time I really would be more curious in knowing your thoughts and specifically why the attribute system feels limiting to you, at least in itās current state.
3 Likes
Quick question about custom attributes in Cycles. Right now they work well on original geometry of the object that has GN modifier, but doesnāt work with point instances. So is this not supported yet or do I need to do something specific to use attributes from instances in Cycles materials?
Could we use the Geometry Nodes momentum to implement a āāComment Nodeāā ?
Hi there,
With the long term goal of pushing Blender toward Everthing Node with the Geometry Nodes, Shader Nodes, Particle Nodes, do you think it could be beneficial to implement a commenting node ?
I have downloaded a lot of procedural shaders over the internet on many Blender related website and I think that many of them could benefic from some sort of comments.
- The Frame node can be use make comments, but I didnāt see any shaders that use that fonction. Only they use Frame Node to make title as : āāroughnessāā / āādisplacementāā ectā¦
- Using Frame node to comment a node group is not obvious to the user and Iām sure a lot of user doesnāt know of that possibility
- The process is also not obvious : You have to make a frame node, create a text inside the Text Editor and assign that text to the Frame inside the āāpropertiesāā sub-menu, which is hidden by default
Sure, you can always make comment this way :
- With the annotate tool, but not everyone have access to a tablet and writing with a mouse is hard
- Inside the forum where you have put the link of your shader/blend file, but if the file is distributed elsewhere, comment will be lost
- Inside a youtube video, but again, comment are āālinkāā to the videoā¦
- Also, a lot of time people make screenshoot of their node with comment over it (done in Paint or something) make the node graph low res and hard to read. So you can read the comment but not the node anymore.
Having a commenting node could have these benefits :
- If would make it easier for well documented node setup to be understood by new user
- Tutorial makers could use it to comment their node setup
- New and advance user could use it to comment their node setup and remember what node are doing what when you open your file a few days, weeks or months later
- Commenting node would be easier to setup than linking a text to a frame node
There was already talk about it : BlenderArtists & StackExchange
And this very interesting addon (seem outdated) : Blender Community
Not sure what some Blender Dev think about this, or some experienced node user as @Erindale ?
22 Likes
I think a commenting node would be great! Even just a frame with a text input field in the N panel would suffice for me I think. Iāve used frames a lot for commenting things and but they also have an issue with text scaling so long paragraphs can be cut off when zoomed in/out. A lot more nodes will be shared moving forward so commenting would be a cool one for someone to pick up. Could be a good one as a community node as it doesnāt effect the functionality, just a bit of polish!
2 Likes
Completely agree with you @Erindale regarding the Number of attributes that one generates within a single node tree.
But I do like the idea of having an attribute Processor. But I am more lenient towards the idea of Splitting away from the geometry socket and later merging it. Just like how we can separate vectors into scalers we can sure separate geometry to Attributes ri8?
@HooglyBoogly I saw on Curve Support in Geometry Nodes - HackMD that you were talking about curve implementation. This is awesome! I was wondering about the available attributes:
Back in 2019 @OmarEmaraDev was working on improvement to Cycles/Eevee, and one of the things he wanted to make was a ācurve info nodeā for the shader editor. Unfortunately he ran out of time, and mentioned that the curve code is kind of confusing, which seems to be a repeating sentiment. Anyways, it would have included information like the CurveU, tangent etc. I particularly wish we had CurveU, because we canāt accurately map texture on curves because are only options are generated coordinates or object coordinates, both of which wonāt really follow the curve. I was reminded of this today when I was making a rush edit for a client because they wanted to add a rainbow, and I was reminded that you pretty much have to make it a mesh so you can use UV coordinates rather than a curve.
I wonder, would it be possible to add CurveU? Maybe we donāt need a curve info node per say, but it would be nice to output it from geometry nodes and use it in the attribute node in the shader editor. Tangent is also very welcome, both are very helpful for procedural modelling!
3 Likes
Unfortunately this was discussed many times before. Splitting attributes from their geometry only makes sense at an intuition surface level without understanding what attributes actually are.
You can find the discussion about this further up in the thread but to sum it up: attributes are not just values but are deeply tied to the geometry and thus have specific requirements.
You can āseparate attributes from (components in) gemetry (sets)ā into seperate arrays when actually programming the geometry nodes in C++. There are dragons about: once you do it is your responsibility to make sure the topology and other attribute containers are zipped in sync. If you make a mistake and create a malformed geometry set you are in for a fun time debugging some obscure memory corruption errors deep inside of a call stack further down the road.
Even if the catastrophic crashes were safety proofed and memory access was made water tight it would still be painful to constantly adhere to these requirements for users and at the end of the day it would not be very useful. It is for this reason we provide an useful interface to the user to manipulate attributes in useful ways while ensuring everything messy is taken care of behind the scenes.
4 Likes
Yeah frame nodes could use a little more flexibility so that we can actually wrap text inside of them. In-editor text editing would be nice also !
2 Likes
Getting curve radius would be awesome as well. Iāve had projects in the past that would have greatly benefited from that.
1 Like
I think having a U value for curves in the shader editor is a slightly different topic. At least only tangentially related to supporting them in geometry nodes. Honestly itās a lot easier for me to think about the change if I donāt try to think about adding new features at the same time. Though I have no doubt that having curves available and generalized enough to work with attributes will allow many new things.
1 Like
Distributing points in volumes should now be usable if anyone wants to try out the patch and offer feedback
(it is still a work in progress): https://developer.blender.org/D10506
8 Likes
I set up a nice simple and performant camera culling node group (and LOD tools etc theyāre up on gumroad) but I wanted to share this culling method as I know @BD3D and others were trying stuff. You can see (a bit compressed) in the video the scene is running real time even with a pretty high density distribution.
This method doesnāt rely on having any geo or using dynamic paint etc. It just checks if the points are a 0 or 1 after putting them through min( (m*abs(x)-z), (m*abs(y)-z) ) > 0.
Basically just a square pyramid. You also have to do some vector rotation to adjust for camera rotation and also translation. I made an Attribute Vector Rotate node group to do this but that would be a great node to include if itās not already planned. Iāve not noticed any issues with my Euler rotations so far but even just the number of attribute names it used (23) to do the full transform is potentially troublesome when we start being able to search.
18 Likes
Impressive node maths 
I started looking at that technique originally - but the complexity freaked me out and I didnāt think it would be performant enough.
Iām guessing transforming the geometry should be faster for Geometry Nodes because itās a built-in function. However to do a comparison, Iād have to implement top/bottom clipping.
Why is there an X/Y resolution passed into the group - how is that used? (Perhaps used for the camera aspect ratio only.)
1 Like
(Here is the file) badIdea_vol_points.blend - Google Drive
(Requires the Point Distribute Volume build)
7 Likes
With a proper attribute vector rotation node, this method would be super simple actually. It really is just y=mx but dressed up a bit. I started off with trying SDFs but that was a lot less performant.
The field of view is calculated as the diagonal of a square and then the aspect ratio is just cropped out of that. I could have cut my losses and just made it square all the time but I thought it would be more performant if I could cull right up to the view boundary. All it does is does X/Y and Y/X and if X>Y then it will multiply the field of view by Y/X going to the Y calculations and if Y>X, FOV*(X/Y) to the X calculations.
Keeping close to the view boundary lets you have some fun as well because just before creating a the mask to separate points I have a region attribute that is 0 at the view edge and increases towards the centre so I could have things eg scale or rotate depending on how close to the edge of my view they are.
Really Nice work @Erindale just purchase your stuff, whatās the nodegroup licenses?
Unfortunately that also shows the downside of using a lot of nodes with a lot of points, if thereās a massive amount of points and the instancing is not that intensive on the OpenGL viewport we can start to see the slowdowns from the nodegroup directly due to the heavy ammount of math nodes.
Maybe T85655: Attribute Processor for UX improvement will be more performant when doing a lot of math? 
Still eager to try out proximity by volume (or negative distance) with a frustrum mesh!
Also Iām not sure that distance driven LOD is of any use when using cycles. as cycles can handle instances extremely well with almost no impact on rendertime
1 Like
I think I put them as CC but youāre welcome to use/dissect in any capacity. Iād just rather avoid people changing the name and reselling with no alterations.
I didnāt realise cycles was so well optimised for instances. Do they help with eevee? I have some larger animation projects I was thinking Iād use it for.
The heavy maths is mainly the Attribute Vector Rotate node so either a native VR node or the processor would be a big improvement definitely
Yes it should drastically help in rasterization
But in another hand eevee is not the best rendering solution for environmental rendering, which is where distance driven LOD are the most useful
1 Like