Exactly where I’m still getting puzzled, you’re not alone
For me it helps to just read those input nodes as attribute names, and not actual data. And trace the stippled parts of the node tree backwards to see where the actual data comes from. But it is kind of hard to wrap your head around, I agree.
Another question:
I tried to make the profile curve for a curve-to-mesh node an input, but blender told me ‘Node group can only have one geometry input.’
There’s probably a technical reason for this?
As a workaround I can create object-info nodes in the tree to get the profile curve, but that’s hard-coded into the node tree and that hurts the re-usability. It would be very nice if an object-info node could be coupled to the parameters shown in the modifier panel somehow, or if you could just add geometry inputs.
It’s weird, I don’t know why. Can’t you create an object input on the group node, though ?
Turns out the object info node has an input socket which my brain completely ignored
Thanks.
A plexus effect, this may be useful for demo purpose.
https://drive.google.com/file/d/1nFldngKjM-ispinORusryzGJy-CFAA6w/view?usp=sharing
https://developer.blender.org/rB8ddfdfd2b2a52f746312246aa3099ab0df8544a0
After this commit yesterday the old Volume to Mesh
node with density
string input becomes legacy. Considering it’s just a simple Sihft S I think instead of me uploading the chocolate donut file again, maybe you can just do it for me? @dfelinto
I noticed something which is slightly surprising to me as a user, though it makes sense to me as a coder if I think about it.
You can create a geometry nodes modifier on a curve object instead of a mesh object. However if you then use Curve to Mesh nodes inside your modifier tree you get a sort of weird hybrid object. It looks like a mesh, behaves like a mesh, but has a curve type. One effect this has is that the material settings are completely ignored.
This is somewhat surprising if you try to add a material to your newly generated object.
Conceptually, some GN trees are very nice to start with a curve input, even though you end up with a mesh object in practice. However, because a modifier cannot change the type of the object I don’t think is is really solvable.
You can of course use a mesh object to attach the three to (though you can’t attach a GN tree created on a curve object to a mesh object, so you’ll have to copy paste stuff into a new GN tree). But this is a bit less elegant in a way, since now you need 2 objects to generate your final result. A mesh object which is more or less ignored/replaced and a curve object to describe what you actually want.
I don’t really know how to actually solve this, but some error/warning message if you output mesh data from a curve based GN tree would be nice since it took me rather long to understand why my material wouldn’t work.
Or should this actually work? And is it ok to have such an object which has a curve type but behaves like a mesh object?
I’m a bit confused…
edit: the material not working appears to be a bug, because after writing this post and alt-tabbing back to blender it now suddenly works!? I’ll investigate if I can reproduce it and do a bugreport if I can. The question if such a curve/mesh hybrid is ok and what are the consequences still stands…
Conceptually, this is normal, and exists for other object types as well. The fundamental change is that an object can evaluate to multiple data types. A mesh object can evaluate to a curve, a volume, a point cloud, instances, or even all of the above at the same time. The type of the object just controls what you see in edit mode.
This is a huge simplification in many cases, and has allowed a much improved workflow, in my opinion anyway. However, since Blender operated under the opposite assumption for so long, it will take a bit longer to teach every aspect of it that an object can evaluate to multiple data types.
The solution to the material problem is just the set material node I think. Maybe some way to copy a material from the list in the curve properties. But personally I don’t really like that-- a curve doesn’t have materials, it’s just a bunch of control points and wire edges.
But curves do have a material, it is displayed when using Extrude or Bevel. This is a common technique used to create stylized hair (or photorealistic hair cards).
That doesn’t work either. Or it ‘sometimes’ works. No difference from without it. Set material node has no effect either.
If I look in the spreadsheet the material index properties are set ok.
I don’t really have a clear picture when it does/doesn’t work yet. As soon as I can really reproduce it I’ll create a bugreport.
Of course! I wasn’t really thinking clearly yesterday evening after scratching my head for an hour
There is a new sample file and we are now officially in Beta
The focus now is bug fixing, so let’s test, test and test
If you encounter any bugs, please report to: https://developer.blender.org/
Ah, I found one source of confusion.
- I think ‘set material’ only works on instances? (not completely sure about this) not on generated mesh data. The manual says that it currenlty only supports mesh data, so I can understand it not working on curves. Apparently blender considers instanced curve objects mesh data. It’s maybe not really a bug, but rather confusing.
- ‘Set material index’ only works for a curve object if I add the material to the object data, and not if I add the material to the curve data. I’d consider this a bug, since for normal beveled/extruded curves I can add the material to the curve data and it just works. I’ll create a bugreport for this.
edit: I think it’s still some caching issue, because reloading stuff makes it work. and changing stuff breaks it again.
The curve itself doesn’t have the material, it’s the generated mesh that has it (displist). With geometry nodes Blender is moving away from curves having integrated meshing to curves that are only curves, but can be beveled by the user more deliberately through the use of dedicated nodes.
I could be mistaken, right now that’s my understanding of it
I agree with @Baardaap and generally I’d say “object types” as they exist in Blender make less and less sense with the kind of flexibility allowed by geonodes
But by default, if you attach a material to a curve, it is attached to the curve (‘data’ in the dropdown) and not to the object (instance). And if you bevel the curve, taht is what is used for the material. The same happens with geonodes. Or should happen, but I’m experiencing some weird heisenbugs where it sometimes works and sometimes doesn’t. I suspect caching ore some sort of memory corruption. I have a switch in my node tree and if I toggle the bool value it starts/stops working, but not consistently. And also different in cycles rendered view vs evee rendered view vs material preview.
Also when having cycles rendered view (but not any of the other view modes) toggling the switch sometimes randomly toggles one of the other switches as well. But not in a debug build, in a debug build it behaves ok. It smells like an uninted mem bug or something.
I’m trying to extract a smaller test case from by bigger file, but so far the bug only happens in the bigger file…
Surely I misunderstood your previous post… I understand the issue now.
What I meant in my reply to Pauan is that curves don’t render, beveled curves (which are meshes) do.
Yes, that’s right. The only detail is that displist no longer fits into that design, any data is either a mesh or a curve. This also gives us the freedom to have more meshing options that can be chosen explicitly. Right now we have the sweeping in the curve to mesh node and the Delaunay triangulation in the fill node, but in the future there might be loft or others.
And to complicate matters it happens on my work machine (with 2 nvidia rtx 2070s) but not on my laptop (intel gfx, so no cuda). Urg. I’ll have to try again at home to see what happens there (single nvidia card).
Hi @dfelinto I posted this yesterday but I am not sure whether you saw it or not
Maybe my wording was not clear, but I was talking about the “chocolate donut” demo file I submitted now contains a legacy node after this commit, so it needs updating. Do you think I should do the Shift S and upload it here again or you can do it for me?
EDIT: Nevermind, I am taking this opportunity to tweak the SSS of the bread to make it look nicer:
Here is the updated file:
Thanks, I uploaded the latest file.