darrellp

@srekThanks for the feedback! So great to have people who know what they're talking about giving advice to us newbies. I think the keeping of the separate c4d file method I mentioned is working out okay for the time being. I'm sure you guys are more aware by a long shot of how best to move this thing forward than I do so I'll just be happy with the way things work right now.

@MighTI'll stop nagging and start implementing myself. I get that you're anxious to try some other stuff which is great! I'm glad I got you started on something you're enjoying! I'll just make one last point. This is the inner loop as it currently stands: I think that with mine all this would be reduced essentially to a get element, matrix multiply and set element - at least in the innermost loop. There would be a couple more levels of loop and the matrix scaling but that stuff happens above the innermost loop and should represent a miniscule proportion of the time. All the fractal specific groups in your LCV would be replaced by the Matrices array which is produced entirely outside the loop. None of the figuring out which points are drawn between and where their indices are in the array, none of the arithmetic done either here or inside the groups - just that one matrix multiply. I guess I'll go ahead and implement it. I really can't imagine that it wouldn't make things faster. The main question is whether it would make them noticeably faster and like most performance stuff, not really sure until it gets implemented. I'm sorry if I sound lazy and trying to put stuff off on you. Not my intention. Watch now - I'll start implementation and realize some incredibly horrible fatal flaw in my logic and come back with my tail between my legs explaining how bad an idea I had! 🙂 Oh - and finally, I'm not criticizing your code at all. Such great stuff! I'm excited to try my idea out but it'll take a while. I'm kinda half doing this on the back burner and not as dedicated as I probably should be. Have fun with whatever floats your boat at the moment! It's all fun and I love seeing what you're coming up with! You are hereby released from my nagging about this.

Hmm...I think I may not have done a good job of explaining this. Same number of points involved, same size array. The way I was thinking was kinda like recursive programming which doesn't work so well in the nodes world we're dealing with. I think here it has to be done kind of iteratively from the bottom up rather than recursively from the top down. So when you enter, you're doing the zero'th iteration for a line 1/exp length. In psuedo code, for the koch snowflake, here's the algorithm in psuedocode (I think I got indices correct, but maybe I'm off by one somewhere): segLength = 1/exp; // Length of tiniest side in final iteration cPts = 2; // Set up 0 iteration (i.e., two points) array[0] = start point; array[1] = (segLength, 0); Set up Matrices[i] to represent each leg (after the first) of the fractal scaled to a side length of segLength; for each iteration past 0 { // First leg of this side already setup on prev iteration - transform it into remaining legs for i < Matrices.Length() { for (iPt = 0; iPt < cPts - 1; iPt++) { array[cPts + iPt] = Matrices[i] * array[iPt + 1]; } // Prepare the matrix for the next iteration matrix[i] = matrix[i] scaled up by iteration size multiplier; } cPts *= legs on a side + 1; } So you're producing the same number of points one at a time just as before. It's just that they're all produced by some precalculated matrices applied to the previous iteration's points - one transform per point, then put it in the array. It doesn't seem like it could get any faster than that. Since all the translations are coming from a set of points aligned along the X axis (namely, the output from the previous iteration), they only have to be scaled from one iteration to the next - no rotations or translations. The only thing that differentiates one fractal type/parameters from another is the setup of the Matrices array which could be done outside the LCV and passed in. Again, maybe I'm barking up the wrong tree here, but this seems like a faster way and in some ways a simpler way to handle things. It's definitely working backwards to the way you're currently doing where you insert smaller iteration points between larger iteration points. This one appends larger iteration points based on smaller ones. Does this make sense now? If you don't want to try it I may incorporate it when I'm done understanding stuff, but hopefully I've made it clear enough that you can decide better whether it's worth pursuing.

@MighTBTW - I was just thinking that REALLY, the ultimately "correct" way to use transforms would be to use them within a single "line" rather than build an entire line and then make transforms of it outside the LCV. So in the LCV, have another variable being passed which is some representation of the spline from the next level down. I'm not sure what's best for this representation - probably just filling in that portion of the pre-allocated array, but you take that representation and scale it up and translate/move it into place for your current level and return that representation to the next time through the loop. So each iteration step through the LCV would be checking to see if it's iteration 0 in which case you produce the points by hand or if not zero, then setting up a few matrices, looping through all the previous generated points, acting on them with the matrices and placing them properly into the array. Would this be a performance gain? You know your stuff better than I do, but I noticed that some of your new configurations start to chug much earlier than an iteration of 9 so a performance gain might be nice. I think if it were me I'd probably internally put some limits on the iterations which depended on the type of fractal to keep people from effectively crashing C4D. One possible problem might be roundoff error because you're not dividing between well established endpoints but rather generating everything off your smallest iteration but these are 64 bit floats I think so I don't think that should cause a problem.

