Will do, thanks. I pivoted to a different solution for the job. But I'd still like to know, so I'll post an example file as soon as I can free up time.

I want to have a soft body be impacted by a collider, and have the resultant waves propagate for a time.
But then I want the shape to return back to the original shape. I want to be able to direct that return, with precise key-frames.

How would I do this?

Thanks!

Will do, thanks.

Thanks, I'll try that again. Pretty sure I already had, but maybe I need to try adjusting more of the parameters, in order to see the effect.

Okay, thanks! C4D looks to play the occasional joke, I see...
But, if you happened to crack open my scene, where would you position the deformer?
I'm not seeing any results, when I add it in various positions.

Greetings!

I am trying to create a simple (deformer-based) effect, where an object is going to fall into liquid, and create a simple radial ripple. I'm attempting to use the Spline Deformer to create one ripple, and then I'd like to utilize the Jiggle Deformer to create an "echo" of that ripple so that there are many smaller ripples after.

But anywhere I try and apply the Jiggle, it tells me "Invalid Hierarchy".

How would I employ that in my simple example scene?

Also, I'm very much open to any other suggestions as to how to go about making a "simple" water ripple; I'm not tied to the spline deformer route, by any means.

Thanks

Hey Noseman,

Thank you, and my apologies, I normally would have done so. But I was a bit rushed, and I actually tracked-down one of your excellent quick tip videos, regarding creating quick (Add Transform Constraint) constraints, and that got me thinking that the "transform" option might work better than the "clamp" or "parent" options, I had been fumbling around with.
So I think I'm okay for my current deadline, but I'll circle back soon, with a sample project, to see whether there are more elegant solutions to my problem; as it stands, I'm key-framing a number of parameters ON then OFF, to achieve the effect.

I have a project where, in simple terms, I need to have a tube impact a sphere, and then have the sphere stick to the tube.
Seems like this should be a simple task with the Constraint Tag - using Clamp.
However, as is almost always the case with that tag, the results are a pain to achieve. Whenever I reset the animation to the first frame, the sphere almost always winds up some improper position.

I'm specifically toggling the tag's "Enable" feature off, then on, at the moment of impact. So ahead of that enabling, the sphere should be receiving no effect from the tag, right? But it does.

There must be a sure-fire way to make these kinds of common tasks work 100% with the constrain tag, right?

Help, please!

Anybody? I can't be the only one who needs to make something like this work.

I need to unwrap the UV's on various client product CAD files. That process works much better (especially as I'm using FD Toolkit to help) if I perform that task with a relatively low-poly model. Great. I can do this.

However...

I need to use much higher poly models, for the actual rendering work.

So, I'm trying to use the Property Transfer tool to move the unwrapped UVW map, from the low-poly model, to the high-poly model. Things get messy from there. The UV's do seem to come across correctly, but I'm also stuck with weird artifact issues, around some of the model seams.

I'm attaching the most simply, stripped-down, example of two pieces. One is the low poly (source) and one is the high poly (target).

I hope someone can shed some light on this, for me.

https://spaces.hightail.com/receive/IPq6ilHP4Z

Noseman; your work on the Maxon Youtube channel is excellent, and greatly appreciated. I look forward to your presence, here on this board.

Dr. Sassi, you were, without a doubt, one of the most helpful, positive, and engaging experts I've ever had the privilege to work with.
Thank you for all your help, and best of look on your future endeavors.

Note: I posted this exact question on the RS forum, but have yet to get any feedback. I figure this may be more of a C4D issue, so I'm also posting here.

I've been meaning to ask this for some time. I used to always enable "normalize intensity" for my RS lights. Then, some time ago, something changed (either with RS or C4D) because those exact same lights, in the exact same scenes, would blow out the display (not IPR) in Cinema. It's actually more than a little uncomfortable, with my XDR display. This is a result of having to turn the light intensity quite high, in order to get proper illumination with that feature enabled.

So, is there some setting someplace, in either RS prefs or Cinema, where I can avoid that blow-out preview?

As it stands, it's forced me to only use lights with that feature disabled, which is a total pain when I have to work with an older project; I have to change every light.

Thanks.

Good morning, Dr. Sassi. I apologize for the late reply, I was grinding away all weekend, on the very project which prompted these questions. I had to proceed with some quicker solutions, to make the deadline, but I'll be looking back over your example projects, to see what you have proposed. Finding more practical ways to generate some of these special data passes, will always be highly valuable.

Thank you!

Dr. Sassi, thanks so much. I'm calling it a day, but I'll study your work tomorrow morning. I'm most certainly trying to find some sort of "cheat" because I'm having a heck of a time getting motion vectors to work with my particles scenes - likely taking all the VRAM I have, because Redshift / C4D is having fits - unexpected quits, left and right.

Take your time, Dr. Sassi. I'm interested to see whether there is a way to make this work, but I'm planning my work project around the idea that I'll still have to generate my native particle MV's through Redshift; just to be safe.

Good morning, Dr. Sassi.
Thank you for the example. You beat me to the punch, because I was going to show you (attached) a much closer proxy of what I'm creating.
You can see that the Data Mapper is controlling the radius of the particles, over their age percentage.
However, when you enable the MoG Object, you'll notice that it (not surprisingly) doesn't see that data, so the radius of the particles (clones) remains constant.
Was your project showing a way to also solve for the radius? My apologies; my brain is still waking up today...

particles to MoG test.c4d

Update, I did figure out that it's not terribly difficult to accomplish some of what I was asking about, in regards to the native particles.
Use a MoGraph Object, set to "Object" mode, then drag the Particle Group into that selection. With the MoG set to "Multi-Instance" it's not terribly laggy, either.

All good!

However...I'm realizing that MoGraph is not likely going to read the Data Mapper I have used to control the scale of the particles, over their lives.
So I'm not sure I'll be able to get close enough to make the resultant motion vector render match that of the RS particles beauty pass.

Dr. Sassi,

This post piggybacks mine from earlier, regarding motion vectors.

I'm still running some experiments, trying to find ways to generate motion vector data, without the tremendous render times inside Redshift. I feel like I might be able to get away with generating them with the standard renderer for some of my scenes / objects. However, I'm going to have several instances where I'm creating (C4D) particle effects. Those beauties will be rendered through Redshift, however, I'm wondering whether I can create the particle motion vectors in Standard? I know that the C4D particles are just data, hence the need to generate the visible results with a RS tag. But what's the equivalent, in standard render? I'm guessing there is no perfect 1:1 solution. Would it be a MoG Matrix object, which could use the particle data?

Thanks, for any ideas you might have!

Thank you, Dr. Sassi. Yes, indeed, I've previous experimented with eliminating nearly every non-essential setting, when trying to output the RS MV pass. Unfortunately, at least in my experiences then, it still took quite a long time - particularly, when working with C4D Particles. And therein lies the issue. If I already have a long primary "beauty" render, I'd sometimes rather just include the MV pass in that, as opposed to a second standalone MV render, even if that is a little quicker.

But I wasn't expecting the good ol' Standard Render MV pass to be so lighting quick. Again, it's not the same looking as that from Redshift, but it still seemed to convey some good data to RSMB.

I'll keep experimenting, as always.