MighT

I'm afraid that's too little information. "A specific scene from a larger scene"? What's that supposed to mean? Only a some objects (including materials) from another project? And which plugin did you try? And why and how did it fail? For the "only some objects" case, I'd open the other project and simply copy and paste the objects in question to the other project.

A bit off topic... 😉 For Affinity Photo I can say pretty difficult, if not impossible currently. They do not even disclose their image file format. I checked a while ago, as I thought about an importer for C4D (just like .psd import). As far as I know, they have no API, which would make something like this possible. And about Photoshop I can't say anything. Not a fan of Adobe, so I never looked at their API. In general it shouldn't be too complicated on C4D's side. It all depends on the API of the target application. Yep 🙂 Edit: Sorry, too short, probably sounds rude. I doubt such an approach could pay off. The amount of work and constant support involved (one would not only need to follow one application's changes, but two of them...) seems insane to me.

Cool. Until Affinity came along, I was a big fan of Inkscape. The update looks nice. I'm wondering, if anybody would be interested in a Live Bridge between Inkscape and C4D and if there would be a market for it. I'm not sure, I think of something like Maxon's Designer bridge. Probably something smaller, more light weight. Basically a way to use Inkscape as an external Spline editor. Complex projects and layouts, I'd leave to importers, at least in a first step.

Thanks! I meant, the number of points vary between the different fractal types and thus more complex fractal types are slower (Koch Snowflake and variations). And the setups never append points, they both work on one large array already containing all points needed for the last iteration. I had hoped, this is what my setup currently would do. One thing is for sure, the way I slapped together the different Koch versions is stupid. Very apparent for the Quadratic Island type... no discussion about that. I simply didn't care about that aspect. I'm far from a math guy. For the Dragon Curve, I'm not sure, it can work backwards. For the Koch types, I do agree, a bunch of calculations could probably be dragged out of the loops. And it could be implemented much more generically. Especially when having an idea (like adding in other types), I tend to copy/paste a lot, instead of taking a step back, rework and then add in on a more solid basis. Depending on personal or general interest, I may then later refactor. The Single Spline option is another example for this. The array preparation is a giant big mess. Nobody needs to look for different words to describe it. I'm not proposing at all, these are optimal solutions. And for sure the posted setups could be optimized further within their sub-optimal approach. I'm learning Scene Nodes on the go, probably just as everyone else. And for sure, when playing around with stuff like this, I tend to come up with my amateurish approaches by iterating on my own stupid ideas, instead of sitting down first, looking for good solutions others have come up with before (and for fractals mathematicians for sure have come up with optimal solutions for all of them). That's what sane people would do. I am not. Partly because for me that's where the fun is. Puzzling around and see, how far I can get on my own, without spoilers, how it is actually done. The sane approach I already have to use, when doing paid jobs. Luckily here it's not. For the moment, I'm more interested to look into different fractals. But if you prefer to thrive for a more optimized solution for maybe the Koch types, I'll be happily coming back to these later on. Please don't get me wrong, I appreciate your thoughts a lot. And I'm thankful for every idea about further optimizations. I may just not jump right away onto every one and try to implement. But I will try to return to Koch eventually. Also these setups can be considered public domain. Everybody is free to modify them. If after modification there is still some part of my work visible, I'd appreciate to be mentioned, but it is by no means mandatory.

Would it make sense, to have something like a Step parameter in Iterate Collection then? Or what would be the best way to iterate over every third element of an array for example? Maybe doing a parallel Index Iterator and then bypassing calculations for indexes not needed?

I'd just like to express my sadness, that this had to turn into one of these threads again. Even more so, as it seems to have the inevitable outcome. May I assume, it was Thanulee's intention to hurt this community. It's hard to read some of these posts in any other way. Very unfortunate, a helping hand got burned. And it's not like we have an abundance of helping hands in here... 😞 May I ask, if anybody is still wondering, why Maxon people are so rarely getting into contact with the outer world?

This is mainly not because, the setup got slower, but because the amount of points rises immensely. Take for example the Quadratic Island, that's 17 new points per step instead of just one for the basic Koch Snowflake. I'm not sure I understand this. Would you mind to try to build a mock-up? The problem with the flattened corners is, you need to know already about the following segment, in order to correctly flatten it. And you also need the non flattened position to properly iterate. I think, there are two easier and probably speedier ways to approach this. If you look at the Heighway Dragon Curve in Wikipedia, the first way shown way to construct is, is actually by cloning and rotating the previous iteration. Would be interesting to try this approach. I instead chose the other, as I think, one key to performance here, is to allocate all needed memory in one step at the beginning. I'm not sure the incremental allocation and possible connect steps would perform that well. But I may well be mistaken. Pick up the ball, even if it turns out slower, we would have learned something. While I am currently playing around with Koch Cubes trying to get a single mesh version in a reasonable amount of time...

