jed

I made a version with a manual switch - easier than detecting a slider change. Problem is you don't say what happens to the disconnected ports - your logic needs looking at. There's 2 Python nodes in this file - one sets the unknown ports to zero. Try swapping them out. Some ideas for you anyway. https://www.dropbox.com/s/4y4bic8c0e5cgic/zrotalpha.c4d?dl=1

re Z axis - the pointing null uses its local Z rotation to find the direction to steer with respect to its parent truck, so cab Z must point in same direction of travel. You had a rangemapper doing the conversion, which I suspected was causing problems (as well as the wheels not being aligned with the suspension). re smoothing - by coincidence, smoothing is an interest to me ATM. I have an ongoing project about audio spectrum analyzers (usually incorrectly called graphic equalisers) and smoothing is needed to stop the display being too jerky - current WIP here. Also, when I have cars bouncing around, I like to smooth the camera. Some smoothing examples in the zip file. There's a demo of the XPresso preset Soft Target, which smooths out a pointing obect when the target moves, and works up to a point. I used the code idea to build my own version. Basically it subtracts the output from the input and adds 10% of the difference to the output every frame, so the output approaches the input smoothly. Can be used with data, but works well with a camera. I've included my XPresso and Python versions. Also in the zip, a Python WIP for smoothing music (for the analyzer). This works by making a list whose length is the number of frames you want to average over. Every frame, the music level is added to the end of the list and the 1st item removed, thus keeping the list the same length. Every frame, all items in the list are summed and divided by the number of samples to give the average. I'm still working on this concept. If you've never used Python, have a look at the scripts anyway - there's explanations (of sorts). The zip is 20MB because there's a wav file. https://www.dropbox.com/s/mjukwurgwx2q6vg/smoothdemos.zip?dl=1 edit : for smoothing just using XPresso, I guess you could have a bunch of memory nodes set to 1F, 2F etc, add them and divide for an average

I'm not sure what the title means re interpolation, but I've tweaked the truck a bit. I rotated the cab axis so Z is forwards, and dispensed with the rangemapper for the pointing null. Also the wheels and suspension were a bit out so I aligned them. The suspension was set quite hard, so I softened it and used ride height to compensate. Also lowered custom center of trailer (was rolling on turns). Truck is on a zigzag path in this file to test the steering - seems OK. If you can expand what the title means, I'll have another look at it. https://www.dropbox.com/s/vz01mwm5p1bjibo/cafetruck.c4d?dl=0 edit : have updated the file on Dropbox - better wheel alignment

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.