CINEVERSITY

Thank you very much for the kind feedback, Adam; I love to do that.

If there is anything else, I'm happy to look in the morning into it. (midnight here)

My best wishes for your project.

Yes, Dutchbird.

Since processing time becomes faster, I can see that as an advantage. But also, drives have gotten to $20 per TB, and even running the standard Project file/BU/BU (three places in distance to each other) is not a problem anymore, money-wise; keeping the drives alive, as they are degrading over time is. Another point would be whether future app versions can read the cache files anyway? I keep my old laptops here to have things available, like some old Quicktime codecs (e.g., Sorenson movies would be lost otherwise, as I noticed a while ago).

All the best

Thanks a lot, Mike.

Let's hope that the Prefs will not go back at any time to the state that caused the problem.

My best wishes

Hi background-permit,

So far, I know that would be possible with the Point Cache; after the Point Cache has stored the data, the Cloth can be switched off.

https://help.maxon.net/c4d/2023/en-us/Default.htm#html/TCAGEOMCACHE-ID_TAGPROPERTIES.html#ID_CA_GEOMCACHE_TAG_CACHE_LIMIT

All the best

Hi strength-address,

The Pyro simulation in Cinema 4D builds up over time; I'm unaware that anything could be set to a later starting point (precalculated frames - not shown) and placed that one to frame zero.

However, if you cache the simulation and open it in RS Volume, you can offset this Freely. The single (per frame) cache files contain the needed information and do not build up on each other.

If storage space requires it, the frames not included in the renderings can be deleted. I would keep at least the frame before, as I'm unaware how other renders might require this data for motion blur (Just a gut feeling, as I have no 3rd party render engines here running).
RS Volume will recognize the available range, and if the "Detect Frame" is pushed again, it will set the first available cached frame to frame zero. If you need a different starting point, use the provided Offset parameter.

I tested this all with the current build 2023.1

My best wishes

Hi Dfunk,

Thank you, yes Cloth in R25 is a different "engine", hence my hint with 2023-1.
I guess you have tested 2023-1, and the main obstacle is the rendering.
Using Alembic, you could animate everything in 2023-1 and render in R25.

Save your file, select your flag, and go to
Object Manager> Object> Bake as Alembic.

When the file appears in the Object Manager, disable the original Cloth.
Then select the Alembic Flag, and in the
Attribute Manager> Speed and Offset.

I just tested it in r25.
https://stcineversityprod02.blob.core.windows.net/$web/Cineversity_Forum_Support/2023_PROJECTS_DRS/CV4_R25_drs_23_CLal_01.zip

All the best

You're very welcome, Alex.

The idea was to provide these dynamic or progressive Voxels to limit the memory needed. The more classic approach is to define a single space that requires a lot of memory from the start.
But, yes, when you go tiny, as mentioned, you quickly have a thousand times more of these cubes, which goes tough on the memory then.

In the old Pyro (two decades ago), there was a 2D version for a more distant objects, I wish we had that also here, even just to comp on the 3D view 🙂

All the best