Device 1111 (x1 GPU)Ġ:04 – Deadline job start, launch Cinema4DBatch pluginĠ:19 – Redshift scanning scene, updating lightsĠ:23 – Redshift Extracting Geometry, Mesh Creation, Mesh Geometry Update, Acquire License, etcĠ:01 – Redshift preparing materials and shadersĠ:00 – Redshift allocating GPU mem and VRAMĠ:01 – Redshift apply post effects and end renderĠ:08 – Redshift return license and free GPU memoryĬPUs: 64 Memory Usage: 10.3 GB / 480.3 GB (2%) Free Disk Space: 10.240 GBĠ:05 – Deadline job start, launch Cinema4DBatch pluginĠ:08 – Redshift scanning scene, updating lightsĠ:07 – Redshift Extracting Geometry, Mesh Creation, Mesh Geometry Update, Acquire License, etcĠ:07 – Redshift preparing materials and shadersĠ:06 – Redshift allocating GPU mem and VRAMĠ:02 – Redshift apply post effects and end render Operating System: Amazon Linux release 2 (Karoo)ĬPUs: 16 Memory Usage: 6.7 GB / 62.1 GB (10%) Free Disk Space: 9.811 GB I ran the same task through a few different instances and went through and summarized times for various “chunks” of the process: It’s this part of the rendering process that I’d like to speed up as much as possible. However, there’s a lot of “setup” involved in rendering Frame 0 that gets cached. Since we’re using Cinema4DBatch, all of the frames after the first one render very quickly. c4d scenes directly instead of exporting proxies first. rs files using the Redshift Standalone plugin is faster, but from a QoL standpoint we’d prefer to just render the.

From my tests, it’s clear that rendering. I’m trying to optimize render times using the Cinema4DBatch plugin, so the scene file stays loaded in memory in between frames. I’m currently experimenting with rendering C4D+Redshift scenes on various AWS Portal instance types.

Redshift c4d price