Hello,
We have seen comments about how it is hard to find something in the Python API documentation.
Would one of these ideas be better for you than what it already available:
If not, what would be your suggestion?
For me personally, the 2nd option sounds the most helpful.
@fredwarren - I’m in agreement with @kyleobley that the second option is appealing.
Moreover, if there is to be an overhaul of the documentation I think now is a great opportunity to provide example code.
If you provide more building blocks, more people will build things.
Just in case you haven’t seen it / didn’t know, there are a few examples in…
@fredwarren - thanks Fred, yes, I trawl the flame help pages daily, frequently around the API section.
My suggestion was too vague.
I’m thinking more along the lines of:
The content of the python file could be heavily commented with examples:
e.g.
And this will provide a framework for everyone to sample all of the good stuff in the Python API.
Currently it’s a bit opaque and the samples are good but focussed.
My $0.02 is that we could all benefit from some very general examples, and most people appear to want to get values or set values.
The second option sounds right to me. I’m frequently in a situation where I know what PyObject I want to deal with but I don’t know the syntax or the available attributes and properties.
Second option sounds great to me as well. I think something right upfront about what a PyAttribute is and very clear demarcation of which attributes of other PyObjects are PyAttributes and not built-in python classes would be very helpful. When I was first figuring out the API I remember frequently getting stuck on why something that appeared to be a string wouldn’t behave like a string until I added .get_value().
I also think the examples for the API and hooks could be integrated a bit more. My hunch is that a lot of people who look up the API documentation are really looking to figure out how to use it in combination with python hooks even if they’re technically separate features. I don’t think it’s super clear right now that the API can’t build a menu item on its own for instance.
@fredwarren - Maybe this should be a feature request for the forum:
Please consider providing building block examples that are fully integrated.
i.e. create scripts that have menu integrations and explain what scoping is.
Provide example that do stuff that people want: (maybe create a survey)
The list is just a start but I believe it’s important that these examples should come from you (Autodesk).
Many companies do not employ flame artists to fuck around with python, since a flame artist’s contribution to the business model is to exploit the power of flame to turn around jobs quickly, predictably and profitably.
Companies that employ people to develop python based pipeline tools often hire people that have no experience or appreciation of flame, are not production-sympathetic, and often the tools that get written are ill-conceived, poorly built and left to atrophy. (or frequently completely shitty)
I’m hoping that you might consider it a good engineering investment to build flame-centric building blocks that anyone in our community can have a crack at.
We expect that flame artists can grasp data management, connected conform, image processing, pipeline wrangling, color conformity, machine learning, finishing and delivery of final pixels.
Writing a few lines of python, especially with the recent ubiquity of large language models, is easily in the realm of most flame artists.
If a flame artist can write an expression or do a connected conform or figure out color science, then python is not beyond the realm of possibility.
You have an opportunity to provide functional and powerful tools that will enable this community to wrestle back the responsibility of creating flame centric and flame focused pipeline tools that are polished by flame artists and engineers, rather than disinterested transient third parties.
Do it Fred.
I know that you can.
I once asked you in a beta preview to make a script that made motion vectors of all the layers in a batch, and I think you delivered that in about two hours.
It blew my mind.
I think it’s still in the examples directory.
Second option sounds like it might be best. Also having examples like the beta docs have would be very helpful. I’ve saved those over the years as reference and they’ve been extremely helpful to go back to.
Mike
Isn’t this what can be found in /opt/Autodesk//python_utilities/examples? There is even a script called object_scoping.py in there.
These could certainly be added to the online help.
Some of these can be found in the online help, but I’m not sure it was kept up to date with the more recent changes.
@fredwarren - That’s hilarious - I’m just the old guy at the side of the road shouting at the traffic!!!
Ignore me!!!
I don’t know why I never thought to just dump those files into /opt/Autodesk/shared/python
Of course they totally work.
Epic fail on my part.
+1 2nd option please
Fred,
One thing that’s confusing is that in the Flame api…“attributes” and “properties” have the opposite meaning they do in Python:
In Flame api…it looks like read only fields = “properties” and read/write fields = “attributes”.
In Python, “properties” have user defined getter/setter function and “attributes” are just instance fields.
In the beginning this was source of frustration until I listened to that first Logik Python talk you had with Andy Milkis.
Oh and the sample python files helped a lot!
easy