Deconstructing Reality Composer Pro (Inspector Components ...continued)
This latest wave of fixture work extended the reverse-engineering effort across Reality Composer Pro’s built-in components. Now it's documented and implemented more fixture-backed components across Deconstructed and Uncannyuse, including Environment Lighting Configuration, Grounding Shadow, Image Based Light, Image Based Light Receiver, Virtual Environment Probe, Reverb, and the expanded Audio Mix Groups research. The workflow has remained consistent throughout: generate minimal RCP-authored fixtures, inspect the authored USDA, identify the actual value and relationship types, then wire that observed schema back into Deconstructed's inspector and publish the result on Uncannyuse.
One of the findings in this pass came from Audio Mix Groups, which again challenged one of the most common assumptions made when dealing with RCP: not every component is self-contained inline in the UI. In the inspector, Audio Mix Groups looks like an almost empty box that only contains a button. The real authoring flow happens in the bottom panel.
The button opens the Audio Mixer tab; mix groups are created there, audio gets assigned there, and the meaningful authored state lands in child mix-group prims and referenced audio-file prims rather than as a flat parameter list on the component itself.
Another interesting example came from the Image-Based Light Receiver. Its UI suggests that it “points to an IBL,” which makes it easy to assume it references an Image Based Light component directly. But the authored USDA shows something more precise: it stores a relationship to an entity path via iblEntity, and that entity is only valid if it currently carries an Image Based Light component. Again, the visible UI gives you the broad idea, but the fixture diff reveals the actual storage model.
def RealityKitComponent "ImageBasedLightReceiver"
{
rel iblEntity = </Root/Cube>
uniform token info:id = "RealityKit.ImageBasedLightReceiver"
}These are the kinds of details that make the process worthwhile. The goal is to understand the authored data shape well enough to edit USDA files like RCP, not just replicate Reality Composer Pro’s surface.
At this point, the coverage of built-in components is nearly complete. The only major built-in component that remains on the fixture-and-implementation track is Particle Emitter, which will most likely require a different strategy due to its large and combinatorial UI. Aside from that, the other line of work is custom component support, which is handled separately rather than as part of the built-in fixture parity effort.
Now, let's focus on the particle emitter and custom component...
elkraneo
