I was thinking about building an internal tool builder for tech artists. Something like a https://retool.com/ or https://dagster.io/ but with a focus on Maya, Blender, and PyQT intergrations.
Imagine a world, where you can drag nodes, each representing some function within a software. Let’s say Maya or Blender. File conversions and connections with version control/review control will be handled underneath using USD and OpenAssetIO. Basically, you don’t have to re-write your pipeline. Then, you can use a drag and drop interface, and connect your APIs to a PyQT front-end.
Happy to go into more detail of above if there is interest ^^^
Probably would like to start small, maybe focusing on simple integrations like Maya Rigs → Unreal Rigs or whatever. Or display all assets from Shotgrid in Houdini. Any ideas for this?
Would love feedback on my random idea. Might be completely useless, or if it resonates please let me know. If it’s useless, would love to chat about why?
If there are internal tools that you have been struggling to build, let me know. Or if you are working on migrating your pipeline to USD, OpenReview, etc then let’s connect.
It was supposed to be a standalone node-based tool. It would have ‘universal’ (e.g. running an app or a Python script) and ‘specific’ (e.g. Maya-only) nodes. It was supposed to be highly scalable (adding an extra PC for processing was supposed to be as easy as adding a node).
Automated reports, visual debugging, abstract templates, automatic UI generation for user input, support for Deadline, web support, activity monitoring, cross-platform, automatic deployment – the works!
Made a whole presentation for top heads and even had a name for it!
Got a raise out of it but eventually switched to making games
ah yes. Interesting. If it’s in your backlog, it’s probably more of “nice to have” than something that you need to have? Any reason, why that’s the case? @Munkybutt
I’ve not.
Very personally, I avoid node based editors like the plague. I find they get out of hand and become a spaghetti storm to quickly for them to be useful to me compared to me just writing the code myself.
The framework would have to be EXTREMELY good and manageable (read as maintainable) for me to even consider suggesting it to be used in our pipeline as we have a lot of python modules/classes that we can re use across our current slew of DCC’s (which gets more maintainable as DCC’s have finally gotten onto py3)
Nah. It never went past the concept stage.
But if I ever get back to pipelines, I’ll probably try to resurrect the thing – it had a lot of cool ideas in it.
