Roji Research.
Render-oriented
joint interface.
Technical validation.

One Electron shell hosts five core research modules: Roji Graph, Shaderverse, the 3D Viewer, Roji Render's setup surfaces, and Roji AI as the operator layer over readable graph, USD, shader, render and log data. The experiment tests whether all of this can share UI conventions, scene state and technical context without turning each step into a separate handoff.

JavaScript & TypeScript across the UI, the backend and the native scripting runtime (Electron + Vite + React), Python for the USD scene-graph layer (Pixar's USD/pxr API: composing stages, reading and authoring prims and attributes, with an in-memory stage cache), and native C++ for the rendering core (Embree + OptiX), the Hydra viewport (USD + Hydra Storm), and the EXR viewer (OpenEXR + OCIO 2). JS and TypeScript drive the interaction and scripting, Python composes and authors the USD scene, and C++ handles the pixels.

It is a research question. The interface is a web layer kept separate from the native engines, so the same interface can run in an ordinary browser on any device while the engines run on a local machine, a remote host or a cloud. The heavy compute stays wherever the engines run; the device sends commands and receives results. Roji Web EXR and Roji WebHydra are the implementation studies for heavy workflow data transfer online: full EXR, USD, texture and render data stay close to the native engines, while the browser receives viewer frames, controls, summaries and review state. Roji Render can also run fully headless from the command line, and AI-accessible control of the same pipeline is under test. This is studied as a research configuration, not offered as a hosted product or a cloud-render service.

USD has layers, sublayers and session layers. They track authorship at the layer level. Roji's provenance experiment records which graph node wrote an authored opinion, so an overridden attribute can be traced back to the node that produced it. The goal is deterministic technical lineage stored with the scene, not just held in the app.

The research started as a review function for a running render: a supervisor could receive the validation file through email or Teams, open it on an authenticated device, and inspect the render without needing access to the render workstation. From there, the stats file developed into a richer single-file dashboard. Per-lightgroup AOVs are embedded as image data, sliders re-composite the frame in the browser, and additional diagnostics can travel with the same file. No plugin, install or server upload is required for the validation file.

No. Roji is presented here as public R&D documentation, not as a commercial replacement for Houdini Solaris, Katana, Maya, Blender or any other DCC tool, and not a replacement for RenderMan, Arnold, Karma or any other rendering engine. The research explores a different integration model: USD scene authoring, lookdev, viewport inspection, rendering and review sharing one technical workspace.

Roji Render is being tested against production-scale USD scenes, including public benchmark datasets, on ordinary artist workstations where many pipelines would split, cache or stage data before final rendering.

The research also tests whether graph authoring, CELs, previews, AOVs and final frames can run through one render path rather than a separate host integration.

It also studies CPU/GPU parity validation and the granularity and range of rendering complexity, so a simple scene and a large-scale scene converge on the same render process. The larger research goal is whether the whole system can live in a CPU/GPU farm environment end to end: readable graph inputs, headless render commands, farm logs, final EXRs, Roji Web EXR review and traceable fixes.

Shaderverse tests shader authoring and material-transfer behavior: BSDF graphs, OpenPBR-oriented parameters, MaterialX-style exports, package manifests and assignment metadata that can be inspected by USD-aware tools in a human-readable environment.

Yes, as a research direction. Shaderverse includes early tests around game-style shader graphs, and Roji Render is used to compare CPU and GPU paths against the same scene, shader, lighting and AOV tests.

Yes, as a research question. The position behind Roji is that generative AI should belong inside the 3D scene-building and validation process, not only at the end as a final generated image. Current tests evaluate whether control passes, depth, motion guides and structured scene data can be compared against generation workflows while keeping renderer context explicit, and whether generative AI can be integrated into a spatial render through the path tracer.

Farm support is a research and validation area. Roji Render can run headless in research tests, and the work is exploring command-line rendering plus submitter concepts for Deadline, Tractor and OpenCue-style environments, with AI-assisted data monitoring and wrangling. The CPU/GPU parity research is tied to this: the target is an end-to-end farm workflow where CPU and GPU jobs can be compared, reviewed and debugged without losing the human-readable source of the shot.

Roji is not currently offered for public sale, download or public use, and no pricing or release commitment is being announced on this site. Private technical validation discussions are now open for DCC providers, render farms, R&D teams and pipeline groups evaluating the research direction.

The research uses plain USD scene data, MaterialX-oriented shader graphs, standard EXR outputs and standard AOV naming where possible. Round-trip behavior with Houdini, Maya USD, Blender USD and Omniverse-style workflows remains a technical validation area.