Choose a workstation for 3D rendering by identifying the renderer and version, the CPU or GPU rendering path, a representative scene and the required output. Then validate the proposed build with that scene. A graphics-card name or processor core count cannot establish suitability on its own.
The procurement question is specific: can this exact configuration produce an acceptable result from the team's scenes under the agreed conditions? Keep modelling and CAD interaction requirements in the separate CAD workstation configuration brief. This guide covers the scene-to-final-render requirement, including memory, output quality and repeatable acceptance.
Fix the renderer and CPU or GPU path first
Record the host application, renderer, plug-in versions and operating system. Name the mode used for final production, not just the mode selected in a demonstration. If the team needs both CPU and GPU paths, specify which scenes and features belong to each.
Check current vendor documentation for that combination. For example, Autodesk's Arnold system requirements restrict Arnold GPU rendering to supported NVIDIA hardware on Windows and Linux and identify driver requirements. This is an Arnold example, not a rule for every renderer. A GPU supported by one product may not be an eligible choice for another.
Confirm feature compatibility before comparing speed. Arnold's GPU feature documentation lists supported features and limitations; it also explains that identical settings can produce different noise behaviour between CPU and GPU rendering. A faster result is not an equivalent result if required effects or output quality differ.
The application owner should identify indispensable shaders, volumes, plug-ins, render passes and denoising steps. IT should review software access and licence conditions for the proposed use. Keep hardware supply and customer-approved software responsibilities explicit.
Describe a scene that represents the hard part
Choose an authorised scene that captures the work you need to size. Record geometry, textures, instancing, displacement, hair or volumes where present. Add the output resolution, frame range, passes, sampling or noise settings and required file format. Preserve external assets and colour settings so the candidate receives the same job.
Include an ordinary production scene and a demanding scene if they represent materially different requirements. A simple preview image is poor evidence for a workstation expected to finish complex animation. Conversely, one exceptional scene should not silently define every artist's equipment.
For GPU rendering, treat graphics memory as a separate requirement from system RAM. Autodesk's Arnold GPU FAQ says the scene and textures must fit in GPU memory and that scene assets load into each GPU's memory. For that renderer, adding the capacities of separate cards is therefore not a valid shortcut for sizing one scene. Check other renderers' own memory behaviour.
Measure the chosen scene rather than estimating memory demand from the saved project size. Ask the technical reviewer to record peak system and graphics memory during the agreed test and to assess room for the expected project changes.
Specify the complete working configuration
Record exact CPU and GPU models, system RAM, GPU memory, drive arrangement, operating system and driver. Keep these details beside the renderer and plug-in versions. A quotation saying “high-end workstation” does not identify the machine you intend to accept.
Separate active scene assets, application files, temporary data and final outputs in the storage brief. State where each will live and how much space the pilot needs. If assets are on shared storage, include the actual connection in the test rather than demonstrating only from a local copy.
Add display and connection requirements for the person using the machine. State whether the workstation must remain available for scene preparation while another render runs. Include the application's normal companion tools in that working-session test where relevant; do not judge the candidate from an isolated render that omits daily work.
Copy this renderer and scene worksheet
Complete one record for each materially different production workload. Use measured values where available and mark the rest “to validate”. Keep confidential assets under your company's approval process; the first enquiry can describe the scene without transferring it.
| Field | Information to record | Review owner |
|---|---|---|
| Software and path | Host application, renderer, versions, operating system, CPU/GPU path and essential plug-ins | Application owner and IT |
| Scene | Approved scene identifier, asset locations, geometry, textures, volumes and demanding features | Production lead |
| Output | Resolution, frame range, passes, sampling/noise target, denoiser and output format | Production lead |
| Candidate | Exact CPU, GPU, RAM, graphics memory, drives and driver | IT reviewer |
| Pilot record | Scene loading, render time, peak memory, warnings, output checks and repeated-run conditions | Technical reviewer |
| Acceptance | Required completion window, visual approval, allowed exceptions and named approver | Production and IT |
Run a controlled render pilot
Save a fixed copy of the scene and settings before testing. Define the acceptance window from the actual production schedule, including preparation and output handling. Record scene loading separately from rendering where possible so a fast render does not hide a slow overall workflow.
Use the same scene, output requirements and software versions across candidates. Where CPU and GPU paths need different sampling to achieve acceptable quality, record those settings and have the production lead approve the comparison. Do not quietly reduce resolution, remove a difficult feature or compare a preview with a final-quality output.
Check the saved result for required passes, missing assets, visual defects and the agreed noise standard. Log failures and memory warnings alongside timings. Repeat the agreed task under consistent conditions and retain the results. A successful frame does not by itself validate the full animation range or every future project.
Illustrative pilot, not a benchmark: A studio needs equipment for product-animation delivery. It selects one ordinary shot and one shot with heavier textures and effects. The production lead freezes output settings and specifies the delivery window. IT records the candidate and licences; the reviewer logs memory and completion results. A build is accepted only after both the output review and the agreed task checks pass. No performance outcome or particular configuration is assumed.
If the team is considering a separate machine for unattended rendering, prepare a distinct requirement using the physical server specification checklist where appropriate. A workstation evaluation does not establish render-farm deployment, scheduling or software support scope.
Frequently asked questions
Is a CPU or GPU workstation better for 3D rendering?
Choose the path your renderer, required features and production workflow support. Compare eligible configurations with an approved scene and equivalent output quality. There is no universal winner across renderers and scenes.
How much graphics memory does a rendering workstation need?
Measure representative scenes in the intended renderer and review its memory rules. Record the peak observed usage, required assets and expected changes. Do not substitute project-file size or combined GPU capacities for a renderer-specific assessment.
Can a modelling test validate final rendering performance?
No. Modelling interaction and final rendering are different tasks. Include both where the same workstation must do both, but record separate acceptance conditions. A smooth viewport does not prove that a final scene will complete within the production window.
What should we send with a rental enquiry?
Send the completed software and scene worksheet, required quantity, location, start date and duration. Identify who approves licences, software setup and the pilot. Ask for the exact offered build and exceptions; confirm any testing arrangement before sending protected assets.