Displaying 2D Graphics via a Node Server

Now that our node.js web server is hosted by Heroku, running live on the web, and even generating nonsensical source code in six different programming languages for April 1st, let's move on to something more interesting and graphical.

First, briefly, a couple of other short news items and topics of general and personal interest:

WebGL 3D Model Viewing on Mobile Devices

Question: What is the current status of WebGL viewers on mobile devices?

What phone will run VR demos for Google cardboard or Dodocase?

I have access to an iPhone 5 (my wife's), but could not get viewer to run there.

I also notice that my Android Samsung tablet does not run it currently.

The general WebGL site says it is not compatible with the device's graphics.

I am thinking of going out to buy a used Android phone and just use it's wi-fi for this; however, I want to be sure it will work.

What about iPod?

Will that work in the Dodocase?

I have a Windows phone (yeah, go ahead and laugh).

Interestingly enough, it appears to get me the closest to working.

The iPhone 5 won't display anything but the frame, the Android tablet fails with error, but the Windows Phone will display the viewer controls, and the flashing dots.

It just never gets to the model view.

In all the tests I made I used the Chrome or native browser, cleared its cache, etc. but with little mobile success.

The iPad Mini seems to run it with Chrome, but it's not mini enough for the Dodocase.

Answer 1: The reason iPhone 5 is not supported is probably because WebGL wasn't on Apple's agenda for that release. iOS 8 is the one that claims full support, and that's when iPhone 6/6 plus came out. I personally have the viewer working on iPhone 5S and 6. Whether the viewer works well or not also depends on the model – if you try to load a huge model, it's just going to eat up memory, and that may crash the phone.

Same with Android, you'll get a better chance with a phone that came with 5.x or Chromium 40, since the hardware is most likely to be tailored to work with WebGL support as well.

I have little experience with Windows Phone development, so I can't comment much on that.

Keep in mind that iOS 8 came out only 6 months ago; as people upgrade their phone mobile support will happen in time.

Lots of teams are expressing interest in using WebGL viewers now that the mobile situation seems promising.

Answer 2: The WebGL viewers on mobile browsers has been supported since end of last year after the team added touch support that solves the major user interaction issues. It should run fine on mobile devices whose web browser has capabilities to support WebGL and web worker. Typically, a mobile browser that satisfy both constraints would also satisfy the other WebGL web viewer requirements, e.g., typed array, so explicitly checking WebGL and web worker support is enough. At this moment, the device that provides the best experience on a mobile browser is Nexus 9 and IPAD AIR 2. As already pointed out, mobile devices have memory constraints and for now our viewer has no out of core capability or view dependent loading of geometry, so for large models (typical for BIM or Plant), out of memory and crash of mobile browser is not uncommon. Handling large models on mobile device is part of our plan, so we'll get better mobile support as we go on.

Answer 3: I have an iPad3. I updated it to iOS 8 and the viewer runs fine on it in Safari.

The iPhone 5 device is OK if you decide to upgrade to iOS 8.

A360 Drag and Drop Viewer

The new A360 drag and drop viewer enables you to and share designs without any sign-up or plugin installation whatsoever.

It also includes new capabilities to handle large and complex CAD files linking in external references.

Over 50 design file types are supported, including AutoCAD:

A360 viewer design file types

View and Data API Design File Formats

This resembles the list of design file formats supported by the View and Data API.

You can generate an up-to-date list of those yourself at any time using the Supported API.

A suitable CURL command is shown in the step 4 – upload a file:

$ curl  -k --header
  "Authorization: Bearer QOeHrJWR3CQS49oD33UCTrFbm7HZ"
"channelMapping":{"ipt":"viewing-inventor-lmv", ... }}

