Leaderboard

Excellent - glad you found some value in my ongoing efforts. Happy to book a short skype or zoom session with you to discuss all the terms you haven't understood so far ! But actually I think Mrittman's eradication of the pesky frame update problem provides a much more stable base going forward than what I had going on, so I am led to think we should probably continue on from his version of the file, and buy him a round of beer or 2 along the way for cracking this vital part of the problem ! I wasn't even LOOKING at the piston setup for problems being caused in the springs !! 🙂 Anyway, hit me up in the DMs about when you'd like to arrange discussions if you still think they would be of value ! CBR

Folks, this is not a political forum, there are plenty of other places to express opinions of current geopolitical events. There were similar topics in the past and it never ended well and turned into very bad thing. Core4D is open community for everyone and will not discriminate on any basis. Hope you understand this decision, topic closed - thanks : )

@HappyPolygon XPresso is evaluated once per frame (ignoring accidental calculation due to clicking in viewport) for train node RHS port = output z position (read) LHS port = input z position (write) every frame - the train z is read small amount added to this new value written to train z if we just did this, on restart train would be at say 500cm, so need to reset this to 0 frame is null outputs - True or 1 when F = 0 False or 0 when F > 0 condition node selects ports - switch = 0 selects 1st input port (normal) switch = 1 selects 2nd input port (reset) ============================= 100mph scale calculation - for 25 fps 1 cm/F = 25 cm/s = 0.559 mph (from Windows calculator) 1 cm/F >> 0.559 mph divide both sides by 0.559 1 / 0.559 cm/F >> 1 mph multiply both sides by 100 100 / 0.559 cm/F >> 100 mph 100 / 0.559 = 178.9 so 100 mph >> 178.9 cm/F this is amount added to z position every frame for 100 mph slider 50% = 50 mph etc ============================= as a test, in this file speed_test.c4d I keyframed the speed as 0 - 250F constant 20 mph 251F onwards 0 mph seems OK you might want to check my math 😀

For the time being you can do just that in PS by going to Filter>3D>Generate Normal Map. I think the tool is being shelved in the near future though

I decided to take a stab at this myself, as this kind of stuff fascinates me! As @Cerbera mentioned, there's definitely some issues with priority going on. Mostly stemming from those darn constraint tags with the piston portion. I got rid of that setup and rigged it with a little Pythagorean magic. This way, we get rid of the lag/priority problem. There's just one issue... the piston rod is now pointing in the wrong direction lol. Apart from that, I think I've got my version pretty solid. The spring connections stay in the holes. The only keyframe is the crankshaft/starter cup. I used squash and stretch to expand/collapse the springs, as opposed to the pose morph. Then some target tags to point them to the governor arm. https://www.dropbox.com/s/17wt1d2ys9mbwn1/GOVERNOR 00 PREP R25 V18 C4DCAFE V7 CBR_matt3.c4d?dl=0 If someone could figure out how to put the piston/rod in the proper position/angle, I think it's pretty much there. Hope this helps! throt.mp4

This is a very particular case. For comparison, I converted this scene to Blender, and added the Line Art modifer to create similar lines - and as expected, Blender also plays the animation quite slow (slower than C4D actually). View-port navigation also slows down in B for the view camera that must recalculate the lines from all angles, but the perspective camera is smooth (no need to recalculate lines, but the lines look wrong from a too different angle). So it is just the nature of the 'beast': calculating and processing this type of line effect in real time takes its toll on the CPU rather than the GPU. Only with a dedicated edge line art GPU shader (like in games with edge shader effects such as Borderlands) is it possible to calculate these type of edge effects in real-time. Btw, if these lines are 'baked' per animation frame in Blender the view-port works butter-smooth, as does the animation (at least in Blender, don't know if this is possible in C4D, to be honest...). The lines are then converted to Grease Pencil strokes, and can be adjusted per frame, if required. At the expense of not being able to change the camera's view point too much, of course... Perhaps someone here knows how to bake the lines in Cinema4D.

OK, some progress on the investigations there. Might be down to naughty priorities after all... CBR