srek

The statistics tell you that the lack of memory does have a negative effect on your performance. The more the Renderer has to work out of core the lower the performance., this can be a very significant drop in speed.

You can read the parameters of an object in the Object Manager, but not via the modeling stack, you need a specific link to the object and use the "Classic Object" node to read the parameters.

What do you want to do? Changes to folder structures etc. are usually done via the operating system, not from within applications, especially scripted operations. Under Windows the Scripting Host offers a lot of power here https://en.wikipedia.org/wiki/Windows_Script_Host

Does the command to remove duplicate materials work? If not please get in contact with Maxon support since it might be a bug. The multiple import is not much of a surprise, afaik there is no function to test if a material already exists in a scene,

Make sure to not use that console option in your daily work, accidentally closing it will immediately kill Cinema4 4D

Using matrices for points wields a lot of power, but at the same time you need four times the memory. That is why usually simple single vector positions are used for anything with a large point count. Even for splines you mostly try to get away with less than a matrix, i.e. broken tangents only increase memory consumption by a factor of two, not three like a matrix. Neutron doesn't change anything here, some things just become a bit more visible than in the past. What Neutron does differently is that you can already attach specific attributes to vertices, where in classic Cinema 4D you have to add tags this kind of information is now a direct part of the geometry information. At this time these attributes are a bit limited, you can only use types that are offered within the Geometry Property Set node. On the other hand, where possible, all modeling operations interpolate/copy those attributes if the topology changes.

You can try to get a bit more information by creating a shortcut to Start Cinema 4D and adding this commandline argument to it "g_console = true" If you start Cinema 4D via the schortcut an extra log window will open that shows more details of the startup process. The last entry before the crash might help identifying the issue.

True random might be less useful than you expect, it will not generate repeatable randomness. Hash will do that. If you want to be closer to true randomness use Hash with the system time as Salt.

Your setup was missing the connection to the Index, but that alone does not fix the problem. There is still an issue with this that i can't pin down yet, sorry. I'll look into this next week and come back to you once i have a solution.

Thanks for that, it seems we have a small problem with the Triangulate node, please find attached a version that does work without it. PolygonSurface 0.0.2.zip

Please find attached a general Polygon Surface asset, just add the ZIP as a database. PolygonSurface.zip

You are on a roll Please find attached a capsule version attached. I did a very slight modifications regarding iterations, but the original setup was absolutely valid. sn_220425_001.c4d

From the Asset Browser drag a Object Group into the AM and double click the icon to open the node editor.

The check for the interruption has to be done within the calculation, otherwise you end up with corruped memory and other not so nice side effects. Calling operating system routines to check for key strokes from within highly optimized simulation code is just freaking slow, those OS functions are meant for interactive use mainly, not during intensive computing. Imagine you are sawing a log and after each stroke you stop, go to the door, check if someone is standing there. If not you go back for the next stroke, rinse repeat. Thats the level of loss in efficiency we talk about.

Esc key should work as well, but it can only be tested for so often without reducing simulation speed substantially.

If you build a capsule for use in the Object Manager the options for instancing will be offered in the attribute manager. If you build a pure scene nodes setup this is handled automatically

Great setup 🙂 I took the liberty of turning it into an Object Group Capsule, this makes it available as a Generator with an AM interface object in the Object Manager. The parameters are mostly named how i found them in your setup. sn_220520_001.c4d

The layout is similar and so is the result, but there is a key difference in how the actual function is evaluated and applied. In Scene Nodes it is a generic approach where basically any field and function can replace the one used, the Geometry Node setup is much more restricted in what it does. I do see some cross over, but most of what makes up Scene Nodes has been defined quite some time before Geometry Nodes saw the light of day. A lot of what you now see in Scene Nodes was already introduced in R20 with Material Nodes four years ago, just applied in a different context now. There are many factors regarding user acceptance and i think a fundamental difference is the makeup of the user base. Currently by far most Cinema 4D users are pro users that make money by using Cinema 4D as a tool. They simply don't have the time to spend on a feature that is not yet final. Many will dabble with it but few will spend any huge amount of time. The Blender community is quite different, there are many people that do have time to spend on developing setups that are not making them any money. I am looking forward to how this develops and i am sure Scene Nodes will show their merrit and power.

Anyone can add to that list by creating an own asset based on the Effector Group. The Effector Op auto adds all assets that are based on the Effector Group to the list of available modifiers. This is a general mechanism used in several places, among them Distributions as well as Spline and Polygon primitives.

Thanks for your view on things. The whole Scene Nodes topic has multiple parts to it that are interconnected. The one that is, by far, the most immature are the Op based graphs. The whole Effector, Cloner, ... Op is pretty much what makes Neutron nodes a Techpreview currently. The modeling on the other hand is pretty mature and imo can be used in production. If you want to have a less experimental and more productive go at Scene Nodes please do so using capsule template nodes to create own geometry related nodes to be used in the object manager.

On the topic of User Data. I would very much disagree. Groups as well as Assets can have UIs that exceed the abilities of User Data. Where User Data is an add on to any object or tagt the UI on Capsule Assets and groups is basically native, but as easy to create as User Data, but much more refineable with the Ressource Editor than User Data. As for comparisons to other node systems, Houdini is a beast on its own, decades of experience shaped it and it is as powerful as it gets. Not for the faint of heart though, it does require a similar level of technical understanding as Scene Nodes do. Blender Geometry nodes have their moments, but they are still missing fundamental concepts that are a core part of Scene Nodes, especially iterations.

Maybe don’t try to think of it as modeling, but the creation of user defined generators and deformers. The big advantage is reusability.

Giving Iterate Collection a few more options is a good idea. Index Output is already on the list, if you have any further ideas you know where to put them 🙂

Regarding Asset Editing. The current options are the neccesary minimum, we are working on improving that experiencer, but personally i do not want to rush it. One way to update assets is to convert the asset to a group, make and test all modifications, then copy the group, edit the asset and paste the group into the asset. Then rewire the input/outputs, ungroup the group and save the new asset version. For this to work you need to tkae a bit of care that the ports on the asset are not dependent on any nodes in the setup (propagated), otherwise they might change names or properties if you ungroup the inner group.

We moved one city over, to Bad Homburg. We really needed the space.