Closed meshula closed 3 years ago
Good point, checking the time should be sufficient. The layers are a relatively new addition and a bit WIP, so there are probably a number of areas that could benefit from optimization.
As a side note the compositing of the layers is very simple right now and there are probably lots of ways to break it (for example having multiple tracks with overlapping dissolves). It probably really needs a proper compositing DAG with intermediate buffers...
Before jumping ahead to that, I'm building a tiny interface base class for Render so I can get things up and running in Metal, so let me sort that first :)
Wracking my brain on how to deal with OCIO at the moment. Hoping there's a LUT baker somewhere that I can use to precook the textures for the shader...
For the "should render" check, I suggest adding a helper to Frame along the lines of bool Frame::needsRerender(const Frame& previousFrame) so that the logic can be centrally consistent no matter what happens internally with layers and whatnot.
Very cool!
Yeah, the OCIO support is going to be tricky, maybe even more so with OCIO v2. You may have seen in Render.cpp where OCIO can generate an arbitrary number of 3D and 1D textures that are then passed to the shader. I would imagine the textures are straightforward to import into Metal, the tricky part is the custom shader code that OCIO generates to use the shaders:
p.ocioShaderDesc = OCIO::GpuShaderDesc::CreateShaderDesc();
p.ocioShaderDesc->setLanguage(OCIO::GPU_LANGUAGE_GLSL_1_2);
p.ocioShaderDesc->setFunctionName("OCIODisplay");
It looks like there is an open OCIO issue for adding support for Metal shaders: https://github.com/AcademySoftwareFoundation/OpenColorIO/issues/907
There is ociobakelut
, but it will come with a number of limitations:
https://opencolorio.readthedocs.io/en/latest/tutorials/baking_luts.html
That's a good suggestion for the helper function, I'll try adding it.
I added a convenience function for comparing the time value of two frames and updated the tlrplay-glfw code to use it. Thanks for the suggestion!
Efficiency question... It's sufficient just to compare frame.time, isn't it? the frame comparison also compares layers. Even if layers changed mid frame, we've already rendered for the time, in other words if time didn't change and layers did, I don't think it's necessary to trap it.