To be honest, I have not played around with asset packaging. But I think, Maxon does not consider this process final, yet. I also already filed a few ideas in this area. I think, they actually do not really want to encourage people to package scene nodes assets. I may be mistaken. But it's still a tech preview and many things are changing from one release to another. Thus assets tend to break. For example these Koch setups, I doubt, they would work in R25. Haven't tried, just a feeling in my guts. If you have precise ideas, of how workflows should look like, I'd happily forward stuff for you. Or, you could consider to apply as a beta tester yourself. Not sure, where that's done, though. Sure, absolutely right. In its current state, that is. My intention is to actually user to pass arbitrary splines and map onto them. These are just read only string parameters/ports and the displayed parameters are their default values. Unfortunately I ran into a bunch of current issues and limitations with this. At first I wanted these to be displayed in a multiline string widget. But unfortunately one can not have a multiline default string at the moment. So I went with separate single line string parameters. But then (and this is current state) it got really apparent, that it is currently not possible to hide these from the list of ports appearing in the Node Editor. I could do at least an introduction to the Resource Editor (you are aware, there's at least a chapter in Help?), but that's boring. Not the Resource Editor itself, but doing such tutorial. I doubt, I would have the motivation to do so for free. Some incentive would be needed. It could already help, if I did not have the feeling to do this for free for only a single person. Not at all. Go ahead. Only keep in mind, I may not be done, yet... I do not group that much, because a) as you also mentioned, it is currently a bit tedious to move stuff in and out of groups and b) while not knowing, where I want to end up, it's faster for me to think and iterate.

You are most likely right with suspecting execution priorities. If an animation is not jumping back to start with a single click on "Go to Start", but only after second or even more clicks, it's almost always a hint, something is fishy with execution order. Maybe I have a solution, though I have not deeply analyzed your setup. Yet, to me the result looks better. The Xpresso tag on your "target rig". Increase its priority from "Expression/0" by one to "Expression/1". Happy roping.

@OleKIs there a functional or performance difference, either using these two parallel iterator nodes or using an Index Iterator in combination with a Get Element node?

