Table of Contents Show
For those who don’t know the tool: Roji sits between OpenUSD assembly, MaterialX lookdev, OpenPBR shading, viewport review and final-frame rendering. It is aimed at lighting, shader, render and pipeline teams testing connected scene state.
Beta scope
Roji Research/ Rabia Rahou has opened beta registration for a rather interesting render-oriented joint interface that connects lookdev, USD scene assembly, MaterialX shading, native rendering, browser review, and AI-assisted render operations into a single nodal workflow. The beta includes Roji Graph, Shaderverse, Roji Render, 3D Viewer and Roji AI.
The current public R&D material is “just” technical validation for artists, TDs, DCC providers, render farms, R&D teams and pipeline groups. It is not public access, not a commercial release and not a hosted cloud-render service. No pricing or release commitment is there yet.
But if you want to see it running on AWS, here you go:
USD graph and scene state
Roji Graph is built around USD authoring with a human-readable graph state. The graph is saved to JSON, while Python handles the USD scene-graph layer through Pixar’s USD/pxr API, including stage composition, prim and attribute authoring, and an in-memory stage cache. Native C++ handles the heavier viewport and rendering engines. The practical question for USD rendering teams is whether authoring, inspection, and render state can remain traceable without bouncing through a stack of loosely related tools.
The Manipulator experiment records which graph node wrote a USD opinion. Edits can target transforms, authored USD attributes, primvars, materials and overrides. The goal is deterministic provenance: an overridden attribute should trace back to the manipulator, node, and layer that produced it, rather than becoming just another mystery override in the shot. USD itself tracks composition through layers, sublayers and session layers, so this adds graph-level authorship on top of normal USD authorship.
Large scene handling uses lazy loading as the default behaviour. Heavy scenes switch to streaming mode above 500 MB, roots stay protected through anonymous session layers, outliner loading can be cancelled, and prim-load progress remains visible. The R&D target is near-real-time exposure of renderable prims in 100k-plus-prim scenes without first expanding the whole stage. Roji’s graph uses UsdStage::LoadNone First, then loads only the required branches, which is the same version of “open the shot” when the shot is trying to eat your workstation.
Roji does not flatten USD by default. Manipulator overrides and Graph operations are authored as USD layers or layer overrides, with composition arcs, layer order and override sources remaining inspectable. Flattening is available through USDLive Bake only when a delivery, pipeline request or frozen tree needs it. Downstream tools receive plain USD rather than a private scene blob.
The lighting path uses USD Lux authoring through the same graph. The tested light types include Distant, Dome, Sphere, Disk, Rect, Cylinder, Spot and Portal. The lighting notes also cover IES parsing through IESNA LM-63, cookies and gobos, barn doors through standard light:filters relationships, Kelvin colour temperature with blackbody conversion, lightgroups, emissive mesh promotion to importance-sampled lights, portal lights for dome and interior sampling and a Roji-native object light multiplier for CEL-targeted receiver and refraction exposure control.
MaterialX and OpenPBR
Shaderverse targets MaterialX and OpenPBR-oriented lookdev, with material data stored as USD Shade prims inside USD look layers. The package is designed to carry the material graph, prim-binding assignments, texture references and primvar requirements as USD, so MaterialX-aware DCC and USD pipelines can inspect the result without a proprietary wrapper. MaterialX itself is an open standard for material and look-development exchange across applications and renderers, while OpenPBR defines a standard surface model for practical CG materials.
Shaderverse writes MaterialX node identifiers onto USD Shader prims. USD material and binding layers carry prim-binding assignments, texture references can resolve relative or absolute paths and material-authored AOV outputs travel with the package. Roji Render scans connected upstream materials and writes those material AOVs as EXR AOV layers or sidecars. Standard .mtlx import and export are listed, along with a Shaderverse Read node for live linking into Roji Graph.
The OpenPBR-oriented closure set includes layered base, specular, coat, fuzz and transmission lobes. The material tests also list Burley and random-walk subsurface scattering, Marschner hair and fur with melanin-driven colour, anisotropic microfacets with tangent control, transmission, IOR and attenuation controls for glass, water and clear materials, plus volume and displacement outputs. That is a broad closure matrix, but the important production detail is less glamorous: the graph, assignments, shader identifiers and texture paths remain readable.
Texture support in Shaderverse covers PNG, JPG, EXR, HDR, TIFF, Pixar/RenderMan .tex and .tx, UDIMs and frame sequences. RTEX is Roji’s sidecar texture cache, with pre-baked mips that can be built ahead of time or regenerated when missing or stale. The R&D notes also list Ptex .ptex and .ptx, triplanar and hex-tiled utilities, procedural noise, fractal, cellular, Worley, flakes and curvature nodes, channel operations, ramps, masks, material blending, coat-over-base layering, visual node feedback, live material thumbnails, CPU/GPU preview swapping and per-material displacement subdivision settings that travel with the material package.
Hydra viewer, not a dumb preview
The 3D Viewer is a native C++ USD/Hydra viewport based on UsdImaging and Hydra Storm. Multiple viewer instances can attach to different graph branches, so one branch can play while another stays editable. Each branch can keep its own camera, shading mode, selection and memory behavior. The viewer is limited by hardware budget rather than one global viewport state, which is exactly the kind of constraint artists prefer over “please wait while everything refreshes for no reason.”
Roji WebHydra keeps USD and Hydra on the workstation and streams viewport frames into Vite/HTML rather than moving scene data into the browser. The current implementation sends GPU H.264 over WebSocket from the Hydra backbuffer using CUDA/OpenGL interop and NVENC. Browser controls send camera, frame, draw-mode, selection and overlay deltas back to the same session. Current tests reach around 40 fps. // Not independently verified at press time.
Viewport budget behavior keeps heavy geometry as a bounding-box proxy until promoted. The viewer can open heavy nodes without forcing full-detail expansion, control instance density, promote selected proxies to real geometry and work with visible RAM and VRAM caps. Solid, texture and wire draw modes are listed, along with shader-aware and texture-aware feedback. A Moana Island Scene viewport benchmark lists a 71 GB USD scene running live on a Ryzen 7 7700 with 32 GB RAM and an NVIDIA GeForce RTX 4060 with 8 GB VRAM. // Not independently verified at press time.
Native rendering and AOVs
Roji Render uses a native C++ renderer core with Embree 4 for the CPU path and OptiX 8 for the GPU path. Embree is Intel’s high-performance ray tracing library for graphics application developers, while OptiX is NVIDIA’s programmable GPU ray-tracing framework. Roji’s backend parity work compares CPU and GPU output through explicit separate render paths rather than mixing them inside one layer.
The renderer R&D covers large USD scenes, OpenPBR and MaterialX-oriented shading, volumes, AOVs, deep EXR and CPU/GPU parity. The public parity record lists a 99.01 percent result in a strict stress-test environment across lights, OpenPBR shaders, camera effects, AOV/LPE, volumes and materials.
For the large-scene benchmark, Roji H.U.G.E., short for Hyper-Scale USD Geometry Engine (Funny how that Abbreviation worked out :P ) , bakes a large USD payload into a granular cache before rendering under a fixed workstation memory budget. The Moana Island Scene test records a 5m 22s bake, a one-take CPU render, 55 GB render memory budget and 11h 6m 51s render time on a Ryzen 7 7700 with 64 GB RAM and an RTX 4060. The listed containers are Roji Clusters, Roji Blocks with .rblk files and Roji Objects with .robj files.
Shader-input transfer tests include RenderMan PxrSurface, PxrVolume, UsdPreviewSurface, MaterialX standard_surface and OpenPBR inputs. Texture transfer tests include images, UDIMs, frame sequences, .tex, .tx, .ptex and .ptx. Closure coverage under test includes OpenPBR and MaterialX-oriented surface response, anisotropic GGX, Walter BTDF, dispersion, dielectric coat, SSS, hair, fuzz and thin film. Caustics are listed through transmission-ray contribution in a large-scale scene.
The per-CEL sample-budget experiment assigns local sample ceilings, minimum samples, adaptive noise targets and bounce depth to selected objects or CEL selections. An object-id sidecar verifies which camera-visible surfaces received a budget assignment. The measured goal is whether priority objects can improve without raising global samples for the whole frame.
Denoising uses Intel Open Image Denoise on HDR beauty and AOV output, guided by albedo and normal buffers where available. If guide buffers are missing or mismatched, Roji falls back to color-only denoise. If denoise fails, the raw noisy image remains rather than failing the frame. Denoised EXR siblings can be written for review while preserving the original render.
Browser EXR review
Roji Web EXR mirrors the local 2D Viewer contract in Vite and HTML. The workstation reads the OpenEXR, applies the selected OpenColorIO display/view, extracts the requested AOV or light layer and serves a browser-native preview image. The source multilayer EXR remains beside the native review path, while the browser receives color-managed preview frames.
The browser review surface covers catalog review, OCIO display/view, exposure, alpha, AOV inspection, deep/meta views and lightgroup review. Roji Web EXR requests OCIO-transformed 16-bit PNG previews per render, AOV, alpha mode and exposure. Lightgroup relight can mix embedded light AOVs in preview space without a new render, and deep comp research keeps deep layers inside the render review path for inspection.
Each test render can also write a self-contained *_render_stats.html file. The light mixer embeds lightgroup AOVs as encoded RGB data, decodes them in JavaScript, adds the groups in Canvas 2D and redraws the mix live. The file can include embedded OCIO display/view LUTs for the same ACES/sRGB view across desktop, phone or tablet. Export Mix writes a JSON of lightgroup values that can be loaded back into the graph as a new Manipulator.
Production read
The useful technical idea is a shared, readable state model across USD composition, material authoring, viewport inspection, render setup, EXR review, logs and AI-assisted operations. The risky part is the same as always: real shots, broken references, bad paths, half-trusted caches, farm variance, artist timing and the glorious habit of pipelines to fail only after final delivery. Test Roji on duplicated assets, controlled USD layers and non-critical shots before any production use. Which you shouldn’t consider anyway, because it is an early preview, and a research project, not even a “Release Candidate Beta”.
