Cloud and Mobile

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 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).

3-legged OAuth on desktop apps (C# & WinForm)

By Augusto Goncalves (@augustomaia)

If you don't know OAuth or the differences between 2-legged or 3-legged authentication on Forge, please review this webinar.

It's quite straightforward to implement OAuth on a web app: as everything is on the browser, including the redirect callback, it's almost natural. What about a desktop application? In this case is not quite direct to handle callbacks or implement micro servers to handle it.

This code is almost an hack, but works for our purposes. Note this implementation is not safe, meaning your developer ID and secret can be easily hacked/read by almost any end-user. The safest way still to perform authorization on server-side. 

Let's use the System.Windows.Forms.WebBrowser, which works fine, but it doesn't handle error in the way we want for this sample. At the bottom of this post you'll find the full WebBrowser2 implementation copied from here.

Now on your app, create a form (assuming a WinForm application). Add a WebBrowser2 control, say wb. Prepare the Authorize URL (using your client ID, redirect URL and Scope) and navigate to this page. The end-user will be redirected to the Autodesk login page. When done, it will redirect to your callback URL, which is not possible or doesn't exist (at this sample, fake.com). This will throw a 404 error that we can capture. Voilà! Finally capture the code parameter of the query string and call the gettoken endpoint (e.g. using RestSharp) 

[PermissionSetAttribute(SecurityAction.Demand, Name = "FullTrust")]
public partial class oAuthForm : Form
{
  private const string FORGE_CLIENT_ID = "XxXxXxXxXx";
  private const string FORGE_CLIENT_SECRET = "XxXxXxXx";
  private const string FORGE_CALLBACK_URL = "http://fake.com/api/forge/callback/oauth";
  private const string FORGE_BASE_URL = "https://developer.api.autodesk.com";
  private const string FORGE_SCOPE = "data:read data:write data:create data:search bucket:create bucket:read bucket:update bucket:delete"; // assuming a full scope

  private WebBrowser2 wb = new WebBrowser2();

  public oAuthForm()
  {
    InitializeComponent();

    wb.Dock = DockStyle.Fill;
    wb.NavigateError += new WebBrowserNavigateErrorEventHandler(wb_NavigateError);
    Controls.Add(wb);

    // this is a basic code sample, quick & dirty way to get the Authentication string
    string authorizeURL = BASE_URL + string.Format(
        "/authentication/v1/authorize?response_type=code&client_id={0}&redirect_uri={1}&scope={2}", 
        FORGE_CLIENT_ID, FORGE_CALLBACK_URL, System.Net.WebUtility.UrlEncode(FORGE_SCOPE));
        
    // now let's open the Authorize page.
    wb.Navigate(authorizeUrl);
  }

  private void wb_NavigateError(
      object sender, WebBrowserNavigateErrorEventArgs e)
  {
    // This will track errors: we want to track the 404 when the login
    // page redirects to our callback URL, let's check if is the error
    // we're tracking.
    Uri callbackURL = new Uri(e.Url);
    if (e.Url.IndexOf(FORGE_CALLBACK_URL) == -1)
    {
      MessageBox.Show("Sorry, the authorization failed", "Error", MessageBoxButtons.OK, MessageBoxIcon.Error);
      return;
    }
       
    // extract the code
    var query = HttpUtility.ParseQueryString(callbackURL.Query);
    string code = query["code"];
    
    // now we have the code, let's make a Http call to 
    // /authentication/v1/gettoken 
    // and get the access_token...
    
    // you can use RestSharp for it, but I'll stop the sample here

    // you may want to close this form..
    this.Close();
  }
} 

Custom implementation of WebBrowser, let's call it WebBrowser2 (original post). Due our HTML/JavaScript implementation on the login page, some features are not natively supported by the WebBrowser (which, by default, have some features disables). To improve it, we need a set of registry keys (user level), which are well described at this stackoverflow answer. 

 

Boost your Web Application with C++! Emscripten, ASM.js, Web Assembly ...

By Philippe Leefsma (@F3lipek)

    I meant to take a look at the topic since a while but finally got time during a rainy weekend: asm.js, "an extraordinarily optimizable, low-level subset of JavaScript" and Web Assembly, "an experimental efficient low-level programming language for in-browser client-side scripting" ! 

    You can easily find lots of articles on that topic over the web, so I'm not planning to explain in details the theory... Rather than summing up again the same information from different sources, this blogpost is a deep dive from my own experience into digging how to compile a non-trivial piece of C++ into asm.js and Web Assembly (wasm). Then running them inside the browser from a custom test in order to benchmark the performances. Results are satisfying, to say the least.

    If you are ready for a sneak peek at the future of web development, keep reading!

I - Setting up the Emscripten tool chain

    The first step in the process is to setup the required tools that enable you to compile a piece of C++ into something that can be loaded into a browser. That project is called Emscripten, so the first thing you would do when opening the link, is to go to the Getting Started section and follow the instructions right? 

    Yes, but there is a trick... the standard install instructions are suitable to compile C++ into asm.js, but if you plan to compile into Web Assembly - I know you do - there is just a little difference: instead of installing the latest SDK, you need to install the incoming branch, which has BINARYEN compile option available out of the box.

    1/ Go to Emscripten SDK download page and make sure you have the prerequisite tools on your machine. The SDK runs on OSX, Windows and Linux

    2/ You will then build the SDK from source as per those instructions. You just need to instal the sdk-incoming-64bit as described in the tutorial, you do NOT need to install the master branch (no wasm support there yet - at the time of this writing)

    3/ Perform a check to see if emcc (the Emscripten compiler) is installed properly, I have it in my system path, so I can simply type emcc -v in a terminal:

    If you see something like this, then you are ready for the next thrill!

II - Back to the 90's, let's write some C++ 

    It's been a while since I hadn't written more than few lines of C++. Emscripten documentation is pretty good and the SDK comes which a bunch of samples, ranging from very basic to pretty advanced, so you probably want to go at least through the basic hello world tutorial.

    It's quite detailed, so I assume this goes smoothly on your side as well and you are now able to compile a single C++ file into asm.js, then load it into the demo web page that is produced when using the -o output.html:

./emcc tests/hello_world.c -o hello.html

 

    Almost the same emotion than the first C++ program I wrote on my PC!

    My goal here however is to write a slightly more advanced piece of code in order to compare its execution speed with plain JavaScript or we could say "human written JavaScript". A good candidate for that task that came naturally to my mind is the particle system I wrote few months ago, I already have the JavaScript ES6 version, so I just needed to write an equivalent C++ version.   

    Below is how the console test of my C++ particle system looks like. Note: it is just used to test and debug the particle system while writing it, this is not the actual test this blog is about.

    I wrote and compiled the project initially in Visual Studio 2010 (for compatibility reason with the tools), then used a tool called make-it-so that will parse the Visual Studio .sln solution and generate a make file out of it.

III - Exposing C++ classes to JavaScript

     Alright, at this step we have a C++ particle system that compiles and can run in console mode as a pure C++ application. We can compile it using the make file produced by MakeItSo - or created by hand if you fancy this kind of thing. However what we want is to be able to instantiate the ParticleSystem from our JavaScript code, so we can really leverage the speed gain from a web application mostly written in js. 

     In order to achieve that, Emscripten offers two different approaches:

1/ Embind: basically you declare the bindings between the C++ class methods and properties and the generated JavaScript objects using the EMSCRIPTEN_BINDINGS macro

2/ WebIDL Binder: you create an extra .idl file that describes the bindings, generate a .js and .cpp files by running a python script from the SDK against the idl and finally compile the project including that cpp file.

    The second option may look like like a lot of extra steps, however this is the one I chose. I felt that the main advantage is that you don't have to modify your initial C++ code by adding macro to each file and link the project to the correct emscripten C libraries, so you can keep your C++ code base intact and keep developing and testing as is. Note that this is also the approach chosen by two major Emscripten C++ ports: box2d.js and ammo.js (Bullet Physics)

     Here are the bindings definition for my project so far:

    Once the bindings are correct, you will generate the glue files by invoking a python script as follow - path will depends on your emsdk location:

python ~/emsdk/emscripten/incoming/tools/webidl_binder.py bindings.idl glue

    This produces glue.cpp and glue.js, you can then create an extra file glue_wrapper.cpp which includes the required headers and glue.cpp, you then add glue_wrapper.cpp to your makefile. This is suggested this way so if you modify your bindings in the future, you can simply re-run the python script without editing any other file in your project. Refer to WebIDL section on the official documentation for more details.

    If everything is done correctly, you should now be able to replace g++ compiler by emcc in the makefile and by running make, it will produce the byte code: ParticleSystem.bc. You can take a look at my custom makefile there. 

IV - Generating asm.js

    We are just one step away from generating asm.js: just run the following command by specifying the glue.js as post-js step, the ParticleSystem.bc from the compilation and also NO_EXIT_RUNTIME=1 option to indicate that even after main has returned, we keep the runtime alive because our JavaScript code will be running the particles. I also comment out all the test code inside the C++ main as it is irrelevant.

emcc -s NO_EXIT_RUNTIME=1 -s release/ParticleSystem.bc --post-js ParticleSystem/glue.js -o dist/asmjs/ParticleSystem.asm.js

    In my project I created the emcc-asmjs.sh script for not having to type the command every time. The output file is valid ES5 JavaScript file ParticleSystem.asm.js that can simply be included in your html using a classic <script> tag. You can take a look at the asm.js test, which is invoking the exported C++ classes, it's pretty close to the C++ code we had originally in main.cpp.

V - Generating Web Assembly

    That's the cherry on the top, by simply adding the BINARYEN=1 option - that's where using the incoming branch of Emscripten matters - you can generate wasm files!

emcc -s NO_EXIT_RUNTIME=1 -s BINARYEN=1 release/ParticleSystem.bc --post-js ParticleSystem/glue.js -o dist/wasm/ParticleSystem.js

In that case it produces several files and loading the script in your html requires a bit more trickery:

 1 <script>
 2   
 3   var Module = Module || {
 4     wasmBinaryFile: '../Emscripten/dist/wasm/ParticleSystem.wasm'
 5   }
 6 
 7   var xhr = new XMLHttpRequest()
 8   xhr.open('GET', '../Emscripten/dist/wasm/ParticleSystem.wasm', true)
 9   xhr.responseType = 'arraybuffer'
10 
11   xhr.onload = function() {
12 
13     Module.wasmBinary = xhr.response
14 
15     var script = document.createElement('script')
16     script.src = "../Emscripten/dist/wasm/ParticleSystem.js"
17     document.body.appendChild(script)
18   }
19 
20   xhr.send(null)
21 </script>

    Testing the wasm can be achieved with the exact same code than for asm.js, I only added a check on Module to see if ParticleSystem object is available as the laoding is asynchronous. It might not be the best approach but reliable enough for now...

VI - Benchmarking the code

    Finally the fun part is to compare how well asm.js and wasm perform against the plain JavaScript code, well my JavaScript code was written in ES6, so it still has to go through a build step to transpile it.

    Asm.js is plain JavaScript so any current browser should be able to load it, wasm is experimental so it has support only in Chrome Canary and Firefox Nightly at this time, with Microsoft Edge coming pretty soon. 

    I created a simple interface using jsoneditor which allows to modify the test configuration. You can tweak the time step, number of particles, number of steps, add some emitters and fields. There is no validation so if you provide invalid or missing parameters, you will probably crash the test. You can also output the particles position to the browser console with dumpParticles set to true, so don't output 10,000 particles over 10,000 steps, you may sit there for a while...

    Loading the wasm on a browser that doesn't support will use a fallback, so the code still runs but ends up being very very slow. You can give it a try but be warned. 

    That's what you can see in your browser console if it can successfully load the wasm file. In Canary it worked straight ot of the install, in Firefox Nightly I had to activate in the config flags javascript.options.wasm: true 

    I created two tests, here are the live versions: ES6 vs ASM.js and ES6 vs WASM and here is a plot of the results I gathered across several browsers, they were using the same default config 1000 particles over 5000 steps:

    Safari comes the very last as far as ES6 is concerned with a huge difference, however the asm.js executes almost the fastest on it with a 42x speed factor increase!

    Firefox Nightly is the one that executes the asm.js code the fastest with an elapsed time of 122 ms. Oddly it doesn't seem to handle wasm very well with a total time of 521 ms, so much higher in comparison

    Canary is the absolute winner of the contest with an execution speed of 121 ms for the wasm version, 12x faster than it runs ES6! However it doesn't handle asm.js as well as Firefox or Safari ...

    That's it for now! I hope you enjoyed, that was a pretty interesting experiment for me so far. The next step will be integrate my particle system asm.js and wasm versions into a Forge Viewer sample and see how much they can increase the FPS of the simulation, so I will definitely blog some more of that in the future.

    The full git project is available at https://github.com/leefsmp/Particle-System with instructions on how to build it. 

 

First try at Cloud9, View & Data API boilerplate

By Philippe Leefsma

I discovered Cloud9 last week while working with external developers during our EMEA Cloud Accelerator in Prague, first feeling: impressed!

EMEA Cloud Accelerator is starting in our fancy Prague office! One busy week of work around our cloud APIs ... pic.twitter.com/20XoxmhqAm

— Philippe Leefsma (@F3lipek) September 14, 2015

This is essentially a slick browser based IDE which allows you to easily deploy your project directly on the cloud, so you don't need to worry where you are going to host it - at least for quick prototyping and testing purpose.
When creating new a project - named as workspace - you can use a predefined template or clone an existing repository from github or bitbucket and this is very straightforward.

In order to test that feature, I created a minimalistic boilerplate for the View & Data API project based on node.js : view.and.data-boilerplate

Using that as template in Cloud9, I can literally deploy a viewer webapp on the cloud in couple of minutes, while at the same time being able to tweak it to my will. Hard to beat to be honest!

Here are the steps to get that up-and-running:

1. Sign up for View & Data API keys on our developer portal

2. Once you've got your keys, upload a test model. You can use one of our tool to do that without setup: http://models.autodesk.io

3. Sign up for a Cloud9 account if you haven't done it already, then create a new workspace using my boilerplate as template: 4. Fire "npm install" from Cloud9 command line:


5. In www/js/viewer.js replace the var urn = '...' with the urn of your model from step 2


6. Create environment variables CONSUMERKEY and CONSUMERSECRET using your API keys from step 1


7. Start the Cloud9 project... you've got a running cloud viewer!

RESTful website architecture with Node and Angular

By Daniel Du

As a web programmer starting from the traditional ASP/ASP.net, sometimes my mind was constricted to the old days. My understanding of web application was how asp.net works, the HTML is generated at server side, and send it to browser to render. One guy asked me how to display some data which retrieved from server during a hackathon, while I am just in the middle of something, my distinctive response is to ask him to do something like <%= something%>, like ASP/ASP.NET does. But nowadays, it has been changed a lot, we have very different architecture – RESTful, which separates the server side and client side completely, and it also makes it easy for the server to serve different clients, including browsers and mobile devices.

Here is an architecture graph I “steal” from strongloop. As you can see, with RESTful architecture, the web server exposes some REST APIs, the client communicates with the server with REST call. This make it very flexible, the client can be a browser as a common website, it also can be mobile device like iPhone/iPad or Android phone or pad. For the browser, you can user different libraries or frameworks to build your UI, you can use JQuery, Angular.Js or anything else you like.

Let’s make a simplest sample to demo the idea, a web server with Node.Js + Express, and a browser client with Angular.Js. The idea is to make a todo list. Firstly I will create a simplest web server with Node.Js and Express. The express CLI make it really easy. If you do not have express installed, install it first with help of google. And then create a simplest express web application with express generator:

mkdir simpleWebApp

cd simpleWebApp

npm install

This will create a simplest web application with node.js and express, if you run “npm start” and go to “http://localhost:3000” you will see the first welcome page of express.

Now let’s do some simple work to add a REST API:

GET /todos   - Get all todo items

Before that, we will add some test data in JSON, in practice, you will get these todo items from a database like MongoDb. For simplicity, we make it a JSON file named as “todoItems.json”

[ 
      {    
          "task": "buy milk", 
        "complete":false 
    }, 
    { 
        "task": "toast bread", 
        "complete":false 
    }, 
    { 
        "task": "pick up newspaper", 
        "complete":false 
    }, 
    { 
        "task": "water flowers", 
        "complete":false 
    }

]

Then go to /routes/index.js, add a new route, response all todo items in json:

var express = require('express');
var router = express.Router();

/* GET home page. */
router.get('/', function(req, res) {
  res.render('index', { title: 'Express' });
});


var sampleToDoItems = require('../todoTasks.json');

/* GET Todo listing. */
//GET /Todos/
router.get('/todos', function(req, res) {

  res.type('application/json');
  res.status(200);

  res.json(sampleToDoItems);
});

module.exports = router;

Now, the REST API is ready, if I start the web application, and go to postman with GET http://localhost:3000/todos, or go to the url in browser directly, I will get all todo items:

 

The server side is done, next we will do the client side. We will use Angular.JS. Actually the client does not have to be in the same project of web server, but for simplicity, I put it together. The express has already setup the structure, the /public folder contains the static contents. I create a webpage named as “index.html” in it, and then I edit “route/index.js” file to change the route so that when I go to “http://localhost:3000/” it goes to my index.html page:

/* GET home page. */
router.get('/', function(req, res) {
  //res.render('index', { title: 'Express' });
  res.redirect('/index.html');
});

 

Let’s do the angular part, in “index.html” to include the angular js library, and create our angular module and controller. It is very simple one, so I put them into a single JS file. The idea is just to send a GET request to the web server and get all todo items, the import part is to inject the $http into the controller:

var app = angular.module('myTodoApp',[]);

app.controller('myTodoCtrl', function($scope, $http){

    $http.get('/todos')
        .success(function(response){
     
            $scope.todoItems = response;
        });
 
});

And then go to the “index.html” page, I put the important port in bold so that it is easy to follow. Firstly we need an “ng-app”, otherwise angular.Js will not run. And then put the “ng-controller” to the table, and build the table with ng-repeat="todo in todoItems", please note that the “todoItems” is populated in controller by http get request, they are completed in client side already:

     $scope.todoItems = response;

The the databind can be done by “ng-bind” or “{{  something  }}”.  Here is the complete code:

<!DOCTYPE html>
<html lang="en">
    <head>
        <meta charset="utf-8">
        <meta http-equiv="X-UA-Compatible" content="IE=edge">
        <meta name="viewport" content="width=device-width, initial-scale=1">
        <title>Title Page</title>

        <!-- Bootstrap CSS -->
        <link href="//netdna.bootstrapcdn.com/bootstrap/3.2.0/css/bootstrap.min.css" rel="stylesheet">

        <!-- HTML5 Shim and Respond.js IE8 support of HTML5 elements and media queries -->
        <!-- WARNING: Respond.js doesn't work if you view the page via file:// -->
        <!--[if lt IE 9]>
            <script src="https://oss.maxcdn.com/libs/html5shiv/3.7.0/html5shiv.js"></script>
            <script src="https://oss.maxcdn.com/libs/respond.js/1.4.2/respond.min.js"></script>
        <![endif]-->
    </head>
    <body>
        <h1 class="text-center">Hello World</h1>

        <div class="container" ng-app="myTodoApp">
            <table class="table table-striped table-hover" ng-controller="myTodoCtrl">
                <thead>
                    <tr>
                        <th></th>
                    </tr>
                </thead>
                <tbody>
                    <tr ng-repeat="todo in todoItems">
                        <td>{{todo.task}}</td>
                        <td><div class="checkbox">
                            <label>
                                <input type="checkbox" value="" ng-model="todo.complete">
                            </label>
                        </div></td>
                    </tr>
                </tbody>
            </table>

        </div>

        <!-- jQuery -->
        <script src="//code.jquery.com/jquery.js"></script>
        <!-- Bootstrap JavaScript -->
        <script src="//netdna.bootstrapcdn.com/bootstrap/3.2.0/js/bootstrap.min.js"></script>

        <script src="//www.runoob.com/try/angularjs/1.2.5/angular.min.js"></script>

        <script src="/javascripts/myTodoApp.js"></script>
    </body>
</html>

And this is how it looks like when running the app:

 

OK, that’s the idea, very simple, of cause in practical, if will be more complex, and you can user various frameworks, like mean.io, cleverstack, sail.js.

New Code Sample: View and Data API with Polymer Toolbar

By Shiya Luo

As an experiment, Nop Jiarathanakul, graphics engineer at Autodesk, has built customizable toolbars for the View and Data API. Polymer is a library from Google built on top of web components, which encapsulate code and let you call them with custom HTML elements. 

Previously, developers had to struggle with either calling the Viewer3D function in JavaScript and have to write their own UI components and functions. The other choice was to call the “private” function GuiViewer3D, which is essentially the Autodesk 360 toolbar. The built in toolbar is not customizable, and can sometimes be broken by CSS on the page. Although  the GuiViewer3D function is convenient, developers will have to take whatever the Autodesk 360 team decides to do with the toolbar.

This is an effort to offer up a library for developers who wants to customize their toolbars without having to do all the heavy lifting. Instead of putting a <div> element on the page and let JavaScript populate the area, you can simply include the viewer using this single line of code:

<lmv-viewer url=“https://lmv.rocks/data/engineraw/0.svf”></lmv-viewer>

The goal of this toolbar is to let developers be able to implement the View and Data API and easily customize the toolbar without writing a single line of javascript.

A demo of this toolbar can be found at http://lmv.rocks/

The source code is on GitHub.

Creating "Tools" for the View & Data API

By Philippe Leefsma

Here is just a quickie before the weekend showing you how to create a "tool" for the viewer. A tool is basically a custom "class" (in the JavaScript way) implementing the ToolInterface that will give your code easy access to callbacks such as mouse events, keyboard events, touch events and so on...

It's pretty straightforward to put in place and use it. The below implementation does not much except dumping to the browser console the various tool callbacks and their parameters. I commented out the "update" and "handleMouseMove" so the console doesn't get too much stuff logged in:

  1 ///////////////////////////////////////////////////////////////////
  2 // Simple Custom Tool viewer extension
  3 // by Philippe Leefsma, March 2015
  4 //
  5 ///////////////////////////////////////////////////////////////////
  6 AutodeskNamespace("Autodesk.ADN.Viewing.Extension");
  7 
  8 Autodesk.ADN.Viewing.Extension.CustomTool = 
  9     
 10     function (viewer, options) {
 11 
 12     Autodesk.Viewing.Extension.call(this, viewer, options);
 13 
 14     var _self = this;
 15 
 16     _self.tool = null;
 17 
 18     function AdnTool(viewer, toolName) {
 19 
 20         this.getNames = function() {
 21 
 22             return [toolName];
 23         };
 24 
 25         this.getName = function() {
 26 
 27             return toolName;
 28         };
 29 
 30         this.activate = function(name) {
 31 
 32             console.log('-------------------');
 33             console.log('Tool:activate(name)');
 34             console.log(name);
 35         };
 36 
 37         this.deactivate = function(name) {
 38 
 39             console.log('-------------------');
 40             console.log('Tool:deactivate(name)');
 41             console.log(name);
 42         };
 43 
 44         this.update = function(t) {
 45 
 46             //console.log('-------------------');
 47             //console.log('Tool:update(t)');
 48             //console.log(t);
 49 
 50             return false;
 51         };
 52 
 53         this.handleSingleClick = function(event, button) {
 54 
 55             console.log('-------------------');
 56             console.log('Tool:handleSingleClick(event, button)');
 57             console.log(event);
 58             console.log(button);
 59 
 60             return false;
 61         };
 62 
 63         this.handleDoubleClick = function(event, button) {
 64 
 65             console.log('-------------------');
 66             console.log('Tool:handleDoubleClick(event, button)');
 67             console.log(event);
 68             console.log(button);
 69 
 70             return false;
 71         };
 72 
 73 
 74         this.handleSingleTap = function(event) {
 75 
 76             console.log('-------------------');
 77             console.log('Tool:handleSingleTap(event)');
 78             console.log(event);
 79 
 80             return false;
 81         };
 82 
 83 
 84         this.handleDoubleTap = function(event) {
 85 
 86             console.log('-------------------');
 87             console.log('Tool:handleDoubleTap(event)');
 88             console.log(event);
 89 
 90             return false;
 91         };
 92 
 93 
 94         this.handleKeyDown = function(event, keyCode) {
 95 
 96             console.log('-------------------');
 97             console.log('Tool:handleKeyDown(event, keyCode)');
 98             console.log(event);
 99             console.log(keyCode);
100 
101             return false;
102         };
103 
104         this.handleKeyUp = function(event, keyCode) {
105 
106             console.log('-------------------');
107             console.log('Tool:handleKeyUp(event, keyCode)');
108             console.log(event);
109             console.log(keyCode);
110 
111             return false;
112         };
113 
114 
115         this.handleWheelInput = function(delta) {
116 
117             console.log('-------------------');
118             console.log('Tool:handleWheelInput(delta)');
119             console.log(delta);
120 
121             return false;
122         };
123 
124         this.handleButtonDown = function(event, button) {
125 
126             console.log('-------------------');
127             console.log('Tool:handleButtonDown(event, button)');
128             console.log(event);
129             console.log(button);
130 
131             return false;
132         };
133 
134         this.handleButtonUp = function(event, button) {
135 
136             console.log('-------------------');
137             console.log('Tool:handleButtonUp(event, button)');
138             console.log(event);
139             console.log(button);
140 
141             return false;
142         };
143 
144         this.handleMouseMove = function(event) {
145 
146             //console.log('-------------------');
147             //console.log('Tool:handleMouseMove(event)');
148             //console.log(event);
149 
150             return false;
151         };
152 
153         this.handleGesture = function(event) {
154 
155             console.log('-------------------');
156             console.log('Tool:handleGesture(event)');
157             console.log(event);
158 
159             return false;
160         };
161 
162         this.handleBlur = function(event) {
163 
164             console.log('-------------------');
165             console.log('Tool:handleBlur(event)');
166             console.log(event);
167 
168             return false;
169         };
170 
171         this.handleResize = function() {
172 
173             console.log('-------------------');
174             console.log('Tool:handleResize()');
175         };
176     }
177 
178     var toolName = "Autodesk.ADN.Viewing.Tool.CustomTool";
179 
180     _self.load = function () {
181 
182         _self.tool = new AdnTool(viewer, toolName);
183 
184         viewer.toolController.registerTool(_self.tool);
185 
186         viewer.toolController.activateTool(toolName);
187 
188         console.log('Autodesk.ADN.Viewing.Extension.CustomTool loaded');
189         return true;
190     };
191 
192     _self.unload = function () {
193 
194         viewer.toolController.deactivateTool(toolName);
195 
196         console.log('Autodesk.ADN.Viewing.Extension.CustomTool unloaded');
197         return true;
198     };
199 };
200 
201 Autodesk.ADN.Viewing.Extension.CustomTool.prototype =
202     Object.create(Autodesk.Viewing.Extension.prototype);
203 
204 Autodesk.ADN.Viewing.Extension.CustomTool.prototype.constructor =
205     Autodesk.ADN.Viewing.Extension.CustomTool;
206 
207 Autodesk.Viewing.theExtensionManager.registerExtension(
208     'Autodesk.ADN.Viewing.Extension.CustomTool',
209     Autodesk.ADN.Viewing.Extension.CustomTool);
210 

You can find the complete code as part of our viewer extension samples:

Autodesk.ADN.Viewing.Extension.CustomTool.js

View & Data API - Getting started recording

By Philippe Leefsma

Here is a link to my recording on View & Data API introduction. This will take you through the steps in order to quickly get started with that web service.

It illustrates how to use the LMV Quick Start Guide to upload and translate your models without setting up the workflow yourself.

Then how to use my Node,js Basic sample to setup a client/server website to view your models.

 

Integrating View & Data API with Appery.io - Part I

By Philippe Leefsma

I've been playing with a cool technology this week named Appery.io, the best is to define it with their own words: 

Appery.io, developed by Exadel, is the first mobile platform that offers a cloud-based rapid enterprise mobile app development environment with integrated backend services and a rich catalog of API plug-ins that dramatically simplify integration with cloud services and enterprise systems. It combines the simplicity of visual development with the power of JavaScript to create cross-platform enterprise apps rapidly. Because the platform is 100% cloud-based, you can focus on creating great applications, while we worry about maintaining the platform.

Alright, my goal is to integrate View & Data API inside that stuff to produce a little mobile App, here is the idea: I will use my existing backend REST services from the Gallery to create an App that displays the list of models and lets the user select one to load it in the viewer, sounds like a good proof of concepts, let's get started!

First of all, here are the available REST APIs exposed by my backend that I'm going to use and their purpose:

1. http://viewer.autodesk.io/node/gallery/api/models:

    Returns the list of all models available in the Gallery

2. http://viewer.autodesk.io/node/gallery/api/thumbnail/{modelId}:

    Returns thumbnail data for the specified modelId

3. http://viewer.autodesk.io/node/gallery/embed/{modelId}:

    Allows to embed a specific model in an iframe

 

Let's create a new App, I name it "ADN Gallery":

Appery.io propose a pretty slick browser-based visual IDE that allows you to create pages and dialogs for your App which you populate with built-in or custom controls, so in my startScreen page, I will first place a List:

I want to populate that list with models from the Gallery, so I then have to create a new REST Service, there are some very convenient built-in tools to work with REST in Appery. 

I define the properties of my REST service below, notice that I'm using the "Appery.io Proxy" option, this will allow me to bypass CORS security restrictions and test my App directly in the browser!

You can test the service using the "Test" tab and once the reply has been received, you can can directly "Import as Response" which automatically defines the response format of the service:

The next step would be to define two events handlers, which is also very easy to do through the interface: upon loading of the startScreen page, we will invoke the models service and upon success of that service, we will define a mapping so the data for each model in the response is automatically mapped with a new listview item:

The mappings are defined graphically with a specific editor as well: I'm mapping each model in the response to a modelItem in the list and model.name is mapped to the list item name:

Now I want to go a step further and display the thumbnail of the models directly in the listview items, so time to write some JavaScript! Clicking the little "JS" logo at the end of the mapping arrow takes you to an editor where you can input some code that gets executed before the mapping happens, there you can transform the output of the mapping or perform some additional actions through JavaScript.

Here is the code of my mapping, this does two things: sets up an event listener, so when a list item gets clicked, the data about this item is stored in the local storage - this info will be accessed by the next page to know which model to load - and it invokes my thumbnail service to set the image data in the list item:

At that point, you can hit the Test button and see your App running in the browser with a phone frame around it or not, as well as testing different screen sizes and orientation:

Alright, I'm defining another event so when a list item gets clicked, another page will be displayed, this will be the viewerPage. I create a mapping to bind the data in the local storage to the title of that page, so my model name appears at the top:

And then I also create a mapping between the selectedModel._id and the header text, so I can place some custom JavaScript in the mapping transform where I can easily grab the id of the model to load. This is where JavaScript and DOM manipulation is so cool: I can dynamically create an <iframe> element with the correct url based on my model id and append that iframe to the <div> of my viewerPage.

Here is the code for that with some little tweaks to adjust the height and the style:

And that's pretty much it! Just with couple lines of code I get a fully functional mobile App, below is a recording of the final version tested in the browser:

 

You can then export the result as compiled package or as project that you can load in an IDE, the generated project is based on Cordova:

You could as well directly see the generated code on Appery.io:

Finally you can create a backup of your project and pass it to somebody else for example, so he can create his own Appery.io App based on yours, impressive flexibility I must say...

Attached is the backup for my project and the Android/iOS packages if you want to have fun playing with the Apps:

Download ADN Gallery_backup

Download ADN+Gallery - Eclipse

Download ADN+Gallery - XCode