The Philly Interview: Dr. Sarkar talks about Vectorwork’s Advanced Research Group and More…

At Nemetschek Vectorworks’ Design Summit in Philadelphia, in late April, the three day event was anchored on the last day by the much anticipated technology keynote by Dr. Biplab Sarkar, chief technology officer—the guy who spearheads the entire software engineering and development of Vectorworks and its Nomad mobile product lines.

I had a chance to sit down with Dr. Sarkar immediately after his keynote, to discuss several of the key technologies he presented to the more than 350 participants at the event. Chief among these, was the new Grasshopper-like rival technology called Marionette, which will make Vectorworks 2016 the first true, visual 3D programming environment for both Mac and Windows, beating out planned efforts by Auto-Des-Sys with formZ, Autodesk with Dynamo, and even the gold-standard in this space, McNeel’s Grasshopper with Rhino.

And while Marionette is a huge deal there were other major announcements in the keynote as well. In the following interview we delve into many of the details behind the Summit announcements.

The Interview

AFR (Anthony Frausto-Robledo): Let’s start with research development. Obviously I’ve known for years that you must have research development but it seems like it’s a dedicated, formalized thing now. Can you tell me a little bit about the evolution of that?

BS (Dr. Biplab Sarkar, CTO): Every year, we hold an Innovation Week and some fabulous ideas have emerged from these weeks and from the daily work done by our research team. This allowed us to accelerate our process of getting ideas gathered into the final product quicker than before.

AFR: Who leads this group?

BS: Steve Johnson, who is the senior manager of user interaction and research for Vectorworks, leads this group. The fruits of their work will bear out in the point-cloud technology and features coming up in Vectorworks 2016, and they are also working on streaming, augmented reality, virtual reality and reality capture.

AFR: Those are all very contemporary and leading edge areas.

BS: Yes, we are quite excited about having a dedicated group focused on leading edge innovations.

AFR: So what exactly happens during Innovation Week?

BS: Yeah, we sit around and do nothing but think of ideas…(laughter…).

AFR: I love it. So about how many ideas get generated typically?

BS: We generate sometimes more than 100 ideas.

AFR: How do you choose which to advance for the group’s attention—what’s the process like?

BS: As we look at all the ideas generated during Innovation Week, first we look at the feasibility and how close it is to Vectorworks. We get far-out there ideas—which is good—but sometimes things like ‘we should support UAVs (unmanned aerial vehicles)’ which is interesting but in no way related to Vectorworks. We try to always be close to Vectorworks, so that is the first criteria. It has to be something we can do in Vectorworks or close to Vectorworks.

So that weeds out a lot of ideas right there. Then, the selection process is similar to how ideas find their way into Vectorworks from our users and staff. Lastly, we look at the overall trends and our competitors and this impacts our selection process as to what to pursue with our research group.

Marionette

AFR: How did you decide to do Marionette inside the program versus outside the program?

BS: The reason we decided to develop it inside is because we saw all the basic building blocks for what we needed for Marionette already available in Vectorworks. The architecture for the plugin objects is there, the Python scripting we introduced a couple of versions ago was there—so all those things are there, so why build it as a stand-alone program?

And there are other benefits too. Users don’t have to learn a new user-interface that is different from the core program, like Grasshopper. If you look at Grasshopper’s user-interface, it’s totally different than Rhino, and you have to learn it.

AFR: So will Marionette scripting work be usable to some plugin architecture benefit?

BS: Yes, we discovered that we can save Marionette scripts and package them as complete plugin objects, which is something that Grasshopper cannot do.

AFR: So can this establish a third-party ecosystem of sorts around Marionette scripting? People can package their Marionette work into plugins for others to use…?

BS: Absolutely. We have already begun discussions with folks around that very idea.

AFR: So, how did the feature set for Marionette come about? Did you look at Grasshopper and look at all the things that are typically done?

BS: We looked at Grasshopper, of course, and of course Grasshopper is nearly nine years old, much more mature then where we are today. But our main criteria was to do whatever our existing scripting language can do, whether Python or Vectorscript. So we exposed all the functionality that is available in Vectorworks in Marionette. So if you can do an extrude in Vectorscript, you can do it in Marionette. It’s a one to one correspondence.

AFR: But Marionette is Python based itself, correct?

BS: Yes, and because of this it will also support Python modules and that will bring to Marionette Python modules for connecting and accessing databases and doing things like heavy-duty linear algebra. These are all the things one can include in their scripts.

AFR: What about things like MIT’s Processing tool…what else could you plug-in on the database side to drive Marionette? How wide open it is?

BS: It’s wide open.

Energos

AFR: Tell me a little bit about the new energy analysis technology called Energos.

BS: It’s a design tool not a validation tool. It has the potential in the future to validate but we are not putting it out there like that right now. It has the ability to help you become more confident about your energy assumptions.

AFR: So if a user creates a basic structure, in BIM, assigns its envelope properties for walls, roof and floors, et cetera, inserts fenestration and then runs Energos it will spit out a score, correct? And if the user manipulates the design and re-runs Energos the score changes, thereby enabling iterative evaluation of energy use per design?

BS: Yes. You keep tuning the design so you can claim you have done your best to check the thermal qualities of the design against the environment, checked for thermal bridges, et cetera.

AFR: So is this similar to Sefaira?

BS: We are seeing that Energos is much more accurate than some of the other solutions on the market that focus on design guidance…because of the math behind it.

AFR: Right, so it’s built around an engine, is that engine your own or part of the Nemetschek Group?

BS: The calculation engine is based on Passive House Planning Package (PHPP) and developed in house.

Of Pixar and Parasolid

AFR: So the addition of the Subdivision Surfaces library from Pixar (OpenSubdiv) is another upcoming feature coming to Vectorworks 2016. Is that technology also available in Marionette—can you drive that kind of modeling in scripts?

BS: Yes, it’s possible and also you may know that there are Vectorworks functions that are called up by a command, by name, so you can do the same with Marionette. So that expands the functionality by quite a bit—it’s just amazing.

AFR: Okay, so you have opened up Marionette, you have exposed SubDs to it…you once told me there were like over a thousand modeling functions in the Siemens Parasolid geometry engine behind Vectorworks. So my question is: how much of the kernel is still blue ocean for the architecture market?

BS: I’d say about 70-75 percent. There are some functions that probably will never be used in the architecture market because they are so focused on the mechanical CAD market. Of course, one can argue ‘why do you need deform in an architectural project?’ But we did it. And we think that design is the main thing that attracts users to our tool.

AFR: Thanks for talking to Architosh.

BS: You’re welcome.