Leaderboard

@bentrajeSorry, it took a bit, I was busy otherwise. Here's a Geometry Modifier Capsule, which does a manual normal extrude with offset and variation parameter: test_scene_nodes_manual_extrude_variable_offset.c4d Please note, I'm not saying Maxon does it exactly this way. But it's one way to do it. Edit: One more note: You will find I use an actual Extrude node in my setup. This is because, currently we are lacking some smooth tools to create new topology. You can do it, but it gets tedious rather quickly. So, I instead misused the Extrude node, to provide the topology needed for the extrusion, but looking at the setup, you will see, it is not doing the actual extrusion (it's offset is set to zero). So, it's a bit of cheating, but it's cheating before the actual core of the question asked, how to do the "offset" and "offset variation".

I've worked on a few CAD based projects with SLDPRT/SLDASM files as well as STEP files. Generally the default import settings in C4D are fine. They'll come in tessellated no matter what, and subdivisions generally won't work. You'll notice the objects will all have normal tags, THIS IS VERY IMPORTANT. Do not delete the normal tags, and avoid editing the geometry or it will screw up the normals, and you will get weird shading artifacts. As long as you don't delete the normal tags, you should get perfectly smooth surfaces when you render. If you happen to need more geometry in your object, re-import the the file with higher Detailing settings, and it will give you smoother geometry. You can also play with these settings if you want to tweak it. I've also tried using the volume builder and remeshing, but never got acceptable results. Other than completely remodeling the objects, this is the only reasonable workflow I've been able to find.

Just don't turn on "mesh checking" 😬😉

I was curious and put together a setup where a box connected to a HoRope setup falls down. This took me a bit longer than expected since I still have little clue about the connector details. So here is what I did (the important parts): - Created a visible cube at the end of the capsule chain - Removed the end target that fixed the chain - Connected the cube to the last capsule with an additional connector I was ultimately stuck with two errors: 1. I have to bake the dynamics, since otherwise the sweep limps one frame behind the simulation. The capsules are right in step so it's caused by either the sweep itself (which would be surprising since the sweep comes last in the tree and generators come behind dynamics in the execution sequence), or the tracer (where I don't have the slightest clue what its priority is, but it wouldn't help because it cannot be changed either way). 2. The sweep performs a hefty rotation around its axis. (Select it to see the polygons happily twirling.) As the sweep goes over a twist-less tracer spline, this is not surprising. I don't see how I could control the twist through the sweep's Rotation settings in an easy way... Ultimately, this seems to be an issue of the Connectors; I tried both ragdoll (the HoRope default) and BallAndSocket, but neither care much about the z rotation. Test by yourself... 1895823367_HoRopeConnectorChain.c4d

CAD programs do not consider topology any of their business on the whole, so the options they provide at export are not as comprehensive as we might like, and certainly can't do the slightest useful thing with edge flow - there simply won't be any ! ZRM is the closest we have ever got to being able to turn these CAD monstrosities into quad meshes and something approaching appropriate flow automatically. And as you say, although much of an improvement on the Instant Meshes solution, it is still a real struggle to tell it which edges are hard edges, because you have to select them on the original model, which is a deeply unrewarding process on this sort of dogshit topology, where there's 200 parts and only about 2 of the selection tools will work. So in 2022, the ONLY way to get this perfect topo is to build a new mesh on top of the step, ideally using the HB modelling bundle Retopo setup. But as mentioned sometimes the STEP surfacing is good enough to render fine without alteration, as long as you don't need to alter the model in terms of point count or order, or to use displacement, which will just fail. CBR

A lot of people don't realise that when they set a port (eg on a rangemapper) to degrees, it still outputs radians in XPresso. Comes as a shock the first time they stick a result node on something rotational, expecting to see nice multiples of 10 😀.

You will never get a proper quad mesh. But just dont worry about it. Most likely you dont need it. C4Ds internal converter usually makes a pretty good job of things. And edge rounding etc can/should be done on the shading level. Back in the day Everyone used MoI to get decent meshes - but these days I just used C4D as it's less work. If you want to splash out on Rhino, I think that now has a nurbs-to-quad capability which looks pretty good.

What that it?! I know you can't feel it, but in this very moment I am sending you all my love...

Yeah, splines can be tricky in that regard. Maybe you need to use a rail path. Just copy your circle and move it to the side a few units. And put that one into "Rail Path" in your align tag. You may have to adjust your cylinder again...

Do you have "Tangential" turned on in your Align To Spline? If not, do it. You may have to realign your cylinder after that. And maybe switch up the rotation in your xpresso.

I'm not sure I understand. But in doubt, put it in a null object. Or rather: put your align to spline ALWAYS on a null and put your object(s) inside that null.

@darrellpThanks so much! I knew it was stupid! I was looking at these exact nodes quite a while. Blind as a mole... I added a fixed project file to my post above.