@MighTI don't mind that much. If you were to build the machinery short of the Geometry Op node into a Primitive Mesh Group it would make life much easier. Essentially, turning it into an asset is pretty much doing that which wouldn't be a problem if there were such a thing as a "Group into X node" rather than just "Group". As it is I have to copy and paste everything into a Primitive Mesh group and then rehook all the inputs and reset their properties which is a bit of a pain. Then I just get a copy of the Primitive Assets Group node and say "Make Asset". So here's a few questions: 1. How to edit assets nicely? Currently, if I make the Mesh Primitive Group an asset, it no longer gives me access to the internals. Instead, I have to edit the asset. Consequently, I copy the MPG and make the copy an asset and then delete the copy which has lost it's internal access but retain the original which still has access. Now I store both the C4D file with the MPG and access to its internals AND the asset. If I want to make changes I load the c4d file, make the changes, toss the old asset, and repeat the process. If there were an easy way to edit the asset directly, I could avoid the hassle of making the copy and then keeping the C4D file around but as far as I can tell, "Edit Asset" is not very practical. Yes, you can edit it but with no direct response on the screen. You have to edit it, save it (overwriting your previous copy), put that asset into your nodes and hook it up to finally see the results of your changes. If things are wrong, you have to go through this whole process again. I would be SO happy for somebody to tell me I'm mistaken here and there's this quite simple way to achieve this kind of workflow but I haven't found it on my own nor seen any demos/tutorials to achieve such a thing. 2. Wouldn't it be better to use radial distribution than the geometry of a constructed n-side? Not that it probably has any serious bearing on performance in this case - it just seems like the philosophically correct thing to do. Is there some advantage to using the n-gon that I'm missing? I'm glad you generalized it though. I was thinking of doing the same but went off and had dinner instead. I need more dedication! 3. How do I add the Parameter Examples to the parameters screen? I think in general, somebody could afford to do a tutorial on the structure of the "Edit Resource" and "Edit Port" dialogs. It's a bit less glamorous than wiring nodes together and seeing cool stuff emerge, but it's still important and as far as I can tell, completely undocumented. 4. Hope you don't mind, but I'm grouping lots of stuff together. It's the way I keep stuff organized in my head. I think of them as subroutines and just as in coding, lots of smaller subroutines is generally more easily understandable (at least for me) than huge swaths of nodes with connections spanning across empty space into far flung regions. I've just barely started getting into all this. Hope you're doing well halfway across the world!

Love your solution @HappyPolygon! These are exactly the sorts of creative ideas that make this sort of thing so much fun!

@MighTSo much fun! Great stuff! I've really enjoyed working back and forth with you also - well, what little I've done/contributed. I look forward to messing around with all this. I'm SO ABSOLUTELY impressed with the L-Systems stuff and anxious to learn from it but for me this was mainly for my own learning experience so I'm happy we've got our own smaller, less ambitious side project going on here also. Thanks for all the cool stuff you're doing!

Super Nice on the L-System Olek. Very impressive! Gonna do a bit of studying now! Thanks!

Thanks Olek - kinda figured. Not that I'm complaining - I know it's a work in progress. Great toy/tool in the meantime and great that you guys are putting it out there for comments. I'm sure it will be a better product in the end for that. Looking forward to 1st release.

I'm assuming C4D is checking for out of bounds but until I get confirmation I can't be 100% certain. But I do know it doesn't expand the array to accommodate the write and messing around with it I haven't seen any bad behavior so I went ahead and implemented as mentioned above. @MighTI also centered it on the origin. This is almost exclusively @MighT's doing. Here's the asset and the test file with all the nodes. Oh - and P.S. - this could probably be optimized further in the One Spline case by just filling the first leg in and then filling the other two legs by just using a couple of matrices to transform the points from the first leg. It works fast enough for me as is though and back at MSFT we used to say "Premature optimization is the root of all evil" so in line with my efforts to remain virtuous, I'm leaving well enough alone in that regard. Koch.zip Koch Test.c4d

