Iris 0.5.3 Released

Hello All,
A new version of Iris has been released. Along with this release, documentation has been updated, including the API documentation. Here is the Changelog. Use this thread to comment on any issues with this latest release.

A few highlights:

  • Clipping Plane objects in the Rhino model are exported. You should give them a name through the Object Properties panel. Named CPlanes are also exported (though I’m not sure they should be) and act like Clipping Planes in the WebApp. There might be some orientation issues which I’m investigating.
  • Internet Explorer is supported again. There was an issue in how this browser handles the events that get fired in the Iris WebApp. This is fixed.
  • Added ways to configure the background color of the Iris Scene through the Rhino Application Settings (_Options -> Appearance -> Colors -> Background) as well as the Iris API via the iris.ChangeBackgroundColor() method.
1 Like

Hi Luis,

Thanks for this update. I’m really excited about possibilities to customize the UI.
Looking through the current API docs it seems most is still centered around the scene as whole and differentiation only between layers, cplanes and appearance.

What I’d be interested in would be to have control over individual objects’ visibility and appearance. Is that something on the list ( if there is any?)

To outline my type of imagined functionality:
I’d like a web UI/API where I can search for object names and highlight or isolate them. Or show also objects nearby ( based on external database). So for this to work easily I’d need API functionality to show hide specific objects rather than layers as a whole.

Do note this is very preliminary so no need for me to have these features in the near future.


@Willem you have access to the scene, which in turn has a ‘children’ array with all of the objects in it. You can inspect this in a browser’s console. I could also consider adding some helper functions to make accessing objects, querying the scene, etc easier.

Thanks for your reply. This is complete new territory for me so I’ll have to first get some basic understanding of the matter. But it’s good to know this type of functionality is not all that hard once you know your way.


I also need to know what people will find, and what needs to be documented. The iris.Scene is actually a Three.js Scene which is a Three.js Object3d with a few more things. So essentially there is one Object with a bunch of other Objects in it which are the meshes, curves, points, lights, etc. The reason it isn’t documented is that is just Three.js at that point. What I think I might consider is exposing some of the scene in a similar manner as the RhinoCommon RhinoDoc class. So maybe instead of iris.Scene, we could have iris.Document. This would in turn have something like iris.Document.Objects, iris.Document.Materials, iris.Document.Layers, iris.Document.Views, etc.

Going further, we could have something like iris.Document.FindByName(), iris.Document.FindByAttribute(), etc. All of this functionality is built in, just hadn’t thought about how to expose it until now.

1 Like

Hi Luis,

FWIW, I’m still running into this one with this latest version on the WIP.

@wim does this happen with both export modes ‘local’ and ‘remote’? This is WIP running on Windows 7 x64 correct?

Both export modes and on Win7 64-bit, yes.

Ok. Looking into it. Will set up a Windows 7 system to see if I can see anything specific.

@wim, there are seven opportunities where I tell Rhino that a failure has occurred. Based on your tests (exporting a simple box), both local and remote, I would assume it is either #1, #2, #4, or #5. In all cases, I write something to the Rhino command line. Do you see any additional message on the Rhino command line? Here are the cases:

  1. If a model has no exportable objects. This can only happen if you run _SaveAs with an empty Rhino model. You would see "Iris: No objects processed" in the Rhino command line.
  2. If there is an issue creating the ‘data’ directory. There could be many reasons this could fail depending on how a user has Windows configured, user permissions, where the user decided to save, etc. You should see "There has been an error in writing the Iris data directory." in the Rhino command line.
  3. If there is an issue creating the ‘img’ directory (where textures are saved). Same reasons as #2 You should see "There has been an error in writing the Iris img directory." in the Rhino command line.
  4. If for some reason the text for a directory path is corrupt. In such a case you might get: "Path to JSON data is corrupt." in the Rhino command line.
  5. If writing the data.json file fails. In that case you’d get "There has been an error in writing Iris data." in the Rhino command line.
  6. If writing any images fails (adding textures to the img folder). In that case you’d get: "There has been an error in writing Iris image data." in the Rhino command line.
  7. If for some reason writing the irisweb.exe to the export location fails. In that case you’d get "There has been an error in writing Iris application data." in the Rhino command line.

Hi Luis,

None of the above, I’m afraid.

This is the feedback that is echoed to the command line:

Command: Export Preparing WebGL files to be uploaded to a server Failed to save as C:\Data\Iris-TEST\box-check-feedback.iris. The file writing plug-in failed. Command: _CommandHistory

Ouch. So it’s something I’m not catching.
By the way, I installed Windows 7 x64 professional and I cannot replicate this behaviour…It’s a nasty one!

Perhaps / probably related:

I was fooling around with the new PDF exporter a bit just now and went through the dialog to export as WMF. When I cancelled the WMF export, I got the same error message:

When I save the file instead of cancelling, there is no error and the file is saved.

Yes. The same sequence of events occurs, that is, the file writing plugin fails for some reason. In my case, I’m just not sure where it fails. If you’re willing, I will send a debug version that will help us pin point the bug.

Sure, no problem!

Hi Luis,

I have the problem that irisweb.exe does not terminate itself after viewing the scene. Even if I shut down Chrome irisweb.exe keeps running as a background process and I have to end this task in the Taskmanager manually. Otherwise the next local export will just copy the old exe showing always the same scene.

This is on Win 10, Rhino 5 x64, Let me know if you need more info…

Anyways, very cool stuff :wink:

Hi Luis,

I wonder if it is possible to extend an iris scene with certain functionality from three.js?
What I need for example is user input of a few points on the geometry. Of course this is possible in a separate three.js scene but it would be nice if we could “easily” add custom functionality to iris. What do you think?


irisweb.exe and have been erradicated. Next version this will not be an issue.

Does the API suits your needs? Through this you have access to the entire scene, objects, etc. The ui that ships with an Iris scene, for example, uses this API to get access to layers, views, etc. You could write js code that loads after iris.min.js that does anything you need to do from Three.js.
If this does not cover your needs, I need you to be more specific. In essence, anything you guys think is interesting or important to add will be considered! I do plan to write some tutorials that describe how to do these kinds of things.

Hi Luis,

Thanks - we will test this and see how it works.


Hi Luis,

some minor issues:

I’ve tried to click the “Animate Views” button a second time to turn off the animation But then it freaked out. (I noticed that a simple click in the viewport will stop the animation.)

Double click on a named view deletes the view. Is that by design?

Long layer names overflow the layer panel (Chrome:56.0.2924.87)