This is a xpresso node called "spline" (xpresso -> general -> spline") which is empty initially. Then you'd feed it the "object" output from the actual spline node you just drag in. If that makes sense...

We have just released a small update to version 1.1. And we also fixed the demo version not being available for free... (duh!). The update is of course free. Existing customers will be notified by email and in Asset Juggler Discord. The demo version can also be used to update. Changes: Added: Options to use normal Instances instead of Render Instances for Live-Preview and Baking (useful, if Hair or other features incompatible with Render Instances is involved). Added: Added Texture tag options in Material and Material Override Groups configuration. Note: Also see Asset Group on hidden function of Material layer link field! Added: Report prepared for Cardano Added: Button to Lock None to Zero for all groups at once. Fixed: Asset Group and Rules tabs not correctly restoring their enabled state. Manual: New features, added notes, added parameter defaults and did inevitable corrections.

The problem of the ST was not the CGI though, but the story, characters, and worldbuilding, all of which Disney botched. I bet they can botch Knights of the Old Republic with glee, regardless of who does the visuals. Waiting for Obi-Wan, but with low hopes.

@MighTWell, I think/hope I've figured out the problem. In your LCV you divide the length of the array by the number of segments. For iteration 2, for instance, you were dividing 17 by 4 and using int arithmetic to come up correctly with 4 relying on the roundoff to fix things. However, in the first iteration when the number of segments are 1 you are dividing the array length of 17 (or 5 or whatever) by number of segments (1) and incorrectly coming up with 17 (or 5) because the int arithmetic doesn't have anything to round off. I think the proper thing to do is divide not by the array length and rely on integer roundoff but to divide by (array length - 1) and get the exact answer. Now the first time through you divide 16 by 1 and correctly get 16. Second time you divide 16 by 4 and correctly get 4. I put in a little annotation over the division I'm referring to. It's input has been redirected to come from (array length - 1) rather than (array length). P.S. Another feature I'd love to see is being able to turn of Data inspector in the Inspection window rather than having to search all through all the nodes and do it manually on each one. Koch Test.c4d

Well, I would animate the car along a spline (Align To Spline) and then use a setup like this: Where mainAlign is my Align to Spline tag. path is my spline along which the vehicle is going. Spline is a xpresso node to access more properties of the spline (like in this instance "length". fWdia and rWdia are my wheel diameters (in my case I have differently sized wheels front and rear). You can read those with the bounding box node (I think that is in your video example). Those diameters get multiplied with PI to get the circumference. This way your car movement is restricted to a spline, but independent from a single plane. Maybe this helps... Cheers, kws

yea that was a good one! Also really liked sonny’s edge and when the yogurt took over 😅

Heh. Maybe I was thinking too meta; I tried to stay in the context (given by the OP here) of a learning exercise for a Python beginner which would concentrate on the hierarchy of track, curve, key, and DescID, and keep things simple. Adding the whole serialization raises the exercise to a different level... depending on the OP's experience, might even require some understanding of JSON as a format, or a discussion of alternative methods of type-string-type transfer... which is all not necessary if you just copy the data directly from object to object. As the PluginCafé examples show, the barebones clipboard access is fairly easy to achieve, even from simple scripts. Though for a complete serialization, many more tests should be performed even for that simple "copy one single vector" use. After all, the clipboard is a system-wide resource that may contain just anything at any time. For starters, I would begin the JSON representation with a keyword that allows us early termination for most error cases; then we need to serialize one track and its full (arbitrary length) list of keys with multiple attributes each; even the key's value type itself depends on the track type. That's fairly interesting; how would you serialize a PLA track, for example? Even json.dump'ing a mere c4d.Vector results in an error, unless you carve it up into its components. And in the end we need to deserialize it all again to insert a proper track into the other object. Thus, I don't recommend using the clipboard for a beginner for complex data sets. That's all.

No I don't need the screenshot, I believe you (despite your handle) ! I just need the broken file so I can demo it in a potential bug report ! Pls upload the .c4d ! CBR

It's true that there's no current way to terminate an LCV. That will definitely be added. For now you have to use your solution with an extra Bool variable which remembers if you have already reached your final state. I did a similar technique to implement the Mandelbrot iteration. For the GCD case you can use 100 as a safe number of iterations, but you can also use a better upper bound for the number of needed iterations. If you look here in the worst case section https://en.wikipedia.org/wiki/Euclidean_algorithm#Worst-case you'll find the formulas N - 1 <= log_phi(b) and N <= 5 * log_10(b) where phi=golden ratio, N = number of required iterations and b = minimum of both values of which you want to compute the GCD. We neither have a log_10 nor a log_phi node (only natural and 2-based logarithm), but you can use log_phi(b) = ln(b)/ln(phi), so you can use ln(b)/ln(phi) + 1 as your number of iterations. Of course that's an "optimization" which is really specific to the GCD case. There are other cases where you can't estimate the number of required iterations, and not having a true while loop is waste of CPU time.

Capsules that are based on nodes, opposed to those coded, can be converted to groups. You just need to place them in the node view and choose convert to group from the menu.