Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

# Implement a rendering graph model #3

Open
fughilli opened this issue Apr 19, 2022 · 3 comments
Open

# Implement a rendering graph model #3

fughilli opened this issue Apr 19, 2022 · 3 comments
Assignees

Comments

@fughilli
Copy link
Owner

Ideas:

  • Specify port types. Perhaps ports can be one of kModel, kRender, or kRaster
    • Model ports are for model data (verts, UVs, etc.)
    • Render ports have backwards-facing attributes for applying transforms before rendering and specifying the raster to render to
    • Raster ports are for raster data and metadata (size)
@fughilli
Copy link
Owner Author

Initial design document

Started work in the graphs branch

@fughilli
Copy link
Owner Author

conversion declaration, opaque data storage, and a minimal graph model are implemented (the graph model only supports linear graphs, which is not very useful at the moment).

I think a nice short-term goal to be able to start playing with the features consists of:

  • support arbitrary render graphs (implement an actual graph representation in opendrop::Graph with appropriate edge storage/aliasing)
  • support constructing graphs from textproto files (and saving them, too?)
  • finish the "minimum satistfaction" feature for arbitrary graphs where there are dangling inputs

@fughilli fughilli self-assigned this Apr 19, 2022
@fughilli
Copy link
Owner Author

fughilli commented Aug 7, 2022

An initial model is now implemented and merged. There is a lot of cruft left over that should be cleaned up:

The OpaqueTuple abstraction should not own memory. It should be just a mechanism for converting from a set of pointers to data to a tuple of typed references and back. The outputs of all nodes in the graph will have memory owned by the graph itself; the nodes will only own memory used to track their internal state. The input to the whole graph is provided by reference at the time of Graph::Evaluate(), and thus does not need to be owned by the graph.

Types should be default-constructible--it was a complete headache trying to work around how to be able to construct memory for a Type without statically knowing its C++ class type. All memory for a graph will be default-constructed and then initialized appropriately on first mutation.

The implementation should be revised to achieve this simpler model.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant