Cloud and Mobile

Autodesk.Hyperlink Extension of Forge Viewer

By Xiaodong Liang

 

Autodesk.Hyperlink Extension of Forge Viewer is a feature that can display the corresponding view of the tagged geometries. It is introduced since Forge Viewer 2.10.

The gif below is a demoing.

When we wanted to test the feature, we hit an issue: with the sample model of Revit (rac_advanced.rvt),the links are available, but they are external id only. Debugging the code, it looks it cannot find a corresponding bubble, so it treats it like a real hyperlink with ‘http://’. Obviously, ‘http://’ + external id is an invalid link.

 

 

 

 

 

With the guidance of engineer team, we got to know to work with this feature, it is required the linked views have been published with the model.This is the tutorial of publishing views.

 

 

In addition, we need to use the skeleton of initializing Forge Viewer by ViewingApplication, which can ensure to load the related bubbles.

By default, the extension is loaded with initialization. If not, we can explicitly load it:

Viewer.loadeExtension('Autodesk.Hyperlink');

 

Standalone Executable Project of Forge Viewer on PC without Internet by Electron

By Xiaodong Liang

 

Forge Viewer is a browser based technology, i.e. structure of BS. Although Forge Viewer supports offline mode, you will still need to setup a server-client environment. It is not a problem to run a localhost on the PC, however it would not much be practicable if you configure a localhost on the PC of your customers. 

Recently, I got to know Electron. As it says: Electron provides the way to build cross platform desktop apps with JavaScript, HTML, and CSS. By this mean, your project will be looked like a standalone executable project, similar to typical desktop application. Electron accomplishes this by combining Chromium and Node.js into a single runtime and apps can be packaged for Mac, Windows, and Linux. So if you worked with a Node.js project, it will be more easier to migrate it to an Election stuff. 

Quite a lot of tutorials are available with Electron community. In this blog, I will simply describe how to build a skeleton with a demo of Forge Viewer in offline mode.

1. Clone the minimal Electron app, install the npm modules and test the app. 

   # Clone this repository
   git clone https://github.com/electron/electron-quick-start
   # Go into the repository
   cd electron-quick-start
   # Install dependencies
   npm install
   # Run the app
   npm start

The app will look like the snapshot below. We can even debug, check network, element etc. These are similar to the practices in Chrome.

 

 

 

 

 

 

 

 

For more details of the skeleton, please refer to http://electron.atom.io/docs/tutorial/quick-start.

2. On Extract tool of Forge Viewer, upload your model file and follow those steps to get the offline package. Unzip the package

3. Create a new folder in the root of Electron project (say ‘Forge’), copy the contents of the package in #2 to this folder.

4. Edit main.js of Electron project to load the index.html in Forge folder. 

  // and load the index.html of the app.
  mainWindow.loadURL(url.format({
    pathname: path.join(__dirname, './Forge/index.html'),
    protocol: 'file:',
    slashes: true
  }))

5. npm start to run the application. a failure would probably occur that indicates jQuery is not defined. This is because of this code:

  if ( typeof module === "object" && typeof module.exports === "object" ) {
  // set jQuery in `module`
   } else {
  // set jQuery in `window`
  }

The jQuery code "sees" that its running in a CommonJS environment and ignores window. With the workaround, add two lines in ./Forge/index.html:

 

 

 

now, you can see the project is running well. To make it fits well with the window, I adjusted height of div of viewer to 550px. In addition, the application icon can be modified by editing the line in main.js. 

function createWindow () {
  // Create the browser window.
  mainWindow = new BrowserWindow({width: 800, height: 600,icon: __dirname + './Forge/Tools.ico'})

6. The steps above are for debugging mode. To make a release version, install the electron-packager. in the terminal, type:

npm install electron-packager -g

next, follow the format below to package:

      electron-packager < sourcedir > < appname > --platform=< platform > --arch=< arch > [optional flags...]

e.g. on my Windows 10 OS, electron-packager will produce Windows version by default.

   electron-packager  “C:\temp\electron-quick-start” MyForgeApp

after the packing, a new folder will be generated. There is an executable application in the folder. Now, you can distribute the package as a typcical desktop application to your customers.

 

 

 

 

 

 

The full source of my demo is available at:

https://github.com/xiaodongliang/Forge-Viewer-Electron-PC

From what I googled, it is a bit pity Electron has not well supported the version for mobile. I am looking for other approaches such as Cordovar. If you know any ways, I'd love to have your sharing. Thank you.

Update: I have figured out one way to produce app of iOS by Cordova :) This is the other blog which tells more:

http://adndevblog.typepad.com/cloud_and_mobile/2017/01/standalone-app-of-forge-viewer-on-ios-by-cordova.html

Setting up external references between files

By Adam Nagy (@AdamTheNagy)

When the Data Management and Model Derivative API's got introduced, replacing the previous ones that were bundled with the Viewer, then you had to upload complex models in a zip file. By complex model I mean those that consist of multiple files referencing each other. In case of AutoCAD DWG files these references would be called "XREF's" in case of others it's just "File References" or "Referenced Documents"

The good thing about using the zip approach is that it contains all the files needed in a single place and so the Model Derivative service can resolve all the references automatically. The bad thing about it is that you might have to upload the same file again and again in different zip files in order to create viewables that can be shown in the Viewer.

The Data Management API is now capable of setting up XREF (it's going with the AutoCAD naming convention) relationships between files which will be honoured by the Model Derivative API when it's doing a translation.

Note: relationships can only be set up between files that reside in the same A360 (or Fusion Team, BIM 360 Team) Project.

To show how it works I uploaded an assembly and a referenced part document to A360. As you'd expect, the translation of the part file succeeded, but the assembly's failed:

If you check with a sample app like http://derivatives.autodesk.io/ then you'll run into the same issue, that the translation fails for the assembly:

With that sample you can also check the manifest of the file in the Console window of the browser and you'll find the reason why the translation failed. Which is, as expected, that the part file could not be found:

Using the POST /relationships/refs endpoint of the given file version on A360 you can add 
xrefs:autodesk.core:Xref relationship from the assembly to the part, which will be honoured by the Model Derivative API when doing the translation and looking for the part. 

The version id of the files I'm using:
AssemblyTest.iam (v1): urn:adsk.wipprod:fs.file:vf.cwgYCF5LQOShkzKA414Zbw?version=1 
AssemblyTest.ipt (v1): urn:adsk.wipprod:fs.file:vf.E0ObBbVgQP-Nko5AfMNHDw?version=1

Using those we can send this POST request:
https://developer.api.autodesk.com/data/v1/projects/a.cGVyc29uYWw6dWUyOWM4YjZiIzIwMTQxMTI4NjQ1MzQwNg/versions/urn%3Aadsk.wipprod%3Afs.file%3Avf.cwgYCF5LQOShkzKA414Zbw%3Fversion%3D1/relationships/refs

Body:

{
  "jsonapi": {
    "version": "1.0"
  },
  "data": {
    "type": "versions",
    "id": "urn:adsk.wipprod:fs.file:vf.E0ObBbVgQP-Nko5AfMNHDw?version=1",
    "meta": {
      "extension": {
        "type": "xrefs:autodesk.core:Xref",
        "version": "1.0",
        "data": {}
      }
    }
  }
}

Now we need to ask for the SVF translation of the assembly again. In order to do that you can either use the x-ads-force: true header value when POST-ing the job,  or delete the manifest of the assembly before asking for the translation (that would delete the result of other jobs as well though).

After that the translation succeeded:

And now the relationship shows up in A360 as well:

 

Selective explode in the viewer

By Philippe Leefsma (@F3lipek)

    Here is a question that was asked by a developer during our last accelerator: How to exclude some components from being exploded in a model?

    Well, there is no API method directly exposed to achieve that, so I dig in the viewer source code and extracted the piece of code that handles the explosion transforms, then customized it a bit by adding an if condition that will prevent the passed fragment ids from being transformed.

    Here is the method, I named that selectiveExplode: 

    You can cut and paste that code here to quickly test it, simply replace the load method by this one with predefined fragment Ids:

    This will prevent the carburator ("Carb:1") from being exploded:

Forge Formats Python Scripts

By Jeremy Tammik.

I just published the beginning of a new collection of Forge Python scripts, currently with a count of one:

py_forge_formats.py implements a Python wrapper around two basic RESTful Forge web service calls:

• Authenticate an app – forge_authenticate_app
• Query the file formats currently supported by the translation processes – forge_formats

The result is prettified using the jprettyprint helper function.

The mainline ties it all together and presents the final result, which looks like this at the time of writing:

$ ./py_forge_formats.py
9 Forge output formats:
  dwg: f2d, f3d, rvt
  fbx: f3d
  ifc: rvt
  iges: f3d, fbx, iam, ipt, wire
  obj: asm, f3d, fbx, iam, ipt, neu, prt, sldasm, sldprt, step, stp, stpz,
    wire, x_b, x_t, asm.NNN, neu.NNN, prt.NNN
  step: f3d, fbx, iam, ipt, wire
  stl: f3d, fbx, iam, ipt, wire
  svf: 3dm, 3ds, asm, catpart, catproduct, cgr, collaboration, dae, dgn,
    dlv3, dwf, dwfx, dwg, dwt, dxf, exp, f3d, fbx, g, gbxml, iam, idw,
    ifc, ige, iges, igs, ipt, jt, max, model, neu, nwc, nwd, obj, pdf,
    prt, rcp, rvt, sab, sat, session, skp, sldasm, sldprt, smb, smt,
    ste, step, stl, stla, stlb, stp, stpz, wire, x_b, x_t, xas, xpr,
    zip, asm.NNN, neu.NNN, prt.NNN
  thumbnail: 3dm, 3ds, asm, catpart, catproduct, cgr, collaboration, dae, dgn,
    dlv3, dwf, dwfx, dwg, dwt, dxf, exp, f3d, fbx, g, gbxml, iam, idw,
    ifc, ige, iges, igs, ipt, jt, max, model, neu, nwc, nwd, obj, pdf,
    prt, rcp, rvt, sab, sat, session, skp, sldasm, sldprt, smb, smt,
    ste, step, stl, stla, stlb, stp, stpz, wire, x_b, x_t, xas, xpr,
    zip, asm.NNN, neu.NNN, prt.NNN

This script replaces and improves on the previous forgeauth and forgeformats Unix shell cURL scripts documented in the discussion of the cURL wrapper scripts to list Forge file formats.

For the sake of completeness, those two scripts have been added to this repository as well.

Setup and Usage

Two aspects need to be prepared: Forge and Python.

Before you can make any use of the Forge web services, you will need to register an app and request the API client id and client secret for it at developer.autodesk.com > my apps.

These scripts assume that you have stored these credentials in the environment variables FORGE_CLIENT_ID and FORGE_CLIENT_SECRET.

Regarding the Python components:

• Install Python.
• Install the requests Python library.

Now you should be all set to run as shown above.

forge_authenticate_app

forge_formats

jprettyprint

Mainline

Forge Viewer Consolidated Geometry

There is an endpoint to know which versions of the viewer are available. Checkout the https://developer.api.autodesk.com/viewingservice/v1/viewers endpoint.

it would return a list like the one below – Model Consolidation, which brings performance enhancements is coming with v2.12+

[
  "2.12.60",
  "2.12",
  "2.11.58",
  "2.11.57",
  "2.11.55",
  "2.11",
  "2.10.58",
  ...
]

Performance Enhancement: Model Consolidation

Model Consolidation optimizes a model for faster rendering by using mesh consolidation and hardware instancing.

An optional value can be specified to control the amount of GPU memory spent for mesh merging. Default value is 100MB.

Consolidation requires the full model to be in memory first. I.e., progressive rendering will have the unoptimized speed until loading is finished and the consolidation step is run.

The optimization step is most effective for models where the large shape count is the main bottleneck. E.g. models like the NWD model can be rendered several times faster

Example:

var initializerOptions = {

   env: 'AutodeskProduction',

   useConsolidation: true,

   consolidationMemoryLimit: 150 * 1024 * 1024 // 150MB - Optional, defaults to 100MB

}

Autodesk.Viewing.Initializer( initializerOptions, function() {

  // ...

});

Some Limitations

# It requires significant extra memory (CPU-side and GPU-side).

# Consolidation will be turned off automatically when playing animations or exploding the model.

# Consolidation reduces the granularity of the scene, which conflicts with existing techniques like progressive rendering, fine-grained frustum culling, and sorting (e.g., for transparency).

Application buckets & Translation in .NET C#

By Augusto Goncalves

Yet another project that uses Autodesk Forge implemented in .NET C#: this time using application buckets on your webapp. 

This solution consists in 3 projects: a class library that wraps some OSS and Model Derivative APIs, plus Authentication; a ASP.NET project that implement WebAPI endpoints with a pure HTML5 & JavaScript UI (no .aspx pages); and finally a Testing project. 

Most libraries have a raw implementation of endpoints, so this sample tries to organize them in a meaningful way: first instantiate a app buckets, from where you can either get a list of buckets or create new ones, then using this bucket object you can upload and translate files. As everything is strongly typed (i.e. no random strings), this approach helps avoid problems passing wrong types.

Please note this is not our official library, but yet an experiment that still under development, so feedback is very welcome! 

Below is a sample piece of code that demonstrate the idea:

// authenticate
OAuth.OAuth oauth = await OAuth2LeggedToken.AuthenticateAsync("Your client ID", "Your client secret",
new Scope[] { Scope.BucketRead, Scope.BucketCreate, Scope.DataRead, Scope.DataCreate, Scope.DataWrite });

// create bucket and get list of buckets in different conditions
AppBuckets app = new AppBuckets(oauth);
IEnumerable<Bucket> buckets = await buckets.GetBucketsAsync(10);

// create a random bucket
string bucketKey = string.Format("test{0}", DateTime.Now.ToString("yyyyMMddHHmmss"));
Bucket bucket = await app.CreateBucketAsync(bucketKey, PolicyKey.Transient);

// upload new object
OSS.Object newObject = await bucket.UploadObjectAsync(testFile);
// this URN can be used on the viewer
// but need to translate first...
string newObjectURN = newObject.ObjectId.Base64Encode();

// the list after should have 1 object...
IEnumerable<OSS.Object> objectsAfter = await bucket.GetObjectsAsync(int.MaxValue);
foreach (OSS.Object obj in objectsAfter)
{
    string urn = obj.ObjectId;
}

// translate
HttpStatusCode res = await newObject.Translate(new SVFOutput[] { SVFOutput.Views3d, SVFOutput.Views2d });
// now this newObject is ready for Viewer

Forge API outage

By Stephen Preston (@_stephenpreston)

(Update 12/8/16 4.40pm Pacific Time)

We wanted to provide you with some additional information about this recent outage of the Forge Data Management and Model Derivative APIs.  These services began experiencing slowdowns around 8pm PST on Tues 12/6. The service degradation gradually worsened, until, by 1am PST Wed 12/7 we decided that it was necessary to take the service off line in order to take remedial action.

The affected service was an internal system that controls access permissions to data in our storage layer. Without this service running, our Data Management and Model Derivative APIs were unable to store new data or access existing data. While addressing this issue, our priority was to take extreme care to ensure that no customer data was lost - even though this resulted in a longer resolution time.

By approximately 1am PST Thurs 12/8 we had fixed the problem, restored access to customer data and started processing a backlog of transactions. We continue to monitor this service and are confident the code changes we made will prevent this problem from happening again. As a result of this incident, we have also identified areas where we can improve our internal processed and how we can better communicate with you when we are having problems.  One area we will be prioritizing is to enhance our API Health Dashboard to make it easier for you understand the health status of our APIs, and to receive more detailed information about any issues we are having.  

The Forge Team

 

(Update 12/8/16 7am Pacific Time)

The Forge Data Management and Model Derivative APIs are now back online, including access to data via the API for Fusion Team, A360 and BIM 360 Docs. The Forge team apologizes for this outage and any problems it has caused for you and your customers.

We are now investigating all aspects of this outage to prevent it from happening in the future.

 

(Posted 12/7/16 12pm Pacific Time).

The Forge Data Management and Model Derivative APIs are currently unavailable.  The Forge team apologizes for the current outage and any problems it has caused for you and your customers. Our team is working diligently on the problem and will fix it as soon as possible. 

The outage was caused by a problem in our service that controls secure access to data that is stored in our storage services. This impacts access to data via Forge Data Management API and the Model Derivative API.  This outage effects files created to view, translated to another format or for access to model meta data.  Access to data via the API for Fusion Team, A360 and BIM 360 Docs is also effected.  We will notify you as soon as the problem is fixed, and will follow up with information on what we are doing to prevent it from happening in the future.  

The Forge Team