TODO FOLDHAUS 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 - cache led positions. Only update if they are moving 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 - 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