According to my understanding (and our previous discussions), render_queue represents different rendering stages in the renderer, each with its own logic and render pass. In this case, I think objects of type weighted should clearly use a separate render_queue, since their processing logic and the render pass they require are entirely different.

I really think Almar should be able to detach himself from this topic now so other work also gets some attention, maybe you can create small PRs to address these concerns, and we can talk about them there?

I encountered these issues while continuing #974 (merging the main branch into #974), so I left a comment here. They may be discussed again in #974.

Have you tried changing the classification logic to see if it resolves your issues in #974?

I don't think we need a special render_queue for weighted. I don't like the idea to reserve a range of render_queue values for it, if that's what you mean.

The important thing is that if you have a mix of weighted and composite objects, that the weighted objects are grouped together. And this happens already because of the different sorting approach (for weighted objects the dist_flag below is zero).

In other words, if a user has a mix of weigted and composite objects, on the same render_queue, then the weighted objects are rendered last. Users can always assign a render_queue to explicitly render them earlier or later.

The final render order is tied to the scene graph. What are the benefits of this design? 🤔
Personally, I believe render_order should be an independent property of an object and should not be influenced by its parent nodes. The scene graph is primarily for organizing objects in the scene and handling transforms; it doesn’t have a direct relationship with the drawing order of objects.
Moreover, for many users, their main concern is simply adjusting the rendering order of certain objects through render_order. They neither care about, nor should they be required to care about, the details of the scene graph.

Can you create a PR with a small example to illustrate this concern? Then we can discuss it there and have a focused discussion.

I agree with your position that render_order should be an independent property, but I am curious to hear Almar's consideration.

In ThreeJS the renderOrder is inherited from the parent, but only if the parent if a group (or something along this line).

I think having this behavior is useful; if you want an object to be rendered later/earlier than other objects, it's likely that you also want this for the children. And I figured its more elegant to make it consistent, rather than depend on the type of the parent.

Though I can imagine that this backfires when there are multiple children with different render_queues. Maybe the inheritance should only kick in if the render_queue matches? Anyway, let's discuss this in a new thread.