Lumenarium/todo.txt

195 lines
6.2 KiB
Plaintext

TODO FOLDHAUS
Ground Up Reengineering
- Metaprogramming
- panels metaprogramming
- fix memory layout (remeber to profile before and after)
- Make the DLL truly platform agnostic
- math.h: present for trig functions
- windows.h: only thing left is InterlockedIncrement and InterlockedAdd
- Win32 Platform Layer
- Enumerate Directory Contents (you started this in win32_foldhaus_fileio.h)
- Internal Log File
NOTE: This should not be a part of the debug system
- Save output log to a file continuously
- Have a window where we can view the log within the app
- Create a bar that displays the most recent error message
- :ErrorLogging
- Make sure it works without building in Debug Mode
- Buckets & Lists
- Allow them to use memory arenas
- Zero is initialization
- Rendering
- OpenGL 3
- Vertex Buffers
- Layers
- Lighting
- Clipping (with error checking)
- Sculptures
- store scale in the assembly definition file
- cache led vertex buffers
- custom sculpture update functions (for motion)
- placing sculptures
- editing sculpture files (change universe output)
- led groups & subgroups - defined in file
- Network
- Handle Error Cases
- Handle connecting a sculpture after launch
- Artnet
- Universe offsets (per sculpture)
- Interface
- Layout functionality
- styling
- text input
- lister with icon options
- panel system: destroy panel by extending it beyond its max, not just its min
- Asset Loading
- images
- icon system - integrate with interface
- Sculpture View
- mouse spatial interaction - handles, and hover for info
- debug capabilities (toggle strip/led/universe colors)
- Animation System
- snapping clips
- blending between animation
- layers
- layer masks by sculpture
- blend modes
- Node System
- automatic node layout
- blending node layouts
- workspace -> animation block
- generating node workspace as code
- compiling node workspace
- hotload compiled pattern sets
- Serialization
- saving scenes
- saving node graphs
- saving animation timelines
- saving projects
- Settings
- Platform Layer
- Mac Platform Layer
Reimplement Node View
- probably want to take a fresh pass at nodes all together
Assembly -> SACN interface
x you need to rebuild the map from leds -> universes
- x thinking about storing a sparse array of { led_start_index, led_count, led_universe, led_channel }
- that we can iterate over to populate dmx buffers
- need to create a data structure in CreateDMXBuffers that prevents duplication of DMXBuffers.
- - thinking about a dictionary. Key is Universe, length is 256, create parallel arrays as necessary
BUGS
- Typing a period into a float value doesn't register. Problem here is that we arent' translating key presses into characters at the win32 layer. Need to do that.
Switch To Nodes
- BUG: Connect a solid color node to output then try and pick a color. I think temporary node buffers are
- overwriting other data when they get evaluated. Bigger solution is to create a system of working
- led buffers that get assigned to nodes as needed.
- gonna need to remove output node from the node lister
- delete nodes
- - Simplify node storage
- - investigate if node connections can be operated on separately from the node headers
- - UpdatedThisFrame can probably go into each connection
- - Allow insertion/deletion within connection table
- - Allow inerstion/deletion within header table
- - maintain free list of connections and headers
- separate node functionality from drawing the nodes
- - pull node position, size, etc out into a parallel data structure. after split names: node_header, interface_node
- - create separate files: foldhaus_node_engine, foldhaus_node_gui
- - store interface_nodes in binary tree
- - allow panning and zooming around the node canvas
- - Investigate why we're giving nodes bounds :NodesDontNeedToKnowTheirBounds
- selector node (has a list of connections that it can switch between)
- Serialize Nodes
- evaluation step (one node at a time)
Hardening
x turn the default sculpture view into an operation mode ? (have to think about this)
- Then we want to think about separating out mode render functions from mode update functions. Not sure its necessary but having something that operates like an update funciton but is called render is weird. Might want some sort of coroutine functionality in place, where modes can add and remove optional, parallel
update functions
- memory visualization
- x Log memory allocations
- separate rendering thread
UI Improvements
- highlight node field under active edit
- Mouse Held Commands
- Actual cursor states
- shift drag to 10x drag speed
- Text editing improvements
- - draw cursor in node field under active edit
- - better/intelligent zero padding
API Improvements
Application
- More efficient HSV <-> RGB
- Save and load a session
- Don't render if the window isn't visible
Development
- Fix your scope time tracker to account for threads.
- Nest scope times so you can see totals/dig in
Interface
- fullscreen
- In world interface elements
- - Handles for Patterns
- - UI Popups
- - Value modifiers
- Scroll view
- Update the text system - use system fonts
Structure
- motion
Renderer
- Render layers
- Mouse Picking - point at a led and see info about it
- Camera: pan
- Camera: zoom
- Camera: leds always face camera
Resource Management
- TODO: Need to figure out which textures are currently in graphics memory and which need to be resubmitted
- Icons
Animation
x timeline
x create clips that play
- clips can have parameters that drive them?
Optimization
- investigate the memory access pattern of the SACN / LED systems. Guessing they are very slow
x look into why debug logging functions seems to incur a large hit on framrate
- patterns are asking to be multithreaded
- probably want to convert as much color functions to use u32 Packed Colors
- - Probably want to think about this more. What about supporting different color depths
- for different output devices?
Name
- Splash screen (like blender) (thisll be fun)
- - Image importer (stb image? or find a png > bmp converter for the image you have)
- - Display on startup