MighT

Edit: The issue described in here got fixed by @darrellp in a post below. So, no more help needed. And thanks to darrellp fixing my stupidity (although I'm pretty sure, the fix won't last long). Ok, I have to admit, this did not go as planned. While cleaning up, I realized I have a bug in here. And I am too stupid to find it. While the performance is quite ok and the result looks good, the internal array is actually garbage... 😢 Anyway... I tried to annotate and comment the setup a bit, so it's hopefully not too bad to find your ways around. Here's the project to play around with: test_nodes_koch_snowflake_2_preallocate.c4d Fixed project file: test_nodes_koch_snowflake_2_preallocate.c4d And this is what it looks like: For any help in finding the bug, I'd be really grateful. Here's some more info about the issue: If one unlimits the Iteration parameter from lower bound 1 to 0, it gets more apparent. Iteration 0 (which is the plain triangle) looks the same as iteration one. What looked like a simple "one off" bug, turned out to be rather strange. Dive into the LCV and "data inspect" the array going in and coming out of the Koch step. Add the ingoing parameters to Data Inspector, too. The ingoing parameters, as well, as the ingoing array look exactly as I expect them. Unfortunately the resulting array does not. It shows the correct result one iteration too late and then funnily shifted to the end of the array. I don't get it. After looking into it like a pig into a clockwork (except most pigs are more intelligent than I am), I gave up and decided to post nevertheless. Maybe somebody can help me...

Quick update: I have a working version with a preallocated array. Now, the performance is more how I'd expect it. Still need to do a bit of cleanup before I post it here. Probably tomorrow.

@darrellp In case you are interested, I can offer some help in my spare time. Be it, you'd like to discuss SDK directly, or coding assistance. Not implying you'd need it, but it sounds like a fun and interesting toy project.

There is nothing to inspect. It is like a Geometry Modifier Group with only one single Extrude node inside, if I am not mistaken. But certain Nodes can directly work in OM as Capsules and this is what happens with the Extrude node.

And that's how one buries looming issues via support... 😞

Don't be. We have all been there. I'm glad I was able to help. Regarding data types: I agree, it's not ideal, if arbitrary connections break. I will forward the idea to Maxon, to keep them in some disabled error state. Be it marked in red or as disabled greyed out connections. In this particular setup I didn't even think to forward the types as you did. I simply setup the Array<Vector> where needed via the small arrow button right of the combo dropdown. It was needed for the LCVs only. Array is in Structure, then unfold the array type and set its containing type. I actually thought, one could also copy and paste the data type (somehow I could swear it was possible in the past). Will forward as a request as well. Anyway, in this way wrong types can not ripple through the entire setup. Edit: I took a moment to report a bunch of things to Maxon. Among the above, I also added a request for somehow marking or highlighting Nodes which do not get executed at all.

@EricNS BEFORE reinstalling, report the issue to Maxon. It's never good to bury issues and loose the ability to reproduce them. Having a way to reproduce helps developers immensely. If you need to continue working, install fresh into another folder.

I took a very brief look into your setup. It's a bit too late for me to debug through. A few minutes later (peeking into your setup, while actually writing the following paragraph)... I think, your setup is actually working. You tricked yourself. In the third Koch step the new points were not connected to the Insert Element nodes. This caused virtually the entire group to be optimized away, thus your Port Inspectors showed zero, because the nodes were never executed. I did not see it right away, but when I enabled the Data Inspector for one of these ports, I got suspicious, because it didn't show anything. Then I started looking for missing connections... It reminds me, though, I need to ask Maxon, if some day we may get Group instances in Scene Nodes (thinking of your Koch Step groups). Maybe they are even there, yet? I know, it is currently already possible by converting a group into an Asset Browser asset and then re-using that asset. But I'd very much like to have a shortcut, where I could add "Instance node" which I can set to reference another group in my setup.

Yep, I started with one level LCV first, until I realized that every iteration of the LCV affected the array right away for the next iteration (duh!!! probably evidence I only come to grips with the concepts very slowly), so when cutting the next line segments my indexes were totally off... it was way easier to wrap my head around with two nested LCVs. The outer iterating the Koch iterations, the inner iterating the line segments of the given Koch iteration.

