Commit Graph
23 Commits
Author SHA1 Message Date
itsmattkc 8ace197d66 improved backend encapsulation
Various backend improvements are included in this commit, mostly for the
benefit of exporting. These include:
- Moving more non-GL code from OpenGL derivatives into base classes
- An "export mode" that changes the cache behavior of video backends
- Using the Viewer's UUID introduced a few commits ago
- No longer hardcoding the pixel format/render mode in the backend (since
  they'll inevitably differ when exporting vs previewing)
- Improved signalling for frames that are completed
2019-12-20 04:35:31 +11:00
itsmattkc 3d3e40d431 minor code cleanup and fixed opengl thread desync issue 2019-12-11 03:20:23 +11:00
itsmattkc f5d66436fa attempt to use fbo clear function 2019-12-10 21:32:21 +11:00
itsmattkc c35a6d009d removed unnecessary debug messages 2019-12-10 00:57:28 +11:00
itsmattkc 26b3993b9d made vast improvements to rendering engine and node structure
This was many changes that were largely fundamentally related. They included:
- More const modifiers to enforce read only node graphs
- Support for fragment and vertex shaders from the nodes
- Support for node code loaded externally (embedded into the binary)
- Fixed issue preventing two textures from being used in a shader
- Removed several unused functions and cleaned up code
- Fixed video media node misreading its matrix input
2019-12-09 23:50:52 +11:00
itsmattkc f6064b40df hold worker busy state in renderbackend rather than in renderworker
Workers run in different threads and the backends can poll whether the worker
is currently busy or not. However the previous iteration has the worker (and an
atomic int) provide the busy state which could easily desync with the main
thread (since all workers run in different threads). By holding the busy states
in the main thread, the main thread will always be able to poll the busy state
accurately.
2019-12-06 19:38:57 +11:00
itsmattkc 5227e10f39 render one frame per thread for increased parallelism
If the nodes are now stateless, there's nothing stopping the renderer from
rendering multiple frames at once. Earlier since the nodes held some of their
input/output data (and that data could change per frame), it was not possible
to render multiple frames at once without conflicts. Now that the node state is
held in render threads, they can do whatever they want at any time.
2019-12-06 15:37:31 +11:00
itsmattkc 694f424627 finished conforming renderers to new node structure
Stateless node system is done! Functionality is about equal to the functionality
in master meaning this is ready for merging.
2019-12-06 03:43:24 +11:00
itsmattkc d25dda5275 removed all dependence on NodeOutputs
If Nodes only have the one output, we don't need to do so much differentiation
between them. Previous iteration used outputs as like a distinct function
within a Node (e.g. length output would return one result, buffer output would
produce a different result - each run different code to produce their results).
Now in this iteration, it's more accurate to say a Node is just one function
(which seems more appropriate for a node system anyway).
2019-12-06 00:23:26 +11:00
itsmattkc 88c3bd44a5 rewrote node data types as or flags
The data types can now be or'd to match broader data types.
2019-12-04 20:26:43 +11:00
itsmattkc 44d649903c copy values whenever the cache is invalidated
Since we're now working with a separate proxy copy of the original node graph,
if the user changes a parameter in one of those nodes (triggering an
InvalidateCache signal), the values in our copied graph need to be updated
with these new values too.
2019-11-23 17:06:49 +09:00
itsmattkc 2cfccbfbef copy node graph before rendering
Previous iterations would use mutexes to prevent changing of the graph
mid-render, however several user actions would need to capture these mutexes
causing the main thread to hang until the current render job (frame/range of
samples) was complete. We now copy the nodes necessary as part of the "compile"
process so that the main thread shouldn't need nearly as much blocking while
caching occurs.
2019-11-23 08:53:52 +09:00
itsmattkc 8e6c23ffc1 fixed bug that caused some frames to never render indefinitely
Frames should no longer get stuck unrendered.
2019-11-17 17:14:08 +09:00
itsmattkc 9d154e1909 use different signals when the audio invalidates vs the video
Both audio and video renderers were working off the same invalidation signal
(i.e. changing audio would also trigger a re-render of the video). This is
obviously suboptimal and now they are separate.
2019-11-17 13:44:50 +09:00
itsmattkc 40b3879440 overhauled render classes to support video AND audio
Major refactoring work to try sharing as much code as possible between the
video renderers and audio renderers, as well as make them as
platform-independent as possible.
2019-11-15 13:50:58 +09:00
itsmattkc 7a6dd02e5b furthered development of audio renderers
Mostly reimplementing functions from other workers to produce audio samples
2019-11-11 11:35:01 +09:00
itsmattkc 1206eb73b9 moved frame cache to external class that's easier to pass around 2019-11-06 23:46:44 +11:00
itsmattkc 97a4294bb3 refactoring work to improve issues with new rendering pipeline 2019-11-04 11:34:43 +11:00
itsmattkc c14125e640 work towards rewriting the render infrastructure
Mostly foundational work and re-implementing older code in a smarter way
(i.e. context creation code should be slightly faster than it was before)
2019-11-01 22:58:02 +11:00
itsmattkc b56fbaae51 began port of previous renderer iteration to new iteration
This will essentially be a full rewrite, but very incrementally to save time
and energy.
2019-10-31 21:59:20 +11:00
itsmattkc 55f7d6aa8a restored previous renderer iteration for porting 2019-10-31 20:06:11 +11:00
itsmattkc 77bcb70dac started porting renderer to new portable form 2019-10-31 19:14:58 +11:00
itsmattkc 401aff52a8 attempts at folding opencl support in 2019-10-28 18:21:20 +11:00