MighT

@DAST: I came from the other thread. And I apologize, if I implied, you had implied... This was not my intention. I just thought, it would be good to note this in a thread discussing this topic. Sorry.

Apple demands modern applications to be notarized. A binary plugin to be linked dynamically into such host app, needs to meet notarization standards, too. Your supported versions and host OS were sufficiently old enough I assume, so it wasn't an issue for you. This is not Maxon's fault, it's an Apple policy.

Nice addition, Hrvoje. Thanks for the pointer, I actually hadn't noticed them, yet. @CALMCLARITYPEACE: Not sure I would call that end of the pool the deep end. To me sounds more like a bottom less hole, unless you bring some very solid experience in a bunch of areas. I'm not saying this to demotivate you, rather to avoid some frustration. Maybe allow me to throw in some advice: Don't dive into C4D via scripting. At first get some reasonable understanding of C4D and its workflows. Reason is, C4D's SDK/APIs are heavily influenced by the architecture and in a way workflows of the main app. More so than many other DCCs, I think. And many parts of the SDK are way easier to understand (or even searched for), if you have an idea of their real life counterparts. And vice versa, many parts of the SDK seem counterintuitive from a software developers point of view, but somehow make strange sense, when viewed from the user's workflow perspective. And if you need to ask how to "apply" a Python Script in C4D, then I'm even more confident, you'd do yourself a favor to consider above advice. One short answer would be: Use the "Script Manager" (and C4D's excellent help system and documentation). But there are so many more ways to make use of Python in C4D, I'm to lazy to list them all here. Python Generator, Python Tag, Interaction Tag, Xpresso Python node, Python Field,... to name only a few. Up to writing full fletched plugins in Python, many things are possible. Next Fractals and DCCs: You seem to have a knack for the deep end. While fractals are often mathematically simple and algorithmic-wise easy to implement, the resulting number/data sets, shapes or volumes do often have very bad properties for their use or application in DCCs working with vertices and polygons. Take something as simple as a Menger Sponge for example. Doesn't it look simple and clean? Nice, eh? Yet, already with only five or six iterations it's weird mathematical properties make the resulting 3D object of a Menger Sponge a nightmare for DCC like C4D (the number of vertices and polygons rises drastically with every iteration). So, again, I'm not so sure, it's the topic I'd choose to learn swimming. In order to be able to be able to keyframe something like the above Mandel Brot on 2D plane, a Python script (which is basically a one shot fire and forget operation) is not the best approach. In the end I'd probably prefer to go with a dedicated ObjectData plugin (Python Generator is just one simple form of these). Though to a certain extend this could be done with a Python Generator in combination with User Data for the parameters. Maybe also for the Mandel Bulb, though I'm not sure, how well suited the Python generator is, when trying to generate volumes. The actual details can be found in various sources. How to add User Data in C4D's help for example. How to access user data via Python has been discussed multiple times in Plugin Café. Many words and still not sure, I answered your question. Though to my excuse your intentions or goals are still a bit fuzzy for me. Also I think it would be probably a bit too much to ask for an entire "Python for C4D scripting" introduction in a thread like this. Especially as some learning resources have already been linked in this thread. Cheers

I'm sorry, I do not understand the question or what you are looking for. Which effect?

I'm sorry, I do not get it. I downloaded your scene and then did two things (in C4D R21): 1) Simply open the downloaded file 2) Merge the downloaded file into another scene In both cases the camera link seems to be ok. What do you mean by "brakes the 'link' data unit"? Maybe you can tell me, how to differentiate wrong from right? What is supposed to happen? What is not supposed to happen? I'm really a bit too lazy to dig through your entire Xpresso, sorry. And if you do not plan to use any of the cameras in the final rig, then where would the link field point anyway? I'm confused.

I had no time to test this, but I think, the question is, how do you copy or merge this into a new scene? During this process C4D will need to "translate" all links, because afterwards the links will have to point to the copied objects instead of the original ones. If you save your rig into a separate scene and merge this scene via "Merge Project" does it break, too?

I won't take part in this pissing contest and I'm wondering, why it's taking place here. Anyway, I'm wondering even more, if you may want to explain "fully threaded"? Serious question.

Just thinking, but using CallButton() inside a StartUndo()/EndUndo() context could have strange consequences, as it most likely does its own StartUndo()/EndUndo() implicitly. In best case one will simply end up with multiple undo steps, in worst case a corrupted undo stack will be the result. Unfortunately there's no easy way around this (you could do the selections manually) or skip the StartUndo()/EndUndo() calls.

I see the use-case. And I have to admit, parallel Option seems indeed gone. I hadn't checked. But now after doing so, R19 seems the last version, I'm able to make it work with multiple instances running in parallel.

Hm? I don't understand this. What would be the point of having multiple C4D open for normal work? Also given that running an application multiple times is way more inefficient from an OS point of view. And if there really is a use-case for this, well, you can have as many C4D open in parallel as you like, simply using the parallel command line option. Maybe I missed the point...

My assumption is, you may have confused the correct "Object" input port of the cloner in the past (kudos to MAXON for naming the parameter identical to an Object nodes object port), which may have corrupted something. Because whatever you put into the Stream_Spline parameter, it does not appear in the cloner's Object parameter (despite the parameter being shown as driven). Another indicator is second Cloner_Length node with those undefined ports, probably indicating the node no longer refers to the object it was intended for. I removed both Cloner_Length nodes and then re-added one, exposed the _correct_ Object input port and connected it to the Stream_Spline parameter output. Now, the object set in User Data is also correctly reflected in the cloner's Object parameter in Attribute Manager. But I wasn't able to test any further, as I have no idea, nor motivation to think about it, to which parameters of the cloner the other two parameters were connected to (those undefined ports). But I'd say, if you recreate that node as well, it should work as intended again.

Yes, absolutely. 😉 But in general it works and with other parameters actually quite nicely. And it also works the other way round, as you may want to switch off a slider taking too much space in the HUD.

Actually I don't think you need the user data. Simply drag the position onto the viewport. By right-clicking the HUD enable "Display -> Widget" and then use the right click menu to configure it to your needs. Unfortunately you need to do it for every component of the vector separately. Also the size of the HUD does not auto expand. So you need to touch each slider once for it to expand. This by the way also works in the Attribute Manager itself. You can enable sliders there as well. The user data approach mentioned by @Cerbera on the other hand has the big advantage, that you can nicely constrain the slider (HUD uses the same parameters as set for the user data). Which in case of position and rotation parameters with more or less unlimited value range is most likely what you want and need.

Hi, Rokoko has released a plugin to connect Cinema 4D to their motion capturing equipment and software, allowing for live streaming and recording of suit, glove and face motion data directly into Cinema 4D. Download Video introduction Cheers

In any case it would be quite simple to do it with a small script. PM me, if you don't find another solution. Cheers

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) maps a 2D mandelbrot onto a plane. Therefore one needs to have a polygonal (aka made editable) plane selected: test_mandelbrot.py The second creates a Mandelbulb volume: test_mandelbulb.py Cheers

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 Name.Other: #a6e22e Name.Tag: #f92672 Number: #ae81ff Literal: #ae81ff Literal.Date: #e6db74 String: #e6db74 String.Escape: #ae81ff Generic.Deleted: #f92672 Generic.Inserted: #a6e22e Generic.Subheading: #75715e If you give me an example of the current Python scheme (list of colors), I can come up with an proposal tailored more to your needs. Or maybe you PM me the needed config file, so I could set a proposal with minimum effort for you. Cheers

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, which usually just get copy/pasted without any attempt of understanding (no insult to anybody, just an observation).