Commit Graph
14 Commits
Author SHA1 Message Date
itsmattkc f5d66436fa attempt to use fbo clear function 2019-12-10 21:32:21 +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 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 955fac1fbb improved documentation note on audiorenderbackend 2019-11-27 09:51:06 +10:00
itsmattkc 6a27161e96 set params on workers when a backend's params change
Previous iteration had params attached to the backend and the params couldn't
change without being destroyed and re-instantiated. This is not necessary in
this iteration so doing so only wastes resources.
2019-11-23 22:28:06 +09: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 2599c1e8a4 forego memory sample buffer and only write samples that need writing
Rather than writing the entire sequence audio to disk every change, now we
just write the parts we need to write.
2019-11-20 10:32:46 +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 863525c595 remove functions that were moved to the timerange class 2019-11-17 12:31:02 +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 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