Sounds like our approaches are similar. Currently looking into the preallocated version, but at the moment some neurons formed into a strange knot, trying to come up the correct array indexes...

@darrellpI found this a nice treat. But I have to admit, instead of looking into yours (spoiler alarm...) and trying to find the problem, I first wanted to build one myself. Sorry! Be a bit careful with the number of iterations! Runtime quickly gets out of hand on my system. I capped the slider at ten iterations, but already six take quite a bit of time here. There are probably faster or more intelligent ways to do it. I think, one approach to optimization would be to work on an array of final size from the beginning. This should only be a bit of arithmetic to calculate the addressed indexes. I bet, this would already help a lot, though. Anyway, here's my solution: test_nodes_koch_snowflake.c4d Maybe tomorrow I find some time to look into your solution. I did not encounter any Data Inspector weirdness, while constructing mine, though.

Just for the fun of it. I took @MODODO's setup and simply merged the four Capsules into one single Geometry Modifier Capsule. Then I animated the height of the landscape from 80/frame 0 to 150/frame 90. I thought, it would be interesting to see, if it makes a difference. As expected, this demonstrates quite well the overhead Capsules create by converting between legacy C4D and Scene Nodes and back. With the original setup I get a playback rate of roughly 1 FPS on my system. With everything merged into a single Capsule I get about 2.7 FPS. Don't get me wrong, this is no critique on MODODO's setup. And there is no ingenuity from my side at all. It was merely a technical test. Here's the merged project file: 22-OK_mododo_landscape_slice_2_andreas.c4d

Hehe, it gets better and better. At first I was a bit lost in translation, here. I really wish, I could understand. The beauty of the symbols alone intrigues me a lot. Edit: Mododo even anticipated me (only me?) being lost in translation and renamed the selection, and replaced above the originally posted scene in above post. The fun change to make it more stable and even simpler: Now, Mododo uses the parametric selections built into Voronoi Fracture. Namely the "Outside Faces" selection, which in this case selects everything, except the two caps (thus the second delete step). Beautiful!!! Edit 2: Why is it more robust, now? Because it no longer depends on the "Select Facing Capsule" to fetch the caps (and only the caps). As this was the problem with Stevijn's own data. It had exactly upward facing polys outside of the caps areas. Edit 3: @MODODO Unfortunately I do not understand, why the second setup also gets rid of the Point Normals Generate Capsule. I understand, you do not feel comfy with English. Maybe somebody else can from the community can help out here and explain it?

@stevijn Did you reduce the Tolerance parameter to 0.0001 on the Select Facing Capsule? I really like this setup. Kudos Mododo. @HappyPolygon The Xpresso only synchronizes the Extrude Capsule's Offset parameter with the Segment Spline. Just so, that the Extrusion happens with the same thickness as the Fracturing. Here's how it works: 1) Voronoi Fracture uses the linear Segment spline to fracture the landscape into slices. 2) Select Facing Capsule then selects all polys with upward facing normals 3) Invert Selection Capsule inverts above selection, so now, basically everything but the top caps of the slices is selected 4) Delete Capsule does as told, so only the top caps of the slices remains 5) Extrude Capsule now extrudes the these caps with the exact same width as the former slices (here the Xpresso kicks in to have the correct parameter) 6) Finally the Point Normals Capsule polishes the terrace look

Holy, 16? Doesn't one need at least 42 monitors, to have enough space for that many? 😉 But I agree completely. While I probably never needed 16 at once, I also like it's flexibility a lot. Also nice for comparing stuff. Serious, 16 sounds to me like a pretty arbitrary number. Sure, a nibble is a wonderfully cute data unit, but I doubt this is the constraining factor here. Should we rather simple to change that limit. Shall we make this into a feature request? Surely nice for marketing: Tim: "Bob, how many Attribute Managers can we have in C4D?" Bob: "In C4D you can not only have one Attribute Manager. Not only two Attribute Managers. Some may say sixteen is enough. But we weren't satisfied. With C4D you can now have 32 Attribute Managers! More than any other DCC in the known universe! And because it's our special-subscription-handy-dandy-Attribute-Manager week we slapped another 32 Attribute Managers on top for free!!!" Tim: "Wow, Bob, that is... 61... almost a gazillion Attribute Managers! Pretty sure, my wife dreamed of having that many Attribute Managers! Now, even our children can have their own Attribute Managers for breakfast. This is soooo awesome." Sorry, got carried away... Edit: To also say something more useful. If we made this indeed into a feature request, we could maybe also ask to get a bit more API access to all of this multi-AM goodness.