@darrellpActually I meant to open a new topic for the Align to Spline issue, but that seems to be already solved. Anyway, now, we are here, I'll link the other thread to this one. Thanks for packaging the Koch Snowflake into a Capsule and making it an asset. I'm afraid in meanwhile I had moved on a bit here. I hope you don't mind to do the packaging once more. 😉 I have to say, I really enjoy this. Not only the fractal topic, but this mutual idea process. I picked up the idea of the One Spline option and also centering of the snowflake. These two in combination lead to the next idea and you will see, I chose a bit different approach to achieve this... Before going on, I need to emphasize, of course @OleK's L-system approach is of course the more scientific and way more versatile approach to such fractals. Also Ole is way more proficient in Scene Nodes, than I will ever be. I really recommend to dive into his L-System setup (see other thread at the end). If there are Scene Node setups to learn from, then Ole's. I hope Björn, Hrvoje and Mododo forgive me. Each of them has already shown very neat setups on their own and there's much to learn from these as well. I hope Björn and Hrvoje at least agree, that's more a Yoda/Luke situation we have here... Nevertheless I stuck with my poor man's approach for the following reasons: Mainly because in it's current state it performs a bit better than the L-system. But that does not mean, the L-system couldn't be brought up to speed as well. Pretty sure it can. But I leave that to Ole. I wanted to play with Scene Nodes and work with the editor, so simply using the ready made L-system was too boring. I'm stubborn. That said, here's a new version: test_nodes_koch_fractals_2.c4d It now supports a few new variations from Koch Snowflake It supports a bunch of different shapes Darrelp's One spline mode There's an example of a conditionally enabled parameter (see Single Spline param in Resource Editor) @darrellp I'm not sure, if it's a good idea to write beyond arrays. The system seems reasonably robust in this regard, but I agree with you, one can not be sure. So, rather safe than sorry. I hope my setup behaves well in this regard. To prove that nerds are like cruise ships (once picked up speed, it's a bit difficult to brake), I created another setup for a Dragon Curve: test_scene_nodes_dragon_curve_2.c4d My approach to the flattened corners of the dragon curve is a bit cumbersome and awkward. If one used the copy/rotation approach of building it, it would probably be easier. With my dissecting approach, well, I have the feeling, it's not a really good solution. Would be cool to see different approaches. I hope, someone has as much fun with these fractals as I (and probably darrellp) currently have... Edit: I had messed up the link to the other thread. Now corrected links below. Lastly the first thread on Koch Snowflakes: In this thread one finds Ole's L-system setup:

Edit: Sorry, I posted this in the wrong thread. @darrellphas created a new thread for the Koch Snowflake, so I will continue with my new version there:

Sorry, I probably overlooked you mentioning the direct way to documentation. I haven't tested, yet, as I am mostly in Nodes layout at the moment. But if this indeed fails in Standard layout, that's bad and should be reported as a bug to Maxon. I will probably test later on, but it surely wouldn't hurt, if you reported it, too. Edit: I can not directly reproduce it. If I have a Select Capsule in OM. Regardless of layout (Standard or Nodes) and also regardless of OM mode (Object or Nodes) the context menu of Selection String in AM sends me directly to the Selection Node's input description. Not saying, I do not believe you, @bezo, but there must be some other variable influencing this behavior. Not related to above bug description, but the direct way also fails for a few node types currently not yet documented.

... or right click the Selection String parameter in Attribute Manager and choose "Help"

@HappyPolygonIt sounds more official than it is. Normally a segment gets divided into equal thirds (thus 3 is default), with the middle third being the "new nose". The "Koch Divider" (name is copyright by me, it has absolutely no scientific background) simply changes this divide. It does not divide into more segments. But it changes the length of the new segments. So, if you set it to four, the line will be divided into one segment of quarter length and as my algo simply reuses this length then a nose segment of quarter length and then the rest. So position and size of the "nose" is influenced by this stupid parameter. It was just a result of me playing around and I thought, changing this value also produced some fun variants. It doesn't even behave "correctly" in the entire value range. So it really is a bogus parameter, which nevertheless can produce some interesting results. The behavior is easiest to see, if you go to iteration one and play with the value.

@Cairyn let me know, if you want me to test specific scenarios. At best send me a prepared scene file to test.

It does not need to be Store Selection, necessarily. That's only needed, if you have a use case for the stored selection further down the line. Otherwise the Selection node does the trick as well. In my mind, it's like initializing the default or active selection. I'm aware, the point here was to demonstrate the named selections. Yet, I'd like to mention, in such case it is not needed. I guess, it's always good to know options: I already posted a feature request, that we get a dropdown button to set the predefined selection names (default, all, odd, even,...). And, because I stumble across it, it is terribly easy to forget the quotation marks, when referencing named selections. I really hope, Maxon will find a better way. Maybe simply fall back and try if there's a named selection, if the entered string is not a predefined selection name. Or maybe the other way round, have the predefined names start with a $ or something, so that the custom named selections can be referenced directly. But in the end, that's probably only my personal preference and problem.

Oh, actually I did test this more for Cairyn, who mentioned not having access to R25/S26 and wasn't able to test himself.

Maybe I shouldn't have done a normal extrude, which complicates the setup quite a bit. But I thought, it would be more interesting.

For what it's worth, I gave HoRope a very quick spin in R26 (26.014). As far as I can tell, all parameters work and behave. And the resulting setup seems to work. Most likely as expected, but without anything to compare to, I can't say for sure. No warnings or errors are thrown on Python Console.

@bentrajeSorry, it took a bit, I was busy otherwise. Here's a Geometry Modifier Capsule, which does a manual normal extrude with offset and variation parameter: test_scene_nodes_manual_extrude_variable_offset.c4d Please note, I'm not saying Maxon does it exactly this way. But it's one way to do it. Edit: One more note: You will find I use an actual Extrude node in my setup. This is because, currently we are lacking some smooth tools to create new topology. You can do it, but it gets tedious rather quickly. So, I instead misused the Extrude node, to provide the topology needed for the extrusion, but looking at the setup, you will see, it is not doing the actual extrusion (it's offset is set to zero). So, it's a bit of cheating, but it's cheating before the actual core of the question asked, how to do the "offset" and "offset variation".

@darrellpIn the UI section of the Resource Editor at the end there's the step size for the slider. On mine I set it to pi/180 (as always you can use formulas in all numeric edit fields in C4D). Edit: I forgot: In Resource Editor, you need to set "Gui Type ID" to net.maxon.ui.number to get the slider parameters (and thus step parameter).

Yes, me as well. And I already posted my request to Maxon.

@darrellpThanks so much! I knew it was stupid! I was looking at these exact nodes quite a while. Blind as a mole... I added a fixed project file to my post above.

We have just released a small update to version 1.1. And we also fixed the demo version not being available for free... (duh!). The update is of course free. Existing customers will be notified by email and in Asset Juggler Discord. The demo version can also be used to update. Changes: Added: Options to use normal Instances instead of Render Instances for Live-Preview and Baking (useful, if Hair or other features incompatible with Render Instances is involved). Added: Added Texture tag options in Material and Material Override Groups configuration. Note: Also see Asset Group on hidden function of Material layer link field! Added: Report prepared for Cardano Added: Button to Lock None to Zero for all groups at once. Fixed: Asset Group and Rules tabs not correctly restoring their enabled state. Manual: New features, added notes, added parameter defaults and did inevitable corrections.