MighT

There's another frame rate (FPS) parameter in your project settings (Attribute Manager -> Menu Mode -> Project -> Tab Project). Both need to match, to get the number of frames you expect.
 

To be honest, I didn't download the project file. 28MB for a few low-poly poly objects looked a bit over the top for me.
But I'd suspect those Normal tags to be the culprit.
 

It would be quite easy to implement such Tokens.
 
Yet, I think, as Cineversity already has a collection of nice Tokens, there would be a good place to have it added. So, maybe you could try to convince them to quickly add such. If they deny your request, ping me again.
 

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.

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.
 

At least in R25 there's a Mode option on the Object tab. When set to "Spline", the Simple tab gets replaced by a Spline tab , offering the options as seen in your R21 screenshot.

I guess, that's a common misunderstanding of Freeze Transformations. When the feature got released, probably due its name, I also thought it was much more than it actually is. This doesn't mean I want to criticize the feature or downplay its usefulness. For some reason I always thought of it way more complicated than it is (unless I'm sill missing some points).
Freeze Transformation is really only a convenience thing for the user. And I wouldn't limit its use to animation. It can be pretty helpful, when constructing complex static models of many kinds.
It's just a way to hiding information from the user. So you can work with clean coordinates in Attribute Manager regardless of an objects position, scale and rotation in space. But mathematically it doesn't change anything. In the end there's still only one transformation matrix defining an object's PSR. And all the same rules relevant for general coordinates still apply for Freeze Transformation or rather the final result of merged frozen transformation with "normal" transformation. For example scaling: It's rarely a good idea to scale the underlying coordinate system, especially not non uniformly.
 
TL;DR: Freeze Transformation does not change anything, except user's perception of coordinates.
 

Yes, take a look at BaseObject.GetMg(). Global position is the offset vector (Matrix.off) in the returned matrix.
 
General explanation of Matrix may be of interest as well.
 

Ok, now I did take a look at the scene file.
 
To be honest, I am surprised. I even went back into R21 to double check this behavior is neither new nor a bug. And I am really not sure, why I have never noticed this before. Or maybe I have and forgot about it again...

Anyway, what I said in my last post is only half way true (I prefer the positive wording, but of course it was equally half way wrong...). While the Object node is agnostic to the object type, it does indeed not update its ports (or rather the availability of these) depending on the type of the Object passed into its Object input. You are right to create Object nodes from "similar" object types. I somehow still can not believe it and would have sworn this worked, but obviously it doesn't. 😞
 
After loading your scene here, the outputs of the "settings Null" referenced inside the Xgroup did show undefined outputs. I assume they broke, because either the User Data changed somewhere during building the scene. And even more strange, I was not even able to access the port lists of the Object nodes inside the Xgroup. So I rebuilt your Xpresso setup from scratch and it worked, maybe even the way you intended, but I can't judge without knowing the actual goal.
 
Question: Why do you need to pass Object references into the Xgroup? Wouldn't passing the parameters and global positions into the Xgroup work equally well? At least this should salvage all your issues.
 
And lastly lessons learned:
In order to have full and correct parameter access in Object nodes referring to varying objects via their Object input, they indeed need to be created from the correct object type.
Accessing anything but most basic parameters (well, mostly PSR, basically everything from Basic and Coord. tabs) one has to be extremely careful with the setup in order to not break it. Especially because Object nodes seem to be able to break in a non-repairable way, leaving replacing them with new ones as only option.
Double caution in above scenario, if User Data is involved.
 
My feeling remains, this has worked in the past and still hope for an Xpresso guru calling me stupid and telling us about the magic checkbox we have overlooked here.
 

I think, it's called "Inset", now.

I am sorry, but unfortunately I know less Asian languages, than you do English. Even to the extend, that I have to admit to be too stupid to even know, which language is being used on that screenshot. My apologies. But this means, with the higher resolution I am now able to see more clearly, but still fail to understand anything.
On the other hand, I think, I pointed you to the correct classes and their documentation. I really recommend to visit Plugin Café and ask your questions there, maybe with a bit more explanation of what you actually would like to know. And I'd recommend to ask these in English. Aren't there translation services from your language to English (Google Translate, Deepl, whatever) you could maybe put to use? By the way, this is another disadvantage of posting such a screenshot. Even if I wanted to, I wouldn't be able to easily and quickly post this into a translator.
 

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

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 basically a line jumping between False/0 and True/1). It's detecting the rising edge of this graph, so when it jumps from False to True.
 
Cheers