wow the autodesk fusion 360 API docs are interesting. it seems like they're trying to see how much documentation they can write without possibly being useful
I'm looking at a Profile object. I see it has a property called profileLoops. Oh, handy, maybe I need to look at a ProfileLoop.
I click it, and it tells me that Profile.profileLoops is a read-only property that returns a ProfileLoops.
I click, and it tells me ProfileLoops is a collection of ProfileLoop objects.
I click item, it tells me it returns a ProfileLoop object. I click it, and now, and only now, am I looking at a ProfileLoop definition
to import an SVG, you get the ImportManager from Application, then call ImportManager.createSVGImportOptions(filename) and then set parameters on that object, then call ImportManager.importToTarget or ImportManager.importToTarget2
@foone For years I asked people on /. why json was better than XML and always got the "it's more compact" answer, which is bogus (it's easy to encode the same information in XML as compactly as in json.) But someone did eventually give me a good answer: you've already got a json parser, 'cause json is basically javascript. You need to pull an XML parser over the wire. But I gotta say something about XML seems to encourage people to use it in the dumbest possible way.
this is mainly because I'm annoyed that python's elementree will not round-trip SVG files because it buggers the namespaces in a way that's valid for XML but breaks SVG parsers.
(if you use lxml's etree support, it doesn't do this)
this API was designed by someone with a pathological fear of globals.
you can't just do like createOpenFileDialog
you need to get an app from the adsk.core.Application.get() static method, then get the userInterface from the app, then userInterface has a createFileDialog method which gives you a file dialog you can configure and then open with fileDialog.showOpen()
@foone Somewhere, there's a very satisfied dogmatic engineer and architect, and a team that answers to them complaining about perpetual increase in scope and burnt out on legacy
It's great because a lot of these classes are just wrappers of collections and Python is one of the official languages supported by their add-on API but they don't appear to have considered making them more usable by python
actually, no! they are slightly more usable than I thought.
you CAN natively iterate them, it's just you can't if they're slightly more complicated than a list wrapper
@foone
See, this is why I follow you. I'm retired for, like, 10 years now and you articulate, ever so agonizingly, the same absolute frustration that any developer, ever, had to endure trying to write anything functional without saying "Fuck it! I'll do it in assembly. I'll make my own, damn, API. Callable by whatever language I want. Piss off!"
this would be fine (keeping the same units throughout in code makes a lot of sense), except THE FUCKING API ALREADY HAS A NUMBERS-WITH-UNITS wrapper. It could have just given me a value that knew it was in inches and transparently converted to centimeters if I wanted centimeters!
and I'm having to show a list of tools to the user, and the ones they normally see in the UI are specified in inches, because they are american tools. This means that when I try to print their sizes as-is, I don't get "0.25inches", I get 0.3169463409805995 because IT DOESN'T CONVERT TO A NICE EVEN NUMBER OF CENTIMETERS
like my favorite silly fact about floppy disks:
5.25" disks and 8" disks are that size. 3.5" disks aren't. They're 90mm disks.
(5.25" and 8" were designed by americans, 3.5"/90mm disks were designed by a japanese company)
the worst part is that it's not even actually specced as 0.25" and it's not shown that way in the GUI.
The normal GUI, which I can't use, says it's a 1/4" bit.
So fusion 360 already contains code to display these tools in a "pretty" manner, it just won't let me access it. So I have to rebuild that
the other fun thing is that I'm sorting through tools and I'm afraid my metadata doesn't contain if they're upcut or downcut. that's a pain, but I only have a small number of tools, surely I can cross-reference with the manufacturer?
yeah, and they indicate if they're upcut or downcut... for 3 out of the 5 tools
I'm now getting the error "object is not in the assembly context of this component" and I google it and there's one reply and they've got a solution but I don't understand it but they link the manual and I don't understand it and I keep closing my eyes and seeing the forest and the deer looks up and whispers "join us"
it's so quiet and dark
the manual is like "the problem is that these two highlighted faces are actually the same face, but you can modify them separately in the GUI using proxies".
the way to fix it is to half-press A and then spend 12 hours building up speed until your de-facto speed matches your syncing-speed and you can execute a QPU movement that'll put you in a parallel universe but you have to avoid QPU misalignment and my ears are bleeding
autodesk: well the component knows where it is at all times. it knows this because it knows where it isn't. by subtracting where it is from where it isn't, or where it isn't from where it is (whichever is greater), it obtains a difference, or deviation.
@foone you are doing infinitely better that me with f360 if it's any consolation to you. the whole workflow it wants where you have to basically define everything of a shape via its relation to every other shape before the shape actually exists is completely incompatible with my brain and i immediately give up and go back to moi3d
the answer apparently was that I need to use the right moveFeatures. See, it's not just a factory method and you can just use the design.rootComponent.moveFeatures, you should make a moveFeatures out of the component you're moving.
@foone Friend of mine wrote a text conversion tool for autodesk maybe 25 years ago. Unless it's changed, bet it hasn't, everything about object position and rotation is a trashfire.
@foone I've definitely seen plenty of C++ code written by former Java devs who thought that C++ and Java were "the same as each other" and it's usually pretty janky. Never seen it go fully down the BuilderBeanBuilderFactory hole though.
@foone
Yeah, namespaces kind of suck. If you ever try to create an XSLT template, it's not so bad... right up until you run into a namespace and then a whole new world of debugging pain opens up for you. Because it either works, or it doesn't. There is no in-between.
@foone I find when you generate your doc from annotations in code, and combine that with template and lambda concepts, the generated doc becomes thoroughly unusable. Extension methods can get ugly too if there are enough of them.
@foone I don't know details about autodesk, but this sounds somewhat like a legacy codebase that was created in Borland C++ times. They always had this horrible Delphi-Runtime, that sounds like .Net, feels Java-ish, has horrible almost-nonexistent generics and infects many derived APIs with lots of anti-patterns. These codebases adopted python runtimes later on.
@foone I’ve gotten the impression that people who learned C++ in the last 20 or 25 years use it like “Java with pointers”. I liked it better as “C with classes”
@foone are you familiar with the automatic documentation writer tools that are/were popular for a while in Very Enterprisey companies? This was years before the current LLM fad, so the results were a much more profound level of uselessness: https://blog.submain.com/ghostdoc-says-the-damndest-things/
@foone to be fair, there is strong and robust competition in the category of extensive but nearly unusable documentation. Gotta keep up with competitors!
Add comment