Massaged with a snippet of Python code, it generates the following sorted list:

  ['3dm', '3ds', 'asm', 'bmp', 'cam360', 'catpart',
  'catproduct', 'cgr', 'csv', 'dae', 'dlv3', 'doc',
  'docx', 'dwf', 'dwfx', 'dwg', 'dwt', 'exp', 'f3d',
  'fbx', 'g', 'gbxml', 'iam', 'ifc', 'ige', 'iges',
  'igs', 'ipt', 'jpeg', 'jpg', 'jt', 'model', 'neu',
  'nwc', 'nwd', 'obj', 'pdf', 'png', 'pps', 'ppt',
  'pptx', 'prt', 'rcp', 'rtf', 'rvt', 'sab', 'sat',
  'session', 'sim', 'sim360', 'skp', 'sldasm',
  'sldprt', 'smb', 'smt', 'ste', 'step', 'stl',
  'stla', 'stlb', 'stp', 'tif', 'tiff', 'txt',
  'wire', 'x_b', 'x_t', 'xas', 'xls', 'xlsx',
  'xpr', 'zip']

Useful JavaScript Resources

Here are some JavaScript resources that my colleague Philippe finds particularly useful to keep up to date with the trends of the web:

Augmented Reality

Check out the cool augmented reality implementation by wakingapp.com that my friend Dan pointed out to me, fresh back from the Campus TLV conference in Israel, e.g., in this one-minute video:

Is Angular Bad?

My colleague Philippe is quite a fan of Angular, meseems, so I thought I should use it too.

On the other hand, I noticed this competent-sounding article by Robert Greyling asking Is Angular Bad?, followed by one on why junior developers are learning bad habits from Angular and concluding:

I won't be using Angular for my next project... and neither should you... as you can see, it’s pretty unlikely I’ll be using Angular in any of my future projects unless v2.0 absolutely blows my socks off. I’ll more likely end up using Ampersand or maybe I’ll take the brand spanking new Aurelia for a spin!

Philippe, what do you think?

Displaying 2D Graphics via a Node Server

As stated, I would like to move into graphical topics as quickly as possible.

Here is a simple starting point, sending a string of polygon coordinate values to a Node server and asking it to render them as a 2D polygon using SVG, Scalable Vector Graphics.

For instance, here is a red triangle with blue edges, minimally adapted from the World Wide Web Consortium or w3.org SVG documentation path data example:

Here is the code generating this image:

  <svg width="3cm" height="3cm" viewBox="0 0 400 400"
       xmlns="http://www.w3.org/2000/svg" version="1.1">

  <rect x="1" y="1" width="398" height="398"
        fill="none" stroke="blue" stroke-width="3" />

  <path d="M 100 100 L 300 100 L 200 300 z"
        fill="red" stroke="blue" stroke-width="3" />


One interesting snippet in that code is the graphics path data definition specified by the d attribute of the path tag.

The path data attribute supports three 'commands': M, L and Z, to moveto, lineto and close the path.

Let's implement a node server taking a path definition like that from the URL query string and generating a web page from that on the fly.

For instance, here is a little form enabling you to define a path of your own:

Input an SVG path data definition inside a 100 x 100 square, e.g.:

Here is the entire Heroku node server implementation:

// index.js
// 2015-04-08, Jeremy Tammik, Autodesk Inc.
// Generated by Heroku node-js-getting-started.
// Added svg_01 implementation.

var svg_template = '\
<svg width="3cm" height="3cm" viewBox="0 0 100 100" xmlns="http://www.w3.org/2000/svg" version="1.1">\
<rect x="1" y="1" width="98" height="98" fill="none" stroke="blue" stroke-width="3" />\
<path d="{path_data}" fill="red" stroke="blue" stroke-width="3" />\

var express = require('express');
var url = require('url');

var app = express();

app.set('port', (process.env.PORT || 5000));

app.get('/', function(request, response) {
  var paramdict = url.parse(request.url,true).query;
  if( !paramdict.hasOwnProperty('d') )
    response.writeHead(400, {'Content-Type': 'text/plain'});
    response.end('No SVG path description given');
    var d = paramdict['d'];
    var svg = svg_template.replace('{path_data}', d);
    response.writeHead(200, {'Content-Type': 'text/html'});

app.listen(app.get('port'), function() {
  console.log("Node app is running at localhost:" + app.get('port'));

I could just as easily implement this locally in pure JavaScript, of course.

Hosting it in a separate server makes no sense whatsoever as long as it is just for my personal local use.

The server implementation is only of interest once we consider more widespread use, e.g., globally accessible sharing of data retrieved from multiple projects for multiple interested parties.

That is where we are headed as soon as we can   :-)