eikonoklastes

It's pretty normal to avoid small sizes in sims and scale up. Remember to scale your forces accordingly, though, and not just your objects.

I'm not sure what your intended scale is, but if it was a real-world size wrecking ball, they apparently start at 500 kg and go all the way up to 5.5 metric tonnes. If that's the case then it would take a devastatingly turbulent force to create the slack on the chain in your original frame. That chain should be pretty much dead straight if you want a realistic sim.

Rigid-body dynamics. I've updated my previous post for clarity.

The two states are guide states for the sim. The end of the sim will not (necessarily) match the supplied end state. It's definitely using an RBD (rigid-body dynamics) sim, just a guided one. I don't agree with this position. Simulations are used all the time to generate physically-plausible, but entirely unrealistic animations. For example, I can simulate two objects with entirely different gravity forces applied to each one. This scenario doesn't exist anywhere in the known universe, afaik.

Houdini user here. I tracked down the thread and found an explanation of the process, which is definitely a sim: To break that down, they're using 2 geometry states - State 1 is the pieces scattered and disconnected. State 2 is the pieces connected/stuck. In a Houdini rigid body sim, they are then interpolating those two positions (not manually animating them), and that's basically it. Houdini allows you to update the input geometry state in a dynamic simulation and feed that back into the sim as updated geometry, which is a pretty powerful feature.

Some AI models allow you feed in a start frame and an end frame along with a guide prompt. That's my guess regarding the specificity.

Saw a fun animation in this C4D thread: https://www.core4d.com/ipb/forums/topic/119136-modeling-of-spatial-distortion/ Here's my take on it, with some extra sauce added in (sphere avoidance and secondary motion), along the the default Houdini special sauce with full proceduralism throughout the chain: The (semi-annotated) scene file is attached here. Disable the PolyWire node (that generates the wire mesh) for a lot faster playback. spatial_distortion.hiplc

Bit late, but some renderers/environments expect different names for the attributes/data, so maybe you need to rename Cd to something else for Redshift in C4D to read it correctly. For example, USD uses displayColor, not Cd so that needs to be renamed when going from Houdini to USD.

Maybe this video might be useful:

From this page it seems that Redshift does not yet support Houdini 20.5: Houdini & Solaris Plugin Configuration (maxon.net) You might have to wait for an update from Maxon, or fall back to Houdini 20.

Houdini 20.5 will feature a brand new environment for processing and generating textures and compositing them seamlessly with your 3D scene. Internally labeled Project Copernicus, it will be the long-awaited update to the COPs (compositing operators) module. A few highlights: Built with real-time/near real-time performance in mind. It's written entirely in OpenCL so you get 100% GPU acceleration. It also uses Houdini's brand new APEX technology under the hood to provide multithreaded performance enhancements where applicable. Tight integration with Houdini's existing 3D modeling toolset. You can freely import any geometry to use as a texture basis or export texture information to affect your models with. Live updates to the existing lookdev and rendering environment, so you get live render updates as you adjust your textures. OpenFX-compatible, so you can use any 3rd party OpenFX plugins (like BorisFX Sapphire for example). Here is a demo of some truly eye-popping abilities of it (skip to the 7-8 minute mark for the actual demos): Here is another video that shows off even more stuff in Copernicus, from the Houdini 20.5 keynote:

Another day, another setup inspired by a C4D thread. Here's a basic umbrella rig using KineFX, with a very basic IK chain driving the thing. houdini_qO0fR14w27.mp4 KineFX_Umbrella_Setup.hiplc

That bit shouldn't be sliding, though? That should be anchored to the arm so that it can lift/drop the arms when the trunk joint slides up and down.

I believe @MJV is referring to the fact that Houdini, neither at object level, nor in Solaris, offers an out-of-the-box parameter to define your own focus object/null, so that it can be easily animated. Its omission is definitely a headscratcher, particularly in Solaris.

My understanding in this area is not perfect, but from what I (think I) know, an orthographic view is already a parallel projection. I believe the isometric projection you want is basically a very long focal length from a camera positioned far away?

I'm not sure I understand. Can you elaborate please?

Saw the C4D post about fitting a plane to a camera and realised that that's something I do fairly often myself, so I finally put together an HDA, which is Houdini's version of a Capsule to do this for me. While this can technically work with any geometry, including 3D geo, I really only tested it with flat geometry. The asset isn't blackboxed, so edit it as you wish. houdini_Hedg0xR1EY.mp4 avi.fit_to_camera.hdalc

Attribute Transfer SOP. It won't be perfect because your topology is wildly different, but it might be close enough to do the job:

The new Solaris LookDev Desktop (workspace) is very well thought out, and a big improvement over the previous Solaris workspace. The Scene Graph Tree has more vertical space, you have a bunch of useful panes beneath the viewer, and you can inspect the USD data without having to mess around with tabs or unhiding panes like you did before. Big fan.

Solaris now has a dedicated Log Viewer pane, that is preferred by Karma. This is a huge quality-of-life change over previous versions, where Karma would send its messages to the console, which is a separate pop-up window that cannot be docked. It was pretty annoying. Having everything neatly go into the Log Viewer is very nice.

Dragging keys around in the Animation Editor will automatically constrain them to the axis in which you started moving them in. This is a very nice change. Previously, there would be a separate UI element to drag them across time, and a separate one to drag them across value. With this new implementation, you get a cleaner UI and more confident key adjustments. You can also MMB-drag a selected key (or keys) without needing to have the mouse over any of them. This is also a very welcome change that reduces the work needed to move keys around. Great changes. houdini_5Tbgqb24pW.mp4

The MaterialX Geometry Color node (that reads in point colour) now sensibly defaults to Color as its signature, and not Float like it was before. Tiny change, but really nice to see even tiny things being addressed.

Karma now finally has filmic tonemapping built-in, which is great for getting a more controlled look of your render without having to mess with the colour settings of the viewport itself. It's under Image Output > Filters.

Steering this back on course, Karma CPU and XPU can both read point cloud data directly to do attribute transfers at render time. This is a massively useful feature that Mantra has, and I'm glad to see it finally come to Karma. This works independent of the mesh resolution, so it can allow for extremely efficient setups. Here is a video describing it:

Object level has a camera switcher built-in (it's called Switcher). Object level, however, has no concept of prims or prim names, whereas USD/Solaris does, and can leverage that to enable a camera switcher by using the same prim name for all the cameras that you want to switch between.