jed

Sorry - I made an error with the fixed car. Will upload another version shortly. I think I scaled the car too large - I'm used to seeing cars in Z direction, so was looking at wrong axis. BRB. try this one https://www.dropbox.com/s/b0e1x6idxowjz5n/fixedcar2.c4d?dl=1

I'm not sure which file is which, but I fixed the car you first uploaded. I put the motors etc inside the car and scaled it up to real car size ie about 3m. C4D car stuff works better with lifelike car sizes. I lowered the center of gravity (custom center) so car doesn't roll on corners. I put the suspension different front/back because the car's heavier at the back. Your wheels are too round - no surface area for friction. If you need the tyres that shape, use hidden proxy dynamic wheels with the visible ones as children. Anyhow, the car now drives. Moral of the story - put motors etc where they are in real cars. When did you last see a car with an engine inside each wheel ? Cinema does its best to imitate real physics, so should you. https://www.dropbox.com/s/clwmzo7ratye1fz/fixedcar.c4d?dl=1

It's always a good idea to post your 'problem' files here for people to have a look at. There's a Cafe size limit, but you can leave out images etc to keep the filesize down. Also C4D files compress quite a lot with WinZip. Failing that, use DropBox or similar. I've tried in the past to get dynamic cars to drift, eg by keyframing friction for less grip at certain points, but have never had much success. Although C4D dynamic cars are a lot of fun, sometimes you've got to animate with keyframes, splines etc to get what you want. There's XPresso methods to rotate (non dynamic) car wheels correctly - driven by car position - so you just move the car on a spline and the wheels turn realistically.

Some of my Minis having a race

You seem to have the motors and suspension as children of the wheels. In a real car the motors and suspension are in the car body, and should also be in your scene. See zip file for 3 examples of how I rig cars. There's a car with manual steer and a car that follows an object (so has auto steer). These are just made from cubes etc. See the Mini car for how I rig a real car model. I don't make the actual model dynamic, but use primitive cubes, cylinders and put the dynamic tags on these. The hi-polygon model parts are children of the simple car. This makes the car drive better. The Mini file has a view switch so you can see the dynamic car underneath the real one. https://www.dropbox.com/s/lxmc6fhzwu2mbl7/3cars.zip?dl=1

I see it now - if time == previous, do not add to rotation (when clicking in viewport) if time < previous, subtract from rotation if time > previous, add to rotation took me a while to work out when time < previous == true > scrub the timeline - D'OH ! as Homer would say did @Gregor get his flipboard sorted ?

Not sure what you mean by this. I had a look at the file from CG, and although it does turn I haven't got the time to analyse his math, so I can't really comment on his work. One thing that really frustrates me is when folk post an XPresso solution without an explanation. I know it's difficult to guess the ability of the person reading a comment and to pitch an explanation at the right level, but too many remark boxes is better than none at all. I put comments on my own XP and Python, to jog my memory when reusing stuff 6 months down the line - I'm sure you do. This thread has been hijacked . . .