@MighTsuggested I start a new topic on our ongoing Koch Snowflake project. My original mailed question to him was why didn't align to spline work with the resulting capsule I had made. I found out through him that there is a Mesh Primitive Group node and a separate Spline Primitive Group node. I have to admit that I wasn't aware of this and that was indeed the problem. So I made it into a Spline Primitive Group and Align To Spline works fine except... The internals of the Curve allocate enough space in an array for one edge of the snowflake and the other edges are created as separate splines transformed from the first. That's the fast and smart way to do things but it causes things like "Align to Spline" to not traverse the entire snowflake. That's not generally what you want so I thought "No problem - I'll just make an optional 'One Spline' boolean which, if false, will use the current faster method and if true will create a single spline". In order to do this I have to allocate a big enough array to hold all the points for all three sides and add a couple of points into that expanded space but I don't want to allocate that large array when the options is turned off. It's easy to use an "if" to make the proper sized array but harder to keep it from adding those two points. The structure of the "if" is to spit out one of two values depending on the conditional - it's not to keep certain operations from actually operating depending on the same conditional. So ideally, I'd like to ignore the size of the array and just "set" the other two elements in it regardless but this would write beyond the end of the array. My experience so far with such things seems to indicate that writing outside of bounds is just ignored and causes no harm. Of course, in most programming languages this is not the case and bad things ensue when you write outside the bounds of an array. If it's not permitted in scene nodes then I'll have to be tricky. I can't exactly "stop" the writes I don't think, but I can make them legally innocuous by changing their values/index to just rewrite the first element of the array instead of writing the elements outside the array bounds. so, in... EXECUTIVE SUMMARY Can I write beyond the bounds of a scene nodes array without worrying about mayhem and chaos erupting shortly thereafter?

@MighTas you pointed out to me - not stupid. I don't know the number of times I've shown people code that I've looked at for hours trying to figure out a bug and the instant you start explaining it, you stop and say "uh oh!". Brains get in ruts and make assumptions that are hard to break out of. Showing it to other people who aren't in the same ruts often breaks the log jam. It was fun figuring it out and you've got some nice stuff in there. The pre-allocation really zips things along. I figured it would but wasn't really that concerned because I hadn't really planned on using it for anything useful. One other thing - I turned it into an asset on my machine and there's one thing I don't quite understand about the UI. I've got the Koch Angle as degrees and in a slider but the sider jumps around to 57.xxx degrees and then up to 114.xxx. I'm thinking it's for some reason using integral radians as the delta instead of degrees. I can't see anywhere to change the delta so my slider is pretty worthless. Any idea on what's going on and how to fix it?

@MighTWell, I think/hope I've figured out the problem. In your LCV you divide the length of the array by the number of segments. For iteration 2, for instance, you were dividing 17 by 4 and using int arithmetic to come up correctly with 4 relying on the roundoff to fix things. However, in the first iteration when the number of segments are 1 you are dividing the array length of 17 (or 5 or whatever) by number of segments (1) and incorrectly coming up with 17 (or 5) because the int arithmetic doesn't have anything to round off. I think the proper thing to do is divide not by the array length and rely on integer roundoff but to divide by (array length - 1) and get the exact answer. Now the first time through you divide 16 by 1 and correctly get 16. Second time you divide 16 by 4 and correctly get 4. I put in a little annotation over the division I'm referring to. It's input has been redirected to come from (array length - 1) rather than (array length). P.S. Another feature I'd love to see is being able to turn of Data inspector in the Inspection window rather than having to search all through all the nodes and do it manually on each one. Koch Test.c4d

Oh duh! I suppose I ought to look before I put something like this up. Just noticed that Expresso provides a "Dynamics Collision" node which provides all the info I need. Well, maybe somebody else will profit by exposing my own ignorance. This is cool! I guess I've never seen anybody use it before and so assumed no such thing existed. Hooray! Collision detection.c4d

