Scene graph is widely used?

[rofrol]

This technique is actually [widely used in the game industry][scene]
[scene]: http://en.wikipedia.org/wiki/Scene_graph

from

elm-lang.org/pages/news/blazing-fast-html.elm

Line 90 in 216a365

This technique is actually [widely used in the game industry][scene] and

And then I read this

However, this higher level organization is often waaay simpler than most UI frameworks and this is why I get a bit suspicious about most UI frameworks. Most Big Idea UI frameworks kinda feel like scene graphs to me (an old/failed/abandoned method of organizing 3D scenes), so it makes me suspicious that maybe the UI folks just haven't had complex enough cases to realize what a bad idea that is from both a performance and ergonomics standpoint (i.e. most UIs are just complex enough for scene graphs to seem like a good idea, but not complex enough to make it obvious that they are a bad idea), whereas the gaming folks dropped those kinds of ideas decades ago.

https://www.reddit.com/r/rust/comments/e04b1p/towards_a_unified_theory_of_reactive_ui/f8pz6q1/

These particular "scene graphs" are outdated junk for modern games. There used to be a lot of them, and now they're not very popular (because they're evil). Here's a not too old rant about them.

Because "scene graph" has become associated with this particular meaning, it's a good idea not to call your scene management structure a "scene graph" if it doesn't fit that description of storing render-states in the nodes of a DAG which propagate to child geometry.
Call it the transformation graph, or the visibility graph, etc, instead. Usually a modern scene will be represented via several specialized graphs (or flat lists!), not one of these traditional uber "scene graphs".

https://www.gamedev.net/forums/topic/464464-anti-scenegraphism-a-tale-of-tom-forsyths-scene-graphs-just-say-no/

Also this https://news.ycombinator.com/item?id=13912670

Scene graph becoming less popular. The whole concept of the scene as a tree is good only for editing a scene but translate poorly to a game engine. A lot of meshes in a games are static and don't need any update or hierarchy. Constraints of dynamic objects are usually managed by physics. The few real dependency (light connected to a destructible lamppost) can be handled with a separated list of links.

https://www.reddit.com/r/gamedev/comments/5exges/scene_graph_just_a_question/

[abitrolly]

That's a very interesting question. I spent all morning reading links about scene graph. From what I experienced, game engines usually organize game objects into trees (GoDot for example). However, the actual phase of rendering, physics calculation or processing game logic may be run in parallel using subtrees and lists of objects that are not, strictly speaking, graph traversal through their parent and child relationships. It is hard to reflect all different aspects of interaction between game objects with just a single hierarchy. There are always multiple angles to look at the same tree. Most obvious two are "rendering visible area" and "game logic interaction between objects". For some things it easier to just maintain a list of all objects using a simple query.

However, for web development, it is uncommon to impose even some kind of hierarchy to the app objects. The DOM tree is one of the kind. And it looks like Elm uses some algorithms for the tree transformation and change detection. These are most likely the ones that most widely used. However, it would be very interesting to know which algorithms exactly. And then look for their visualization to understand how they work. :)

The Elm model is a good start to research if it is the actual rendering tree, or just a tree, or a mix of things like DOM rendering tree and logic hierarchy. I think there is something mixed in the Elm about it that needs to be decoupled on examples.

Putting the final touch to it, I wonder what a GUI for real-time representation of Elm model could look like?