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.

Currently running C4D / RS 2026.0.0 on both my M-Series Macs.
I have the worst time (extremely slow frame renders) when I try and add motion vectors to my final animation renders.
On a whim, I just tested a project file, by rendering a motion vector multi-pass from the Standard Renderer. It looks a hair different than that, from RS, but still seems to work with RSMB (the whole point of doing so) and took a fraction of the time to render.

I will clean up my text project, and post here shortly. But I just don't get it. Anyone else have major slowdown issues trying to generate MV's?

Edit: My apologies, I was thinking that I was composing this question over on the Redshift help forum. I'm going to do just that now, but I'll also leave this here.

Thank you for the follow-up, Dr. Sassi. At the moment, I chose to employ your time scale method, being that I needed to have more unified control over that and the other non-simulated action in my project. I think it will generally work - although I am realizing that because I'm easing the objects to a stop, there is some overlap where the particles don't entirely honor the various collision tags. I think there's not much of a way around it - short of creating one ENTIRE animation at full speed, then caching and time-remapping that resultant alembic. But honestly, too much effort; as it it stands now, the effect still looks cool, and is much easier to tweak as I'm still refining.

Ah, yes. Thanks! That's certainly another way to go. So I guess, at the moment at least, there really isn't a true particle tool or object, which would handled time remapping directly inside the particle engine?
I like that your proposed solution, allows for normal time-line key-frame controls. But if I were to go the cached simulation route, with the time-remapped alembic file; do you know if there is a method to also use the timeline for those controls? The time-remapping curve is a little limiting, being that it operates in a percentage of the motion.

Morning!

I'm exploring adding a particle effect, to a client project I'm about to start. Simply put; I'd like to create a simple (C4D) particles explosion, freeze those particles for a few seconds as the camera tracks around (think The Matrix), then resume the particle motion. The only solution which immediately comes to mind, would be to cache the particles, the simply create that time effect within the alembic controls. But that's a little awkward - having to constantly bake, tweak, and redo. Is there a particle control object, like the math object, which can do this kind of thing?

Thank you!

Oh, wow! Thank you so much. It's going to take a little time for me to study what you have set up, in those scene files. But I'll report back.

Here's a simple project, showing what I'm trying to do. Essentially, I want the ability to have all the particle activity mostly adhere to the overall shape of the spline. But the "rotate" object really has different plans...

particles tornado test.c4d