Chester Featherbottom

*shrug* Doh! I hadn't even seen he posted a scene. I just built one. 🙂 geometry_axis_fracture.c4d

That's only if you use Explode Segments. Straight mode honors wherever the Axis is.

I was just curious if the axis offset node solution @HappyPolygonposted the other day would be a possible workaround for this. It does work, but that won't help you in R21.

Oh, multithreading...

I said the same thing about R25 and yet... here I am. 😉

Can confirm I've seen it before on M1/Monterey. It has often happened when resizing, but I've never seen it persist after resize a little bit more in either direction.

Your caution is warranted - I have been burned by both in production, but not really the fault of the tool. They just take time to get use to. I suggest learning them on a non-critical project. Both Takes and xRefs "work"... but using them correctly usually requires using them incorrectly first. Sometimes projects just become incredibly complicated down the line or grow beyond their scope (multiple users, multiple platforms, multiple servers). There's just no way to cover the many different uses for them. Both Takes and xRefs create a great way to reduce and minimize assets, but at the expense of visibility and portability. I would say your use for visualisation is probably the safest, but they may not be necessary. Are you working with a large team that is all working on different assets at the same time that will be combined into one? Do you have sub-parts that are constantly being updated? If not, you may not need xRefs and if you don't need xRefs I wouldn't really use them. But it entirely depends on your workflow and environment and ultimately, your personal preference. However, here's some advice on learning Takes or xRefs for the first time, especially on large projects with a lot of animation and material changes. Both xRefs and Takes give you a lot of control over objects properties and parameters. You will often get burned by accidentally changing something deeply nested. When you're starting off, try to stay top level any first... just turning visibility on and off... simple stuff. As you get used to it (and make a few mistakes) it will be easier to navigate the deeper trees reliably.

Awesome. If you have to do this in the future you can get a perfect spline in one click by selecting your Joint Chain and running [Character > Convert > Joints to Spline]. Cheers. 🙂

No worries. Sometimes scene files are king. Sinuous_Ladder.c4d

I used a Point Cache Tag [Tags>Rigging>Point Cache]. They have some nice parametric features for Offsets and Loops. And also, you're not doing anything wrong... this is Maxon having PSR Cache, PLA Cache, Point Cache, Dynamics Cache, MoGraph Cache, Cloth Cache, and ABC Caches all in different places following different rules. I'm sympathetic that each of these features arrived at different times, but it seems Maxon has put very little effort into unifying this octopus of caches to date.

The reason you need to cache the spline is simply to force an order of operations. That is... so that the Spline-IK will properly move the joints, but it's not intended for export. After getting everything the way you want, you can just bake the PSR of the entire joint chain and delete the Spline_IK entirely. That's likely the kind of export AR would prefer. There may be a brilliant way of doing all of this without the intermediate baking/caching, but it's a workflow I've come accustomed to when I need to solve things quickly. Cheers. 🙂

If you absolutely NEED to stick with joints for AR, you can still do this... but you really need to experiment with your initial binding approach. You bind feels very "auto". If this is the only action you'll need, smoothing the entire chain in the weight manager will also get you significantly closer. After you got that under control: 1) create a spline from your Joint Chain to use Spline-IK 2) throw a formula deformer per @Cairyn's suggestion under your spline 3) cache the spline and turn off your deformer Joints and Ladder should follow suit after that.

Depending on how many keyframes you have (or how fat your fingers are), clicking and dragging items around your timeline might be a little clumsy. If you know exactly how many Keyframes you need to move you can select all your keyframes then click "Move/Scale" [ Timeline (Dope Sheet) > Functions > Move/Scale ]. Leave Scale at 1 and set Move to -200.

Ha! Well, first of all, Otoy probably has the worst customer information of any company I've ever decided to do long term business with. "When and how" they inform their users of software features and updates is downright archaic (borderline insulting). It just goes to show how good the renderer is for people to tolerate such horrible public relations. But at the end of the day... I put most confusion surrounding Octane specs and releases on Otoy, not Apple. Second, just because it's not listed doesn't mean it isn't good. It simply means they don't have a good test for it. Literally... OctaneBench does not run on an M1. The last OctaneBench is from 2020 and the last news I saw on the Otoy forums was that the CUDA and Metal versions have been using different core code that won't be rectified until the 2022 release. For the short amount of time Otoy has been developing for Metal they have done an incredible job and *they* seem pretty excited about it. There is no way Otoy would have dumped this much time/effort into it if they didn't think it had a viable future. If you haven't had the opportunity to actually render on a good M1 I think you'd be pleasantly surprised. I've only recently been using it for work this last year, but it's been holding its own quite well against my prior CUDA hardware... especially considering so little has even been optimized for M1 yet.

RE: Hardware -- I love how everyone in the Apple event video asked, "What are you going to do creatively with ALL THIS EXTRA POWER?" Oh, I don't know... finally catch up with the industry for 2 weeks before every client starts demanding all deliverables in 12k. The game has been the same for as long as I can remember. Artists get a fraction of a second to squeak ahead before the load just gets heavier. Still, I've had nothing but awesome experiences with each of the m1 chips and how linear the results are, so I'm pretty stoked about this machine.

@Cerberalikely has the answer you're looking for, but a couple of tips when troubleshooting these things in the future... There is almost always *some* type of difference between what you see in the viewport and what you see at render time. Be sure to ALWAYS check both and be sure to know which is the one that's giving you trouble. The texture mapping that comes out of Metashape is always UV mapping. It is the most consistent and would make no difference which program you opened it up in. The UV Information is embedded in the OBJ file itself. Cheers

Hate to burst anyone's OBJ bubble, but they aren't dead (and probably won't be anytime soon). Are they missing tons of features that exist in other formats? Yes, but they're plain text... which makes them incredibly readable, editable, and portable. Everything can open an OBJ. I've been getting quite a lot of volumetric video assets from Microsoft Mixed Reality Capture Studios over the last 6 months and it's all OBJ/PNG sequences (and no MTL files). I've ended up using python to generate, rename, relink, import, export tens of thousands of individual frames and images. I couldn't have pulled it off without it. I know there are some artists that recoil at the thought, but python has been what's saved me from just about everything missing from Maxon's toolset. Way easier and more powerful than switching programs entirely.

It's not a bug with python. You get the same results using Xpresso without the python node. You will get correct results if you change your input color profile from sRGB to Linear. Also, if you want an actual linear gradient, you need to change your knots to be linear as well. You currently have them set to "Smooth" (the default) in the preview above.