Sounds good, leininger609.

My best wishes for your project

Thanks for the reply, leininger609.

My understanding is that the particles are stored normally in the graphics card (GPU), hence the speed.
The Tracer works on a CPU level.
To get the Tracer working, the Particles must also be on the CPU level, which causes the one-frame gap.

You can see that when you switch off the option to download (or copy) them to the CPU:
Attribute Manager> Scene> Simulation> Particle> Download : off

No Tracer will be created from the Particles, as no download is provided.

The suggestion from above, caching them, downloads those and has the particle values available at the very beginning of the frame-based calculation. If stored on an SDD with a fast access time, you might not even feel a difference; in complex setups, it might be even faster.

I hope that provides the needed insights and allows you to improve your project file as much as possible.

Cheers

Hi leininger609,

The Tracer has to be below the Partilce objects, Priority-wise. I assume that is set up already.

The particles are produced, and the Tracer is a frame behind them, which can be fixed by caching the Particles (Particle Group has the option).

Cheers

Hi camera-reply,

Yes, the QT VR gave an option like that, but it was just a series of images with a specific link to a position in the viewer. I bought the Studion Pro version in the late '90s, and I remember it vividly.

When you are familiar with the QT VR Studio, you might remember how to import all the single images and create the VR experience; Cinema 4D later simplified that process for everyone by rendering that sequence. As a result, QT VR had all qualities backed in, and only a specific number of images represented this—no real-time rendering.

Very different is the glTF approach, which is pretty much the common way to get 3D "interactive" into a website :

https://cineversity.maxon.net/en/series/gltf_exporter?tutorial=gltf_exporter

https://cineversity.maxon.net/en/series/exporting_ar_game_ready_models_using_gltf?tutorial=exporting_ar_game_ready_models_using_gltf

The current version of the documentation is here:

https://help.maxon.net/c4d/2025/en-us/Default.htm#html/FGLTFEXPORTER.html?TocPath=Configuration%257CPreferences%257CImport%252FExport%257CglTF%257CglTF%2520Export%2520Settings%257C_____0

Google glTF viewer, or use one of the iPad apps to test if the export works to your specifications.

Enjoy

Hi tie-version,

Please have a look here:
CV4_2025_drs_25_MGem_01.c4d

I created a little gap, inverted it, and used the Thicken generator to create good visibility.
As you mentioned, it is a background object, so the view is from the side rather than the top.

All the best

Thanks for the reply, Tanmir8r.

Yes, my impression is that if two or more conflicting settings collide, things get a little bit more complex to "tame". Since we have no analytic tools for Hair like we have with Simulation to a certain degree, the though below is more an opinion than a fact:

Keeping the beard's shape while colliding and not losing a natural "reaction" to the collision is not an easy task to solve, if at all.
Hence, my suggestion is to lower the value of one influence.

My best wishes for the project

P.S.: Just a little example

CV4_2025_drs_25_PAst_11.c4d
Or with Tracer

CV4_2025_drs_25_PAst_12.c4d

Hi diet-commision,

Please have a look for Displacement and Normal in this file
CV4_2025_drs_25_STbd_01.c4d

While AO can't work for this process, given the flat plane, you can explore this here, baked to the original object, but where would the AO information sit for the "vertical" part in the "A" (see model)?
CV4_2025_drs_25_STbd_02.c4d

I use OpenEXR files in linear and 32bit-float per channel. Baking here is done using the Standard Render Mode!

Please compare the settings you have with the provided files. Will that help? Otherwise, take that as a step one, and I move on with more data from your side until you get what you need as far as possible. Having said that here are a few notes:

AO was a fake to get a sense of Global Illumination way back in time. It responds only to geometry. Even if you place a bright light in a corner of the object, it will show dark AO effects. Global Illumination renders this more naturally, and adding AO to a Global Illumination render is like adding most of those effects twice to the visuals, which might defeat the intention of the whole aesthetic.

I'm strongly biased here (I know ); if we talk about anything towards photorealistic, whatever that might be (realistic, photorealistic, Hyperrealistic, the bandwidth is rather wide. But of course, if your work needs it, then it needs to be calculated after the displacement of the baked object; it can be stored like an XYZ Displacement can.

I would suggest baking to avoid low-level image formats like in the youTube source you shared; thanks for the timeshare, so I do not have to go through this.

I like to help based on project files, which usually give a clear problem, and then, in return, I can hopefully share a working file and, if needed, an explanation. This has proven over more than two decades the best working way. In the end, I would like you to feel savvy about this.

Cheers

Hi hang-single,

To my knowledge, the options are R25 and up.
https://www.maxon.net/en/requirements/redshift-requirements?srsltid=AfmBOopeOaulqhrmPdrk7Abvwp0Ex89LOJNc50RVZ_ZUs-RHLP4n0WZb
or here
https://help.maxon.net/r3d/cinema/en-us/#html/System+Requirements.html?TocPath=_____3

There was a version for R21, but since that was around 6 years ago, I'm not aware if that is available as a new license or if support is given for the current OS.
If it is available, make sure to know what version of Redshift 3D it is.

Please get in touch with Sales:
https://www.maxon.net/en/about-maxon/sales

All the best

You're very welcome, Mark.

My best wishes for your project.