I have made Maxon aware of this thread in their internal forum. I'd expect them to get back to this topic in one way or another. It may need a bit of patience, though. I wouldn't expect too much reaction this week for Maxon internal reasons.

Instead of using "Configure Modes" you can also simply lock the mode of an Attribute Manager. See the icons in the top right corner of every Attribute Manager. There's one button to lock the mode and one to lock the element. So, you can choose, to have an Attribute Manager to stay for example in Tool mode or to have an Attribute Manager always showing the Attributes of a specific object.

@kweso While you may not deem my answer satisfying, you should expect the development go the exact opposite direction. As Björn said, Scene Nodes are not an Xpresso replacement. And they are certainly not meant to automate or control the legacy part of C4D. While Maxon made this possible in certain enCapsulated (pun intended) areas, it would be wrong to ask for more (well, it's never wrong to ask, but the answer will most likely not be as desired). In a way, it would be like asking for a F1 engine to work in a VW beetle. You could probably make it work somehow, but it will neither be as fast a dedicated F1 car nor will it hold for very long. The other way round it makes more sense (no, not the beetle engine in an F1 car... I guess, my comparison sucks). To pick up your example, instead expect to your baby stroller to be created and exist in Scene Nodes world in the first place (no, this does not mean, you will need to create it with nodes. I mean, more from a data organization or data structure point of view). As Björn put it, expect it to be in Scene Nodes' (or new core's) scene graph. Then Scene Nodes will unfold their full potential and will eventually allow similar things as Xpresso currently does, too. Then also Xpresso will most likely be phased out (there will be no more legacy world to work onto). But if Scene Nodes or rather the new core had already replaced all major parts of C4D (so all of this could already work), I'm pretty sure Maxon wouldn't call it Tech Preview. Yet, I think, in their confined area, Scene Nodes can do very nice stuff already. It can be a lot of fun to play with. One only needs to understand the border or the "no man's land" between old and new C4D. This is not clearly defined or well documented (tech preview...), also it is a moving target as the new core takes over more and more areas. Capsules did indeed punch quite nice corridors into no man's land, but there will be restrictions to how far this can be driven and they also come at a price (there is quite some overhead to translate back and forth all the time).

I wouldn't go that far. For beginners CallCommand() can be a valid way to automate small things. I wouldn't want to discourage anybody to test waters in this realm. But as soon as one wants to go a little further, it's usually a good idea to evaluate thoroughly, if CallCommand() is needed and a good idea to use. And in the end there remain very valid use cases for CallCommand(), where there is no easy way around using it. A feeling for these decisions comes with experience. Yet, and a reason for my post, one should never forget the downsides of CallCommand() and keep in mind, that it is a crutch, not high art of scripting.

Simply take a look at Cairyn's stuff or the examples provided by Maxon, either on GitHub or in posts from the SDK Team in Plugin Café.

@kweso But you still opted to post a solution potentially dangerous for user's work. 😉 It is actually not a matter of testing. The code will most likely work. Until there comes a project with a suitably deep object hierarchy. The problem with your solution is the stack, it will overflow... Maybe one is lucky and the Python environment will avoid the inevitable crash. Then the script will simply fail in such cases. Not good either, I'd say. The correct way of doing such iteration is to do an iterative loop instead of recursion per level of the hierarchy.

Edit: @kweso has a good point with the "Children" option of the tag. And obviously I took too long to write my answer. Anyway, I wrote it, so here it is anyway... Edit 2: I hope @kweso doesn't mind. But the iterate function is... well, lets say not so good. It's a recursive hierarchy iteration, which kind of proves my point in the last paragraph. Given a "nice" hierarchy it will simply crash C4D. Original post Consider it as the equivalent to one of Cerbera's answers on Polygon modeling. I do not want to imply similar execellency, though. Usually such questions are best asked in Maxon's Plugin Café. Support there is provided by Maxon for free. Community member @Cairyn provides a very nice Python tutorial over at Patreon. There you could learn all you need. Also Maxon provides a bunch of examples over on GitHub. These are also included in the Python SDK download. For your first Python script you already came a long way. In general I'd say it's maybe not the best approach to try to piece it together with "CallCommand()" (reasons below). I was too lazy to look up c4d.CallCommand(465000402) #thought this might work Would have been cool to have a comment, which command it actually is. At first I even doubted you could succeed with "CallCommand()" for the "copy tag to children" part. But after looking it up, I learned, there actually is a command for that as well: c4d.CallCommand(100004777) # Copy Tag to Children So your remaining problem, will be to find the tag(s) (basically loop over them), select them and then call the above command per selected tag. Functions to look up to tackle this: BaseObject.GetFirstTag() BaseObject.GetTag() BaseObject.GetTags() When looking at cloning tags, you need to be aware though, there are also hidden tags... Now, why do I regard this approach as suboptimal? "CallCommand()" basically simulates user clicks to menus and buttons. Consequences are: It can not be guided easily and precisely, nor can it be customized It adds an Undo step per call (so in order to undo only the script you posted above, you already need to press undo five times. And this still ignores, the inserted camera and changed render settings have not even been added to the undo stack. I do get though, in case of importing a new project file, this does not matter too much. Adding to the previous point, mixing "CallCommand()" with your own custom undo handling is usually a bad idea. Your script relies on the imported project to have a very specific structure. If there is only one additional object in there and this object happens to preceed the object you are aiming at, the script will fail. Simulating user clicks, you always need to make sure, you prepare the environment in a way, that such clicks can be successful (objects selected, tags selected,...). There is no feedback. You have no idea if a command failed or the reason thereof. Using an importer via "CallCommand()" you loose the chance for additional workflow optimizations. For example, I's assume, you will always use the same parameters for import. But with "CallCommand()" you have no means to suppress the importer dialog (not talking about the file requester) Probably a few more disadvantages... My advice would be to ditch "CallCommand()" completely for a script like this. Instead: It's easier and more reliable to do the import directly (there's an example for this in Maxon's above linked GitHub repository). Get hold of the actual root object you want to be working with (examples for this can be found all over all places I mentioned) Create the tag manually (you already achieved a similar thing, when creating the camera Insert the tag manually where needed. Depending on the complexity of the hierarchy, this can be a little bit more tricky. But again code snippets doing so are all over the place. Save (bonus) you could then slap a little undo handling on top (bonus) depending on your needs, the imported document wouldn't even need to appear in C4D (just a thinking, because you save in the end, maybe you only want a automatic converter in background Result: Feeling proud of yourself, because you created your own shiny little helper which acts similar to native commands Lastly, the inevitable self advertising: I do such things on "pay what you want" basis. A script like this would be maybe half an hour of work. And you can also book me for 1:1 Python introduction/training. I can already hear: "Why did he write such a long post? Instead he could have simply posted the script!" Yes, I could have, but I prefer people to learn something. And there are way too many shitty scripts out there, which were obviously pieced together via copy/paste without the creator even understanding a single line of what he did. Fascinating for me, the worse such script, the more people like it and the more it gets spread around.

@NWoolridgeWhich obviously shows how little I know about Redshift. If enable Redshift in render settings and click plus in Material Manager, what is this material, that gets created then? Serious question. No irony.

If you switch your render settings to Redshift, the + button on top of the material manager creates a RS Material. And like for any other command in C4D you can also drag a button for this into any palette you deem suitable. The standard shortcut for a new standard material (depending on chosen render engine) is Ctrl-N, but in Customize Palettes you can also assign any shortcut you like to explicitly create a Redshift Material regardless of chosen render engine.

One more thought, do you have a reason to use the Nvidia Studio drivers (like special CAD applications,...)? I have no evidence, but my guts say, the gaming drivers are better tested, nowadays. Simply by a larger user base. Sure, the Studio drivers will certified for certain apps and probably also certain hardware combinations. But in the end that doesn't help much, if you do not have/use any of this. That's what I meant with "so many more options" 😉