If you could create a database from flame, that took your sequences, shots, and all of the extrapolated info, and created video thumbnails, metadata, and a website, what would be the most important digital content creation tools to interact with?
Maybe Iām nuts but I would approach it differently. Instead of building an export for a specific system, build an export for standard publish container formats.
For Houdini or Maya that would be USD, but in Flameās case concentrate on exporting otio info. Surest way to have other systems import that dataā¦ eventually.
Thatās what theyāre all moving towards anyway, with simple hooks to push or pull open standards on either side of the process. That way hooks are simple to write.
Via a hook, system A is told shit out an otio file here and system B is told import said otio file that was just exported. Easy peasy lemon squeezy. Conversion to and fro is handled app side and not in the exporter.
Maybe crap out XMLs as a backup . And for shots of course itās batch files and openclips.
I guess the question to start with - what problem are you trying to solve? Wasnāt clear to me from the āsurveyā?
Or are you asking what is folkās most pressing unsolved problem, which ADSK is unlikely to get to anytime soon, that another tool could fill the gap?
Iām just getting started on Postgres for resolve in order to discover correspondences with flame.
Itās no secret that I think openclip is the glue that helps flame fix all of the other problems that come from other software.
OTIO should be exportable from a database - I canāt guarantee that I can work out timewarps - the best brains on the planet havenāt solved that one yet, so my chances of success might be slim.
Anyway - thatās what I wanted to know - if some kind of database and some kind of universal metadata could be used as some kind of rosetta stone.
Ambitious I knowā¦
can you build something that is better than flow. shouldnt be hard - that thing sucks
Bahahahaha
@Jonhollis - ābetter than flowā? - probably not - Iām just a bear of very little brain and most of my stuff is āsucksā adjacent.
@cnoellert - Chris - I think I requested USD support a few years back - Iām pretty sure the request is in the feature request db.
As far as writing a USD template - I think itās ASCII under the hood?
The thing that always kneecaps my efforts is proprietary formats.
Hmm, might be a rabbit hole.
Itās not a public API with any guarantee of cross version consistency. In fact BMD has upgraded the schema regularly between versions. Could become a versioning nightmare.
Also you would have to reverse engineer their transaction locking scheme to avoid corrupting the database with dramatic consequences. Iāve looked at that a few years ago with db utilities and their schema.
Writing directly to an sql db bypassing the application layer can be playing with fire. Reading is more forgiving, but not without risk.
It may be safer to go via the Resolve python api. Not sure if itās comprehensive enough though.
@allklier those are all good observations, and funnily enough I just noticed that there is a Python api for resolve 19 studio.
Iām not sure but I think the Python api is relatively new.
Iāll start reading.
Thanks for the perspective
Might be interesting to just add thumbnails to xmlās since all the other data already lives in that so could be xml 2.0 which would be really nice universal format that could be used for producers as well since it would have thumbnails and marker notes etc
Maybe something like this Embedding Images in XML - Altova Blog.
The more I think about it this would be a nice universal way to go , parse the data from xmlās to convert to something of a more universal format since the timelines could contain tags (status) , thumbnails , marker notes etc etc
So every export or publish would be accompanied by an xml which then could be converted to a pdf or whatever by a script
For cases like that look at what tools like YoYotta do when they generate a report after ingesting a camera reel.
I have some experience with Resolves API, including some experiments with Openclipā¦ which btw may be better aproached with Lua. Let me know of any questions.
A REALLY rough experiment that led nowhere after learning the limitations of the method.
@milanesa - thanks for sharing
I just landed in France and will be here for a minute
I didnāt bring a workstation with me but should have access to a few over the next week.
Iāll dive in when time permits
i am in the early process of building something similar completely based on openclips
ā i dont want any flame python api dependency stuff just openclips
ā external service that runs in docker or whatwver that just scans openclips and then represents then in whatever way on a website (for example frameIO or whatever else)
ā it should pull all the other metadata like shotname and stuff from the openclip and the path to the openclip , like what project folder it is inā¦
I am mostly looking at frameIO 4.0 as a hub for this , they have shot management, task assigment etc. the api isnt there yet but thats the horse I am betting of
sonething like
-
scan project server , create a project in frameIO for all found projects
-
scan each folders shot folder , each published openclip is in shottree/metadata
then create a shot folder in frameIO -
render each version found in the openclip as h264 , using ocio config and a basic set of rules as yml config file in the root of each project with the defaults in the root of the project server
-
upload h264 to frameIO
-
push a notification to slack
-
In flame have a python tool that pulls comments from frameIO to markers or something
-
profit
Make it node based!
Use Gafferā¦ you can turn each task into a Deadline jobā¦ with dependencies based on the graph. Easy setup/maintain, and you may be able to hook OTIO.