MighT

I think, you are lacking the correct port IDs? You can find all those IDs in C4D's application folder in subdirectory "resource/modules". For the MoGraph Data node specifically in "resource/modules/mograph/description/gvmograph_data.h". In general MAXON's Plugin Café is a good source for such information. E.g. here on adding ports: https://plugincafe.MAXON.net/topic/6181/6513_getting-data-from-xpresso-nodes Cheers

Would you mind to post some code to illustrate your problem?

I'm afraid I don't understand this question. Procedural workflows for what? Well, one good starting point is definitely MAXON's Plugin Café. There you can get free developer support. Then @Cairyn has a really neat Python tutorial on Patreon. Cineversity also has some Python resources. And there's certainly a lot more I currently forgot. Lastly you could also book a personal Python training. I think Cairyn does something in this direction as well, or you can PM me. Cheers

Sure. I sent an PM

Forgot to mention: For my scripts numpy is not needed. Maybe speed could be improved using numpy, but I didn't bother and leave optimization to somebody else. For the second script to work, a version of C4D supporting volumes is needed obviously. Tested in R21, not sure lower versions would work.

Well, I guess the question was "Can anybody please fix my code?"... There are three main issues with the code posted above: #1: In mandel() function the last return has to be outside/after the for-loop. #2: The coordinates you set on the result object are complete bulls... (sorry). #3: Is a fundamental issue. The Mandelbulb is inherently a volume. Pretty sure, one could map it to the hull of a poly object, but that's not the approach shown in the video. So I won't even try this, but instead came up with the following two scripts. The first (test_mandelbrot)

It's not just one color, but an entire set of colors. Personally I tend to stick to dark themes, like Monokai in Sublime Text 3. There the main colors are for example: background_color: #272822 highlight_color: #49483e Text: #f8f8f2 Comment: #75715e Keyword: #66d9ef Keyword.Namespace: #f92672 Operator: #f92672 Punctuation: #f8f8f2 Name: #f8f8f2 Name.Attribute: #a6e22e Name.Class: #a6e22e Name.Constant: #66d9ef Name.Decorator: #a6e22e Name.Exception: #a6e22e Name.Function: #a6e22e Nam

Hi, I would have another feature request: Would it be possible to change the color scheme for highlighted Python code to something more appealing and useful? Currently when choosing Python highlighting it looks awful, like for example here: So most decide to either have no highlighting or to use a wrong type of highlighting. Neither option is optimal. Cheers, Andreas

Nice. I insist tough, the random module should be initialized with a seed for reproducible results. One more note on this, as it may not be obvious: Such initialization in one Python node is global inside the entire Python tag. This can be helpful, as you'd need to do it only once. But can also lead to unexpected results, if you depend on getting independent randomness in multiple Python nodes.

While I chose to rater comment the setup instead of additional explanation, feel free to ask. Also, while my post got somehow marked as solution, I'd like to stress, Jed's approach is an at least equally good solution, despite all discussion we had about randomness and effectiveness of code. For example it holds the "5-10" frames requirement, I didn't care much about and only mentioned as an possible improvement. I just chose the Xpresso approach, because it had been asked for and usually people are more willing to understand and learn Xpresso setups, rather than Python solutions,

The frames on which the number changes (or when you are freezing the number) change in your code. It has noting to do with the actual numbers shown. Simply uncomment your "print my_list" and select a few objects in Object Manager or do other things. As long as time is at frame zero, the list will be rebuilt and thus change all the time.

I don't think, you got the point. In C4D every randomness is stable. Nobody wants a render to change, just by rendering it twice. If you render frame 42 of an animation. Restart C4D and render frame 42 again, you'd expect an identical result. So, no, it's not a matter of "how random do you want this to be". In your example the result will change, just by hitting render twice. It will even change, just by changing the selection in the OM... In regards to performance: a) I did not compare Xpresso to Python. I only mentioned the inefficient use of a list in Python. b) It's n

Thanks for making me aware of the Freeze node. Never noticed it. It makes the "blue" part of my Xpresso setup a bit easier. The problem I see with the given Python solution: It's not stable. With every new playback (actually every change to the scene while on frame zero, the number will change on different frames. The fix is easy, just initialize Python's random module properly by inserting the following line: ... # make list of frames when output changes if frame == 0: my_list = [0] random.seed(42) ### Init random module for a in range(1, 500)

Here's a little something: test_random_float_text.c4d I have added a bunch of result nodes, so the principle is hopefully not too difficult to comprehend. It could certainly be improved in many ways. Currently it uses a probability for the change, which may violate your 5-10 frames requirement. Or one could add a parameter for the number of digits. Or... The Xpresso setup: I just realize, I used the term "Edge Detection". This has nothing to do with polygon edges. Rather try to imagine the output of the Compare node as a graph (it's

The scene updater plugin won't help. It needs to be run in an older version of C4D. It just automates the process of scanning folders for old scenes and loading/saving those to update them. It was mainly created to help shops like e.g. Turbosquid to convert large amounts of scene files, I think.