0

We have followed the step-by-step tutorials for the model-derivative apis. I can use the /manifest endpoint to get the object tree. I can also create tasks to get a .obj file with geometries of some objects. There is no way to know which geometry belongs to which object.

I could potentially create a job for each object, but that would require thousands of jobs per model which seems excessively inefficient. Are we missing something? Any pointers on how to get geometry for objects while retaining the mapping between them?

Augusto Goncalves
  • 8,493
  • 2
  • 17
  • 44
hk1ll3r
  • 811
  • 1
  • 6
  • 14
  • if you need an .obj for each piece, then you need to call it for each dbId, or some formats accept a single .obj. What's the file format you need? – Augusto Goncalves Aug 22 '17 at 20:16
  • Thanks Augusto. We do some analysis on the geometries of the entire model. For example we detect overlaps between geometries and would want to show the user which objects overlap by highlighting the elements in the viewer. We are not concerned with the file formats as long as we can get the geometry information for ALL objects in the model and know which geometries belong to which objects. The online viewer has access to all that information through the svf format, any reason the APIs don't provide us with the same level of detail? – hk1ll3r Aug 23 '17 at 21:16

1 Answers1

0

The Viewer will extract the information, but as of today, we don't have a documentation for SVF, so it may get trickier to analyze the geometry from this file. You may use JavaScript, something like described in this sample or this sample.

You can extract the OBJs for each element, but may need a big number of jobs. In this case, you need to run your code for .obj files.

Glorfindel
  • 21,988
  • 13
  • 81
  • 109
Augusto Goncalves
  • 8,493
  • 2
  • 17
  • 44