V-Ray Tip: V-Ray and Corona Asset Migration Best Practices

Moving assets between V-Ray and Corona is increasingly common across Chaos pipelines. Use these best practices to preserve look parity, avoid surprises, and keep renders predictable.

• Plan the direction: decide early whether this is a one-time handoff (e.g., V-Ray to Corona for final) or a round-trip. Round-trips demand stricter naming, version control, and feature parity.
• Lock units and scale: ensure scene units and system units match before converting. Physically based lights and camera exposures depend on consistent scale.
• Normalize color management: stick to a single colorspace (e.g., ACEScg for rendering, sRGB for textures unless data/linear). Confirm gamma overrides for normal, roughness, and metalness maps are set to 1.0.

Materials

• Prefer physically based models: map VRayMtl to CoronaPhysicalMtl (metalness workflow) or vice versa. Keep IOR-based Fresnel; avoid legacy spec workflows.
• Glossiness vs roughness: if you see mismatches, invert where needed. Modern V-Ray supports roughness mode; verify the toggle before converting.
• SSS/skin and volumes: profile shapes differ. Start from engine-native presets (V-Ray Skin, Corona Skin/PhysicalMtl SSS) and match reference renders rather than relying on blind 1:1 parameter copies.
• Textures: confirm normal map orientation (OpenGL vs DirectX). Re-check triplanar/procedurals—procedural features might not have exact equivalents.

Lights and Cameras

• Intensity units: keep photometric/candela/ISO-consistent. If a scene looks over/underexposed after conversion, verify camera ISO, shutter, and f-stop first.
• Environment: V-Ray Dome Light with HDRI generally maps to Corona’s environment slot; confirm invisible-to-camera/reflections refractions flags.
• Portals: avoid legacy portals when using modern environment sampling (both engines have optimized skylight sampling). Remove portal flags if they linger post-conversion.
• LightMix: both engines support LightMix; rebuild Light Select/LightMix groups intentionally rather than relying on automated grouping.

Geometry, Proxies, and FX

• Proxies: prefer native proxies per engine for reliability (VRayProxy/vrmesh in V-Ray, Corona Proxy/cgeo in Corona). If keeping VRayProxy in Corona, test on a small subset first and ensure the required plugin is available at render time.
• Displacement: Corona’s 2.5D displacement differs from V-Ray’s. Match edge length/px size and subdivision quality by eye on close-up tests before committing.
• Hair/fur: use engine-native hair shaders where possible. Validate backlighting and translucency; tweak melanin/specular parameters after conversion.
• Phoenix/volumes: reuse caches but reassign engine-native volume grids (VRayVolumeGrid vs Corona Volume Grid). Confirm step size and emission/scatter mapping.

Render Elements, Denoising, and Post

• Render elements: map essential AOVs explicitly (beauty, diffuse/albedo, reflection, refraction, specular, SSS, Cryptomatte, Z). Names differ—align to your comp templates.
• Denoisers: iterate with fast GPU/Intel denoisers; finalize with the engine-native production denoiser you trust. Always compare denoised vs raw for texture retention.
• Tone mapping: VFB stacks aren’t identical. Rebuild exposure/white balance/filmic curves and LUTs in the destination VFB, then save as presets.

Conversion tooling and process

• Use the vendor-provided converters (e.g., Corona Converter for 3ds Max, Scene Converter tools) as a starting point—not a finishing step.
• Validate with a look-matching checklist: gray shader pass, albedo check, key materials close-up, a lightmix comparison, then a 5–10 frame wedge for animation stability.

Need both engines, upgrades, or support? Partner with NOVEDGE for licensing and integration advice. If you’re building a mixed-engine pipeline, consult NOVEDGE to standardize color, asset, and render-element conventions across teams.

You can find all the V-Ray products on the NOVEDGE web site at this page.