jed

I think the answer to the 'tabs show as red arrows' question is that the code was developed in a 3rd party editor that showed tabs in that style, then pasted into Cinema.

I know - it was my attempt at humor, although I'd still like the red arrows tab answer. The only line I understood was if __name__=='__main__': main() Did you know that the guy who invented Python named it after Monty Python's Flying Circus ?

How did you get the red tabs in Python ?

Reverting is one thing, but with new builds you have to be careful. The 7th gen Intels do not play nice with Windows 7 - from Wiki 'Kaby Lake is the first Intel platform to lack official driver support for versions of Windows older than Windows 10'.

The camshaft is jumping a bit. How are you driving the rotation ? I find time node (seconds) > math multiply > Rotation.H (radians) is smooth.

Iteration is really useful for setting up large scenes when you only have a vague idea about dimensions. radii etc. Have a look at this video of 100 staggered pendulums. Working out the lengths + spacing to make a nice curve, connecting all the dynamics, hinges etc would have taken an age - especially if you had to keep trying new variations, but with iteration you can throw together a rough setup and then tweak it 'on the fly'. Scenefile needs a half decent pc to run (has slider for start angle). Might amuse you. https://www.dropbox.com/s/hrjp4arne76qxzp/pendulums.c4d?dl=1

That's iterating 2 sets of 4 items - @degrotepeter wanted 1 output 'has there been any collision with items in the iteration list'.

@Abyss I've a gut feeling there's an easier solution that I'm missing. I think the reason the original setup didn't work is mixing iteration with normal nodes. The linklist is outputting several objects one after the other, but the collision node is a 'static' test. It's like when you hang a result node on some iteration object - you don't see what you expect, you see the last object on the list. A brute force method would be to just have a big page of collision nodes eg this setup detects the sphere colliding with any cube - then scale it up. It's more or less what my Python list method does. I've only dabbled in XPresso Python nodes. There's an area of Python I've yet to learn, where the script manipulates C4D objects and methods by name/ID. I think some nested loops where you could test 'does any object on list #1 collide with any object on list #2' would solve this multiple collision problem.

IIRC I setup the lists with all elements zero at F0, so timeline had to be F0 then F1 or more to make it operate - not necessarily running. The XPresso window calculates once per frame, but moving stuff around also recalculates even when the timeline is stopped. I thought the next question would be 'one blue cube can register collisions with 2 yellows - how to fix ?' After looking at the Wiki page on Conway game, I'll be interested to see where you're going with this.

Try this - uses collision and counts how many outer cubes in the X have been intercepted. Not very elegant ie some repetition, but it seems to work. Timeline either needs to be running, or rewind to F0 then move to F1. https://www.dropbox.com/s/mutqrd5o99d6jy6/collide2.c4d?dl=1

I think you're going to have to learn some coding. If I understand the game, you need to know how many objects are close to one central object. In this file I used distance as the trigger, and made a list with the same number of elements as the surrounding 'swarm'. Then I iterated through the objects writing a 1 for close (and 0 for not close) to the list. Adding the 0's and 1's in the list gives the number closer than the trigger distance. Not sure how this would scale up, but some ideas for you. I put a vibrate on the center object for testing. The script resets at F0, so F must be > 0. https://www.dropbox.com/s/4uc5bhu2j3hhvza/collide.c4d?dl=1

No probs - it's not every day I get to use arccos !

Here's my take on the problem using trig instead of joints. I'll let you sort the symmetry out. https://www.dropbox.com/s/x6nzuqe95f3etqw/door.c4d?dl=1 math for above

Have you tried going thru the mats with object index? In this file it works with 32 mats + objects. https://www.dropbox.com/s/udb6w0lkzxq0y3p/mat_node.c4d?dl=0

You can still buy Spirograph on Ebay. If I had used more teeth on the cogs, there could be more variation in the patterns, but it suffered from strobing. I wanted to see the cogs engaging, so it was a trade-off. Thanks for comments.

Here's something for you to play with - spirograph retro children's toy. Scene file has userdata sliders for speed, size of cog, position of pen in the cog. Due to use of extrudes, it runs a bit slow in the viewport, so I put a boole switch in the control panel to turn these off for testing - or just playing around. The cog automatically lines up when you change the size on the slider. I normally use TR for rendering, but since the scene uses mograph tracer I thought I'd have to do it all on one computer. However, I tried it on TR and it rendered OK. Uses Python - not very complex, but I put some info in the scene zip. Might amuse someone. https://www.dropbox.com/s/erhux1l9jl6uqvz/spirograph.zip?dl=0

The apparently impossible square root of -1 is what mathematicians call the imaginary number i.

I thought today's time-waster might amuse somebody. It's loosely based on a Homer Simson joke. ( pi is lowercase p in the symbol font )

Here's a weird thing - I was working in C4D and saved some info as a text file. My mind was elsewhere, and I forgot where I'd saved it. I did a search using UltraSearch and *.txt, clicking last change to put the results in time order - to find most recent. In the results, bizarrely, I got some C4D files dated 2026 - what's that all about ? See snip -

Glow Orange from GreyscaleGorilla's earlier texture kit.

This animation is based on an animated gif I saw in a newspaper. The pendulums are not dynamic - runs on math. I used hierarchy and reference nodes in the setup, so the scene file may interest iteration users. There's a bit of artistic licence with the wires - in real life they would tangle, but it was just a math exercise (and a bit of fun). simplified scene https://www.dropbox.com/s/5ecouv37imgr1xn/8_pendulum_demo.c4d?dl=0 I have another pendulum video here

One problem with XPresso is the ability to mix n match data types. You can plug an integer into a string etc. I'm sure C4D was just trying to be helpful with this feature, but it can catch you out and give unexpected results - as you have found. Python in C4D is a lot less forgiving with data types - you soon start getting 'was expecting an integer' type error messages if you try using XPresso bad practices. In fact, the reason arturtur's Python worked, but your similar 1st attempt didn't is that he has set the ports to vector where needed, so the math treated the color variable as a vector - in effect saying 'data type vector'. In XPresso, if you hover the mouse over any port, you can see the data type at the bottom of the window.

I think you're mistaken - multiply node must be vector, but you can input a real constant.

I'm guessing that when you got R = G = B, that you were multiplying by a real. Data type vector for the multiply node seems to do the trick - put 1.3 in each of the three fields.

I knew we'd get there in the end.