Transition to a graph-based API#2332
Draft
HoloTheDrunk wants to merge 44 commits intoiTowns:masterfrom
Draft
Conversation
improve post-processing example shader
Add needsUpdate forward propagation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
This is still in early development and the PR was only created to improve the visibility of progress and allow discussion regarding the design of the new API.
Note: merge conflicts with #2300 will not be an issue given that most if not all of the work towards this goal is isolated in a new folder.
Description
This PR aims to expose a generic and extensible directed acyclic graph (DAG) API over iTowns' features.
This API should also expose ways to automatically optimize the graph.
The graph should be made in such a way as to allow the progressive coverage of iTowns' features.
As a side-effect, this PR also adds support for a progressive transition to TypeScript.
Motivation and Context
iTowns currently holds together through sheer willpower, hopes and dreams.
By creating a more user-friendly API that improves feature discoverability, we aim to progressively replace old interdependent code with a more functional style of isolated units of computation, guided by the constrained environment of a DAG.
This will ideally lead to an API reminiscent in concept of Blender, VTK, DaVinci Resolve and many other modern applications and libraries that have chosen a similar data flow representation for its simplicity and ease of use among other benefits.
Since graph nodes can contain arbitrarily complex code, this would also allow for easy higher-level API development by library users targeting non-technical users by simplifying the creation of no-code but still powerful visualization tools.
Example
The
examples/effects_postprocessing.htmlfile has been altered to use the new API, showcasing what it allows.The graph for that example ends up looking like this (generated by the included dot dumping utility methods):
Base
Optimized (only optimization available as PoC right now is screen shader merging)