3Delight Coud rendering costs 2 cents per minute of processing on 32 cores (i.e. 2 cents per 32-core-minute). Only the processing for the actual rendering is charged. The processing for uploading data to the cloud is not charged, nor is the processing for transmitting the image back (a process done separately and concurrently to the rendering itself).

Two cents per 32-core-minute implies that if 1000 cores are used while rendering, the charge will increase at a faster rate than if only 32 cores are used. In this instance (1000 cores), 62.5 cents per minute. This is very much like electricity usage. At a rate of 20 cents per kilowatt-hour, if you use 10,000 watts for one hour, your cost is 200 cents. 

Monitoring the cost while rendering

To further explain and understand the 3Delight Cloud rendering cost, we will use this illustration of four independent renders at various stages: 


Four independent renders shown in the 3Delight Cloud Dashboard (in 3Delight Display).


STATUS

WHAT'S HAPPENING...

Syncing
The first render is at the “Syncing” stage. This is when scene elements are uploaded to the cloud. There is no charge during that process. This can be quick or long depending on the speed of your internet connection and how many of your scene elements are already cached in the cloud. For the entire duration of that process, the 32-core minutes counter and number of cores are marked as “ “ and the progress bar does not start. This serves as a confirmation this is not charged.
Parsing, Rendering

The 3rd and 4th renders illustrated renders at various stages of rendering while the 32-core minutes are counted. This will end up to be the rendering cost in 32-core minutes (when multiplied by .02, the cost in $). As explained before, the rate of increase of the counter is proportional to the number of cores used. While the 32-core minutes counter is shown in the dashboard as an integer, the underlying value is precise to the second.

Note: Prior to Parsing, there is a Starting stage with a duration that varies depending upon global service usage load. It can last up to 30 seconds. But in order to offer a predictable and uniform cost, this is counted as a fixed 12 seconds (0.2 x 32-core minute) regardless of how long it takes. We are aiming to reduce this further in the future in order to make it negligible even when thousands of cores are used.

Completed
The last render (shown in a subdued shade) is a completed one. As such, the 32-core minutes counter has stopped. At this stage, it is possible the image is still being progressively displayed on your screen. This would happen if your internet speed could not keep up with the rendering speed. In this instance, the fact the 32-core minutes counter has stopped serves as a confirmation that the process of image transmission is not charged.

Recording the charge

Once a rendering is completed (successfully or aborted), the 32-core minutes counted are deducted from the minutes balance in your account. Using the completed render in the above example, here is how it is listed in the Transaction History of your online account:

Explanation:

  1. 10:02pm is the time the render was completed. This is unlike in the Dashboard which shows the time it started.
  2. 46s is the real time it took to render the image (i.e. how long you had to wait for the render), excluding data syncing. This complimentary information has no incidence on the charge.
  3. 712 cores is the average number of cores that were used during the rendering (including the starting and parsing stages).
  4. 106m 02s is the charge; the rendering time in 32-core minutes calculated precisely to the second (including the starting and parsing stages).


  • No labels