When generating rotation by a simple multiplication, say frames A and a multiplication factor of B (for degrees), the total rotation at any frame is rotation angle = A * B degrees (could be using time secs, but it's the same math) If B is constant, the total rotation increases linear with time (frames) ie at a constant speed. Say you were at 50 frames (A) with multiplication factor (B) of 10 degrees, the total rotation is A * B = 50 * 10 = 500 degrees at F51 A * B = 51 * 10 = 510 deg etc But if at F50, you try to slow down the rotation speed by dropping B to 9 degrees (B keyframed 10 at F50 and 9 at F51), the total rotation at F51 is A * B = 51 * 9 = 459 degrees so the object has gone backwards ! (this is your glitch) whereas my method of adding a smaller value in that frame, still goes forward. If I was generating rotation by adding 10 degrees per frame, the rotation is angle at F50 = 500 degrees then I lower the speed to 9 angle at F51 = 509 degrees angle at F52 = 518 degrees > still going forward, but slower Simplifying this using linear speed - if an object is at 100m and after 1 sec it is at 105m, its speed is 5 m/s ie 5 is the change in the existing value in one second. When the object is at 200m, 1 sec later (if still going at the same speed) it will be at 205m. The speed is the change per unit of time - the distance increases by the same amount ie 5m in 1s. With my 'addition method' of generating rotation speed, the time unit is 1F and I'm adding a set value every time unit - 1F or 1/30 sec. If I want to vary the speed by changing the amount added per frame, I'm adding to the existing rotation. If I add a smaller amount, the object goes a bit slower - not backwards. If I add the same amount every frame, it has constant speed, if I add a larger value every frame it goes faster. If I add zero - it stops. TLDR version > speed is the rate of change per unit of time. edit : see demo of linear speed by addition https://www.dropbox.com/s/7znmbmo7c0zu0y7/demospeed.c4d?dl=1

Maybe not relevant to the flip display issue, but here's a little trick of mine to get varying rotation speed without glitches. Using time + multiply is fine for constant speed, but if you generate rotation by adding a small amount every frame, you can change the amount added and get smooth speed changes. There's a rotation reset @ F0, otherwise the rotation value persists. Also, since this is an addition, any viewport activity (moving stuff or just clicking) when F > 0 will cause the XP to recalculate and rotate the object 1 step - but realigns when timeline is rewound to F0. I used radians in the XPresso to save unnecessary degree conversion. https://www.dropbox.com/s/bx6ibid34colx2x/addrotate.c4d?dl=1 method works well with helicopter rotors if amount added keyframed https://www.dropbox.com/s/azjzi3lnr7f794q/chopper.c4d?dl=1

The problem is that you don't understand trig and how the sin function is symmetrical around 90 deg eg sin(30) = sin(150) = 0.5 in fact, there's a lot more than 2 solutions to x = asin(0.5) eg . . .-690, -570, -330, -210, 30, 150, 390, 510, 750 . . . etc try it on your calculator The only way you can differentiate asin(0.5) to be either 30 or 150 deg (or whatever) is to do a bit more math. You don't say how you are calculating the hypotenuse, but in this file I've just used a distance node. It's in side view so the angle you want is positive in correct direction. There's a condition node to detect when to make the angle > 90 and when not to. https://www.dropbox.com/s/elbcn3e7vk74alj/trig.c4d?dl=1 you could also use a target tag pointing at the upper point, and measure the angle

You mean you want the conveyor belt to move - stop - move - stop etc ? Try this file - another monoflop LOL https://www.dropbox.com/s/wlnbfs49m4tzaxc/convbelt.c4d?dl=1

You'll have to get your calculator out - if the range mapper covers say 50F in time, the rotation starts at 20F and you need an event to occur at 30F, then the RM point needs to be at ( 30 - 20 )/ 50 or 0.2 on horizontal axis. I guess this could all be done in the timeline, using one of the repeat functions to scale it up. I tend to see every C4D problem as requiring an XPresso or Python solution. When all you've got is a hammer, everything looks like a nail . . .

I'm not sure where you got that big complex equation from, but you should just use the 3 equations in that pic I posted - separately. If I'm reading this correctly, you only have x and y positions of the lower and upper points (assuming front view). If you don't need the actual length of the hypotenuse, just use arc tan to get the angle. tan(a) = opposite / adjacent you can get the angle by deriving opposite and adjacent from the x, y positions of upper and lower points using arctan (You may need a negate node, due to which direction is considered positive rotation) I've used a degree node here to convert rad to deg for your benefit. I only use radians in XPresso - in fact XPresso only uses radians. This could be why you are getting incorrect angles ie from unnecessary conversions. The 360 degree malarkey is just for everyday convenience. The number 360 divides by 2, 3, 4, 5, 6 . . . etc, so it's handy when designing clock faces etc. The C4D GUI uses degrees to make it easier for non-math folk to understand, but whenever you type in degrees eg in a rangemapper, or for rotation, XPresso converts it to radians to do the math. This catches people out when they hang a result node on a port in XPresso and see 'wrong' values. A radian is the angle at the center of a circle when the arc length = the radius since the circumference of a circle is 2 * pi * R, the angle for a complete circle is 2 * pi radians 360 degree = 2 * pi radians, if you really must convert Radians is the usual unit in physics + math - a right angle is often referred to as 'pi by 2' etc. TLDR > use radians

@cavolfiore I guess you're referring to the modulo divide as in this snip what's going on here is that the modulo counts the frames up to the constant value 150F, then resets to 0, then does it again and again. If you divide the modulo output by the actual modulo number (150 in this case) it gives a value that represents how far along the count you are. So if the modulo output is 75, then 75/150 gives 0.5 because it's at 50% of the modulo counting sequence. The output of the divide node is a decimal number 0 >> 1 showing the position in the count. If you were to plot the divide output against time, it would look like this where the min value is 0 and the max is 1. In fact that's how I generated that oscilloscope type trace (for a different project). This modulo + divide is a handy little trick I use a lot in XPresso, often coupled with a rangemapper. You can think of the modulo function as the remainder after dividing number A by number B. We are not concerned with how many times B goes into A, just the remainder (which is the modulo) eg A = 12 B = 10 B goes into A once (this doesn't concern us) with remainder 2, so the modulo is 2. Carrying on - A = 65 B = 10 B goes into A 6 times (doesn't concern us) with remainder 5, so the modulo is 5 in Python, for example, the symbol for modulo is percent %, so this would be written 12 % 10 = 2 65 % 10 = 5 etc . . . HTH

Here's 2 methods for XPresso controlled cyclic rotation. The modulo file is simpler, but the monoflop file has more control. Info in XPresso remarks. https://www.dropbox.com/s/czaambirmctacek/modulo.c4d?dl=1 https://www.dropbox.com/s/qwia7udr0mg83os/monoflop.c4d?dl=1

Can you explain a bit better what you would like the final scene to do. I think you have got your formula mixed up - sin(a) = opposite / hypotenuse a = asin( opposite / hypotenuse ) arc sin is 'the angle whose sin is'. 90 degrees doesn't come into it. edit : I think I've got what you mean - calculate the length and angle of the hypotenuse when the points move horizontal (the hypotenuse has to change length else the 2 points would move together). Try this https://www.dropbox.com/s/ylkw8n1eesssmyr/inversetrig.c4d?dl=1

Interesting - the bounding box has a different definition of center in that objects inside the box don't contribute to the calculation. I initially thought the main topic with this problem would be 'how do you define center' - like mean, mode and median in stats eg if one object is at x = 25,000 is the center of the objects way off in that direction or more or less at world center ? Your python has given me a few ideas. As a relative python noob, I tend to see it as 2 flavors in Cinema - regular number crunching python and the C4D-specific variety with object IDs etc. I don't have a problem learning version #1 - lots of easy to understand tutorials on YouTube, Lynda, Udemy etc, but I have difficulty with version #2. There just seems to be the documentation - which I find a bit hard going. Any suggestions welcome.

I think you're over-complicating this. My 1st answer - just adding the items in one big math node is easier to understand.

That corrected file is interesting. Not sure why it still works when I rearrange the objects but leave the XPresso the same - in fact I'm not sure why it works at all.

Can you explain ?

@teknow that mix solution would get a bit busy with 16 objects as in post #1. You can iterate the objects, and do the math in Python. https://www.dropbox.com/s/gotli0xq1q28lhj/centered2.c4d?dl=1 edit : actually doc, your successive mix node solution doesn't give the center. Lets say there's 3 items at 0, 10 and 20 cm. By your math (0 and 10) > 50% mix > 5 (5 and 20) > 50% mix > 12.5 but the correct answer is 10 my method - (0 + 10 + 20) / 3 = 10 see comparison here in a circle https://www.dropbox.com/s/f4lahgp5z3c9agi/centerwrong.c4d?dl=1 and in a line https://www.dropbox.com/s/y6v6mmumf0rvhoi/centerwrong2.c4d?dl=1

I guess it depends how you define the center - equidistant, average etc. I used to use a simple method for pointing a target camera at the center of several dynamic cars - I just added the vector positions and divided by the number of cars to get the average position ie center. You can't divide a vector in C4D, so you have to multiply by the reciprocal ie 1 / number. See file. If your objects don't move, the axis tool (mesh - Axis Center) might do what you want. I find that tool a bit confusing, but I think you can center to children under a null. https://www.dropbox.com/s/xpzyp0nauqyc5oh/centered.c4d?dl=1

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