[Jasper_]

In most production renderers, you have a soup of objects. Sometimes it's a tree, but much more often it's a graph of nodes pointing to each other.

One of the first steps of this is to gather all the nodes in the graph, flattening it into a list, and then start filtering and sorting it: for every opaque object, you likely toss it in Z-pre and opaque buckets (for objects visible through the main frustum), and a shadow caster bucket (per shadowed light frustum!). So the renderer itself really prefers lists of lists, it does not have trees internally.

React-Three-Fiber seems to take the DOM-equivalent tree, sort it, and then construct a Three.JS scene graph from it, and then Three.JS's render method starts from that scene graph soup and does the above. So one might argue that the tree is a DOM-like interface you're adding on top of Three.JS's scene graph.

[mlsarecmg]

it does not take a dom-equivalent tree, it just expresses the same code you would write out imperatively in a declarative way. threejs is a nested graph after all.

[catlifeonmars]

What is a “DOM-equivalent” tree? Do you just mean a tree?