I'm finding that the register endpoint (POST https://developer.api.autodesk.com/viewingservice/v1/register) is returning different results for the same file. That is, it's non-deterministic.
Here's the expected result after uploading and registering my scissors assembly: https://gist.github.com/sabrehagen/660dad87c9c5948ec042c62f347a9f1d
Here's a different unexpected result after uploading and registering my scissors assembly: https://gist.github.com/sabrehagen/54aaabaf4651ed8da1911f2494308f05
Here are the files for the scissors assembly.
Why am I receiving different results when rendering the exact same file?
Related
I have some JavaScript that calls the function Autodesk.Viewing.Document.load(...). When I run this locally, I am able to successfully load a model, but when the code is deployed the exact same model returns the error
9: BAD_DATA_NO_VIEWABLE_CONTENT
Any ideas what the issue would be?
There are various reasons why loading a model from Forge could return the error code 9, for example:
you are loading a model that has not been processed using the POST job endpoint yet
the model has already been processed but the translation failed for some reason (use the GET :urn/manifest endpoint to check if you see "status": "success")
the model was translated successfully but there is no actual viewable content in it (e.g. a Revit model with no 2D sheets and no 3D views specified)
the model was translated successfully, but the output derivatives have been removed, either manually (using the DELETE :urn/manifest endpoint) or perhaps automatically after the original file was removed from a Forge OSS bucket
I'm trying to get fragment data using the VRAR Toolkit API so that we can make some optimizations to the mesh data. We can create a scene, process the SVF into toolkit scene, and scene process finishes, but we're having issues when we actually have to get the fragment data.
Using the following endpoint:
https://developer-api.autodesk.io/modelderivative/v2/arkit/MODEL_URN/mesh/MESH_ID/FRAG_ID
Returns a 200 with an octet-stream, but I can't find any documentation as to what the contents of the octet-stream are. According to the documentation (https://app.swaggerhub.com/apis/cyrillef/forge-ar_kit/1.2.1#/ARVR-Toolkit/get_asset_fragment) we can specify whether to use legacy or openctm.
1) What is the legacy format? How can verts, normals, uv, etc. be extracted?
2) I tried the openctm option and saved the returned octet-stream to a .ctm file and tried opening in the OpenCTM Viewer available from (http://openctm.sourceforge.net/) but always get CTM_BAD_FORMAT error when trying to open the file for viewing. How can I confirm my openctm payload is correct?
The SVF format (including the mesh data format) isn't publicly documented but you can get some idea about its structure from the AR/VR Toolkit's Unity package source code: https://github.com/wallabyway/ARVRToolkit/blob/master/unity-src/ARVRToolkit/Assets/Forge/ARKit/MeshRequest.cs#L54-L89.
I tried the method in the object with this RVT urn: dXJuOmFkc2sud2lwcHJvZDpmcy5maWxlOnZmLk1HQm5UX2MtVFhteHRzZzJZY2NXR3c_dmVyc2lvbj0x
I get this response with status code 200 {"data":{"type":"metadata","metadata":[]}}
I cannot extract properties using the model derivative API.
Hi we had a similar error where meta was empty.
This was because the upload had succeeded (we got a urn) but the translation had failed and getting the meta information on failed translation just returned an empty meta repsonse. This was specifically with revit files.
If you check the manifest endpoint with that urn do you see and revit file translation error?
The model viewer has the ability to get properties by passing a filter: viewer.model.getBulkProperties(dbIds, ['externalId', 'Category'], function) where we can limit the results to just the two properties 'externalId' and 'Category'.
It would be a huge benefit for us to have this same filtering capability from the model derivative api:
https://developer.autodesk.com/en/docs/model-derivative/v2/reference/http/urn-metadata-guid-properties-GET/
We have Revit files with 40,000+ parts, and it can take over 15 minutes to query for properties, but we are getting far more data than we need.
it is a reasonable enhancement. I logged it as an internal ticket DERI-4610.
If you have used Extractor to download the whole SVF dataset to local , you could try with extract the properties from properties.db (the other post tells more). This is a lite sql database which is actually used by Derivative API on Forge cloud. I'd think there is some smart ways to filter the specific properties by the db file.
I am reviewing the possibility of using NoFlo as an Orchestration Engine.
To keep a "Separation Of Concerns", and using NodeJS, I will basically create a RESTful API, using Express, that will have a series of POST and GET requests. This RESTFful API will interact with the Orchestrations, (i.e. NoFlo Graphs and Runtime) by starting and stopping graphs in the runtime. From a behavior point of view, a POST requests will start/stop an Orchestration and a GET requests will get information about the Orchestration (i.e. Status, Errors...). From a state point of view, a POST will create an Orchestration and a GET will enumerate the Orchestration.
Based on what I read in various Stack Posts (i.e. - Starting out with noflo, running it from nodejs) it appears possible but I still have a few questions. Here is one of them.
Is it possible to load a JSON Graph from memory into the Noflo runtime, instead of having a persisted file then loading it into the NoFlo Network from this file? I would like to load the graph as a JSON object.
I am trying to do two thing with this:
- Load and Save Graphs to a Database.
- Have a UI manage these Graphs in the Database.
Any thoughts on this question and topic would be greatly appreciated.
Yes, it is possible to make NoFlo run a JSON (or .fbp) graph definition from memory, from a file, wherever.
This happens in two steps:
Load the graph string/object into an instance of noflo.Graph
noflo.graph.loadJSON(graphDefinition, function (err, graph) {
if (err) {
// Handle graph loading errors
}
// Now you have a graph object, you can create a network from it
});
Instantiate a NoFlo network based on the graph definition
noflo.createNetwork(graph, function (err, network) {
if (err) {
// Handle network setup/starting errors
}
// Now you have a running network object. You can use its
// lifecycle events and methods to interact with it
})
Additionally the graph object loaded above is "live", so if you make changes to it, the network will react accordingly. This means you can add/change nodes and connections at runtime.