@CerberaI had thought about the possibility of doing something in Xpresso like seeing when things were close enough to seem to collide or keeping track of their velocities and seeing then they changed and calling that a collision. For any more than a few items though that might get pretty expensive performancewise though. Actually, you might be able to do it approximately by keeping track of velocities and when their velocities change, call it a collision since that can be checked per object and not per object pair. Also, it would give some sort of estimation on momentum which you could use to judge how loud a collision sound to make so that would probably be the way to go. This seems like something people would run into fairly regularly and somebody would have come up with a solution by now but maybe not. Thanks for the response!

Is there any way to export information regarding dynamic collisions in c4d? I'm mainly curious about how to work out an audio track that automatically tracks with dynamics. If you have pool balls which interact as rigid bodies and you want to have an audio track that makes an audible click for each of their collisions is there any way to do this other than manually? I am curious whether there's some way to export a CSV file with information about each collision - frame, momentum, location, etc.. How to get that into a DAW is a question for another day and another application, but this would be a first step.

Wow - that's great to know! Never seen that before.

Thanks @MighT- I'll definitely keep that in mind.

Ah yes - exactly what I was thinking! Cool! I'm actually thinking of doing some sort of plugin for "mechanisms" - kind of a dynamic system which works exclusively with a select bunch of gears/cams/etc.. It would work deterministically, determining the rotation of all gears involved so that slower more complex dynamics wouldn't have to be involved and all the stuff would just work. I've had the idea for a long time but haven't really knuckled down and did it. It's a pretty ambitious goal but I think one with just gears as a start would still be worthwhile. Still working my way through the intricacies of the SDK. Love your stuff here!

Yeah - nice on the Reuleaux triangles!. I'm thinking of the same triangles as gears between two straight - I don't know what to call them - gear bars? - moving in opposite directions. They'd alternate pivoting on a lower "corner" and on an upper "corner". I'm honestly not sure whether there's some physical mechanism to make that happen - maybe some alternation to the proper teeth on the upper and lower gear bar to "catch" the corners at the proper time - and whether it would look good if there were but it did get me to thinking.

Okay - got it going the way I want it to go. Careful with the iteration count. I haven't taken it to the breaking point yet - only up to 7 where it works fine - but it's an exponential process so there's definitely a breaking point. I only did one side of an equilateral triangle. Doing 3 would be trivial but I've worked long enough on this and learned what there was to learn. My BIG takeaway from this which got really annoying - if you are passing in the wrong types C4D may just throw a bunch of your connections away. Even changing an input type to another of the exact same type, since you are for a millisecond without a type - boom! There goes your connections and you've got to reconnect. I would hope that when this is a commercial product they'll just disable those connections perhaps and display them as red until they've got the right type again at which point they resume normally. Beware! Koch Snowflake in Nodes.c4d

@MighTAh - one final note. I think I see what went wrong because in the process of reorganizing it happened again - when I was hooking things up I got some type stuff hooked up in the WRONG ORDER so that briefly the wrong types were hooked to the inputs of the Koch group at which point C4D silently disconnected my SetElement nodes and so, for reasons I never suspected, chaos ensued. I looked to see if there were any red flashing warnings or even warnings of any kind on the console. It had errors saying essentially "Wrong type" but nothing about "Proceeding to disconnect things you had already put together behind your back". I'm not really much in favor of this sort of behavior.

@MighT - you are SO right! I think I just looked at that array going into the GetElement and that index going in there and the two not agreeing and got so hung up on that "not working" that I didn't bother to look anywhere else. I know I meant to just copy and paste verbatim. Maybe I took them off for testing and then it totally slipped my mind. Not sure. OMG, I'm so embarrassed (as I was afraid I ultimately might be when I put this up!). It still seems odd that things ended up looking this way but I guess it's something weird along the lines of "The array had already been changed which was reflected in the GetElement but the input node still showed the array as it was input". Maybe they cached the input somewhere. Anyway, thanks for pointing out the obvious. I've enjoyed our little conversation.

I’ll double check when I get home. I thought I just copied and pasted that Koch group with no change but it wouldn’t be the first time I’ve massively screwed up something like this. I might have gotten so hung up on what seemed like an inexplicable bug and so convinced that the two Koch groups were identical that I neglected to look elsewhere. Thanks very much for even glancing.

@MighTI took a brief look at yours. Nice. I think you've got an interation loop outside the loop which effects the iteration. I had planned on doing something like that eventually but ran into the above problem first. I think you've got roughly the same idea I did. Nice work!