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.