View in #blender on Slack
@bclark: The always generic answer is, but you have the entire application source code, just write it in C and make it work, why do you need an API…
those people I just auto-ignore
@passerby: yeah hate when people do that
but these are the same ones that do not understand the value of lts versions or sticking to constraints like the vfxplatform
@probiner: Isn’t that similar to C++ Maya plugins?
@passerby: no
C++ Maya plugins are way way easier to maintain then maintaining your whole build of the whole pacakge
since you are using a stable API that is not going to change without notice between versions
@bob.w: Yeah, Autodesk goes to great lengths to keep the C++ API stable. You might still need to recompile because of ABI changes, but you shouldn’t have to rewrite your code because they (re)moved a symbol
@passerby: even the abi changes are like once a year sometimes less
@bob.w: Yeah, its usually a “we bumped the visual studio project, please rebuild”
@passerby: recompiling when changing major versions is not the worst, but 99% of the time all you need to do is the recompile, and the rest works since the API is stable, and if things are to be removed you get years of notice, and just some depreciation warnings
@instinct-vfx: The only time i actually had to put some work into our plugins was the introduction of unicode all over. Everything else was really minor
@passerby: also just a bad excuse, seen it come up with Unreal before anytime i criticized the bad C++ documentation, of people being well its open source just read the code
@instinct-vfx: That’s part of the problem as a whole though. Not understanding the value of proper documentation
@bclark: Well for Blender- documentation is up to the devs and the community as well. People don’t often think about or appreciate how hard it is to do good docs.
@instinct-vfx: Yeah. Having a technical writer makes a whole lot of difference
@bob.w: Good documentation is a career path honestly
And Technical Writers are worth their weight in “super expensive dense things”
@Nick_Anderson: Just popping in to say I’m very new to pipeline integration and I find these sort of discussions super insightful. I’m a guy who for example didn’t understand why we needed a C api. Really helpful
@bob.w: or magic crypto coins, whichever
The lack of a C API isn’t a deal breaker all the time. But if you can’t make something work with the exposed python API (which is blender’s plugin API) then you’re stuck.
@bclark: and or there are just some speed limitations or needed to protect code that can’t happen with python only.
@bob.w: Right, using python for your plugin API comes with downsides, that not every studio/team/project can handle
@passerby: i generally never worry about protecting code
@bob.w: it being the sole API can be deal breaker, but it can also be a “meh”
@passerby: but yeah python would be too slow for some uses, like if they had api for doing geo nodes
@bob.w: And of course, not every feature/system is exposed to their plugin API, they’ve got internals that aren’t stable and as such aren’t user facing
Which is disappointing but again, they probably wouldn’t expose that to any kind of stable plugin API anyway until they worked through it
no matter the language
@passerby: well pretty common not to expose new things too
@instinct-vfx: I am a fan of making exposing a first class citizen. Expose early, but mark as unstable
AD actually did quite well recently, e.g. with the new BTT stuff
@bob.w: unstable is honestly ignored as often as deprecated in my experience
But I do agree that is the best way to do it
@instinct-vfx: true, but then it’s your fault heh
@passerby: @instinct-vfx so expose it, but do not let changes in it effect your semver?
@bob.w: its just often the people who ignore the road signs are also the first to cry when their car explodes 
@passerby: since the issue becomes if i expose api too early and it changes then i keep needing to jump major versions
@instinct-vfx: Hm. It also depends a lot what you expose and how that works. e.g. in Max a lot of things are actually developes as plugins nowadays that also implement maxscript exposure. So things are less “this is in the core”. That eases update paths and also enables more modular deployments
@passerby: yeah that seems to be why unity is breaking things out to pacakges
though the docs suffered hard for it
@Nick_Anderson: Unity has always impressed me with it’s documentation. In the past they’ve made it a priority. Hope they continue to do so.
@passerby: the might fix it, but i find with packages the discoverability of docs is far worse
and the quality of these new package based docs is not as good as what its replacing
but yeah the core stuff is really good, and some of the best docs i seen for a game engine
@instinct-vfx: What would you people say is the best developer docs overall that you know? Always looking for good examples
@bob.w: Unity, python (standard library anyway, no clue about the deeper docs)
Qt
@passerby: Unity, .Net, Go
@tbwright: I just saw this posted on Twitter so I’ll add my 2 cents: The Python version being out of step is a barrier, but even more daunting is just the time investment
Unless we learn it in our off hours or slow down production to learn and force the change, it’s just inconvenient and inefficient to learn a new piece of software Just Because
It wouldn’t do anything for us Max/Maya aren’t already doing
@instinct-vfx: Thanks guys
That might actually be something nice to have. On github there are all these awsome-xyz link lists. Might as well have one already. hm
