0

When using the Model Derivative API I successfully generate an obj representation from a step file. But within that process are some quirks that I do not fully understand:

  1. The Post job has a output.advanced.exportFileStructure property which can be set to "multiple" and a output.advanced.objectIds property which lets you specify the which parts of the model you would like to extract. From the little that the documentation states, I would expect to receive one obj file per requested objectid. Which from my experience is not the case. So does this only work for compressed files like .iam and .ipt?

  2. Well, anyway, instead I get one obj file for all objectIds with one polygon group per objectId. The groups are named (duh!), so I would expect them to be named like their objectId but it seams like the numbers are assigned in a random way. So how should I actually map an objectId to its corresponding 3d part? Is there any way to link the information from GET :urn/metadata/:guid/properties back to their objects?

I hope somebody can shine light on this. If you need more information I can provide you with the original step file, the obj and my server log.

Lukas Brunner
  • 5
  • 3

1 Answers1

0

You misunderstood the objectIds property of the derivatives API: specifying that field allows you to export only specific components to a single obj, for example your car model has 1000 different components, but you just want to export components that represent the engine: [34, 56, 76] (I just made those up...). If you want to export each objectId to a separate obj file, you need to fire multiple jobs. the "exportFileStructure" option only applies to composite designs (i.e. assemblies) single: creates one OBJ file for all the input files (assembly file), multiple: creates a separate OBJ file for each object. A step file is not a composite design.

As you noticed the obj groups are named randomly. As far as I know there is no easy reliable way to map a component in the obj file to the original objectId because .obj is a very basic format and it doesn't support metadata. You could use a geometric approach (finding where is the component in space, use bounding boxes, ...) to achieve the mapping but it could be challenging with complex models.

Felipe
  • 4,325
  • 1
  • 14
  • 19
  • Ok, that was the answer I was afraid of. So basically if would extract single objs I would waste all my cloud credits in basically no time. I thought it would make sense to name the poly groups after their objectId. I guess this would not be difficult as the object id is just a 1 based index and the group name after the `g` line prefix can obviously be just a number. Do you think that there may be any chance that such a feature will be implemented in the future? – Lukas Brunner Jan 24 '17 at 18:20
  • It would be a pity if not. Because this little detail prevents me from using any game engine in conjunction with forge in a meaningfull manner. – Lukas Brunner Jan 24 '17 at 18:21
  • Sure, I agree that would be a better approach than a random naming. I've logged this request in our system for the development team. I can't commit to guarantee you it will be implemented sooner or later but you now have a chance :) – Felipe Jan 24 '17 at 19:04
  • Thank you. Is there any official changelog for the Model Derivative API that I can follow? I can't find anything on developer.autodesk.com. – Lukas Brunner Jan 24 '17 at 20:58
  • That should be under the "Overview/Recent Changes" section like for data API: https://developer.autodesk.com/en/docs/data/v2/overview/, but unfortunately it's not there for Derivatives, so I will also bring that to their attention ... – Felipe Jan 25 '17 at 08:28