Those of you who are ACIS customers are probably familiar with acis3dt.exe – our Scheme-based demo application (which I’ll call A3DT). For those of you who aren’t, it’s an interactive application, written in the mid-90s, that lets you view and manipulate ACIS models by typing script commands (Scheme expressions). The view window provides mouse-driven picking and view manipulation, but anything you can do with the mouse can also be done through a Scheme expression. There is also a helper application which can be used to edit scripts and send them to A3DT (either entirely or line-by-line) for execution, or scripts can be run from the command line in “batch” mode (for testing).
A3DT has been VERY useful over the years for ACIS, in many ways:
Most of our tests are written in scheme
Customers submit bugs as scheme scripts
Customers are encouraged to prototype their workflows in scheme, then examine the C++ behind the script (the extensions are shipped as source code) and use that to guide their application development.
Scheme is the primary demo tool for ACIS – our Technical Account Managers (TAMs) often find themselves writing scripts “on the fly” to answer specific customer questions about ACIS’ capabilities.
When developers want to “play with” ACIS (e.g. create 100,000 blocks to test performance) they do it in scheme.
And now, let’s fast-forward to when we began working on componentizing CGM. In CGM we didn’t have such a scripting engine – instead we had an in-house unit testing engine that could run unit test executables. If you think about it, this made perfect sense. CGM was not developed as a stand-alone product; instead it was part of a GUI-based feature modeling application. In other words, CATIA filled most of the roles for CGM that A3DT fills for ACIS.
For CGM component, however, this was not sufficient. We first noticed this when writing tests – we found ourselves trying to write unit test executables for tests that were really acceptance tests. This was extremely expensive in developer time – being able to see the models you’re creating and do graphical picks on them is extremely important when writing tests of even mildly complicated workflows (e.g. create a block then fillet one of the edges). A more technical way to think of this is that the overhead due to violations of Once and Only Once involved in setting up the input scenarios (which I’ve discussed in the context of design-by-contract) is prohibitively expensive.
A more important problem is that unit tests don’t use the code the way that our customers do: in an application. This is the heart of App Driven Development: you should try to use your own product in the way your customers will.
At the same time, our TAMs were used to having a demo application available for use in presenting our products to customers.
One of the things that surprised me (but probably shouldn’t have) in all this is how rarely people think about scripting interfaces in terms of supplying a command-line interface to applications. In our experience with A3DT (and now C3D), the primary utility is in the ability to sit in front of the application and interactively figure out, line-by-line, what you want to do, while capturing what you’ve figured out in a script. In contrast, it seems like most people think of the utility of scripting in terms of being able to write scripts that will be processed in “batch” mode; in other words it’s very similar to programming, except you don’t have to recompile the executable when you change (or extend) the program. I imagine that a lot of this is driven by the browser-based application market; in such applications the scripting language isn’t the actual interface that’s presented to the user; it’s simply an intermediate programming language that can be run on the browser. I think ignoring the potential of scripting as an interactive interface is a mistake – there are a lot of benefits to having a scripting “hook” into your application.
The challenges of a major software release are not unique to Spatial. And like other organizations, the launch process looks different to various departments in the organization. There are those in Marketing who view each release event as part of a beautiful, butterfly-like progression. On the other end of the spectrum, you have factions within development and testing who see things as more like the manufacturing of really tasty sausage. Across all of Spatial and our partners, however, we are very happy to announce the general availability of 3D ACIS Modeler R23. The R23 release combines improvements to address specific customer requests, general 3D market needs, and improvements that further our strategic roadmap goals.
Nearly all application developers will benefit from significant performance improvements in both 3D ACIS Modeler and 3D InterOp. As part of Spatial’s continuing multi-core strategy, 3D ACIS Modeler includes support for multi-threaded faceting. To simplify implementation for the user, thread management is handled completely within the modeler. Restoring of SAB models, a function used by most ACIS applications, brings dramatic speed improvements of up to 40%. Developers can combine various performance improvements in 3D ACIS Modeler, as well as in 3D InterOp, for even more sizeable performance gains.
Driven by the ongoing priority for advancements to core algorithms, 3D ACIS Modeler extends Boolean and Stitching capabilities. 3D ACIS Modeler includes enhancements to several of the Fuzzy Boolean operations. These types of operations are especially useful in applications which use an approximation of a piece of geometry in a Boolean operation. ACIS is now better able to handle near-coincidence between surfaces that previously would have resulted in sliver faces, performance problems, or even failure.
Cellular topology allows developers to attach attributes, such as material properties, to volumetric cells. New improvements now allow these attributes to migrate through Boolean and Glue operations. Enhancements to the Glue operation provide non-regularized unite capabilities. This is especially useful in flows where manifold solid bodies are joined along coincident faces, providing a big gain in performance compared to using the standard unite operator.
Seeded feature detection is also available in 3D ACIS Modeler R23. This new capability offers significant benefits to direct-modeling applications and other workflows that operate on logical groups of faces. Feature detection functionality helps in the identification of protrusion and depression features as well as blends. Developers have the flexibility to specify whether or not the blends at the boundary of a depression or protrusion feature are to be included as part of the feature.
3D ACIS Modeler also includes new APIs for the extrusion of simple planar faces with the elimination of unnecessary error checking and other overhead. This new API is up to 90% faster and offers significant benefit to industries such as EDA, CAE, and AEC. In these industries, a lot of unnecessary effort goes into the extrusion of something simple like a 2D rectangle which may be used for an electrical component.
For a complete list of improvements see the “R23 Release Notes for 3D ACIS Modeler”. Interested in what’s new in 3D InterOp? Take a look at the “R23 Release Notes for 3D InterOp“. There’s an impressive number of improvements and new features, including a new component option which extends 3D InterOp access to include the native graphical representation of the original CAD model, including graphical PMI, for all 3D InterOp supported formats.
Finally, you can learn much more about 3D ACIS Modeler, as well as the complete portfolio of Spatial components, at the 2012 3D Insiders’ Summit held September 25-26 in Blackhawk Colorado. Summit attendees enjoy the unique opportunity to hear directly from Spatial’s management team about Spatial’s vision and strategy, and get the latest and detailed information on all of Spatial’s products from our software developers and product managers.
As I was sitting here trying to come up with a topic for this post, I was thinking that while I have a million things going on, none of them are post-worthy in and of themselves, and I'm sure nobody wants to read a general post about being busy. Then I had an epiphany, there is something bigger going on that ties it all together.
3D InterOp is going through a paradigm shift.
The longstanding objective of InterOp has been to convert CAD data from 1 format to another while retaining the highest quality. The interface was originally designed with this very simple objective in mind -- give the user a small, clean interface, independent of input or output format.
This all works pretty well, the interface is certainly easy to use. When we added the CGM modeler though, it presented us with some new challenges. Being newly componentized, CGM doesn't have all of the somewhat clunky add-ons that we've put into ACIS to support additional types of incoming data, for instance product structure and PMI. We were faced with a question, do we add these in the same way as we've done in the past so that we can translate all data into 1 format, even when it isn't very clean? The question was particularly relevant because we knew we'd be adding graphical data soon, which didn't have anywhere to go in either ACIS or CGM.
This is where we come to our paradigm shift. We found ourselves asking how people will really use the data and how do we modify the interface with this in mind?
For geometry, this part always came for free. You convert files into a modeler, which then provides a full range of APIs for doing something with the new data - query it, change it, whatever you want. As long as the data is usable by the modeler, InterOp's job is done.
So we had mostly avoided this question, but faced with adding new types of data to both CGM and ACIS, we had to truly address it. Even if we add all new data, like graphical data, into the modeler, we have to make sure there are APIs that allow the user to get it back out and use it. That starts to make things very complicated.
We decided to go for a cleaner approach that was very focused on making sure people had a targeted way of using every type of incoming data. Through this examination, we came to a few key realizations:
The objective of 3D InterOp is not simply to convert from one format to another, but rather to query the source document for different "containers" of data, converting only when necessary.
Rather than one size fits all, theinterfaces for reading such containers should varywith their complexity and downstream use.
If the data is very simple, then a direct API is a great way to access the data, so, for instance, we've added new APIs for extracting product structure and graphical data in memory. This means that applications can put the data directly into their internal representation without any file interaction, saving steps and time. Here the interface is a little more involved because the user is exposed to more.
If the data is more complex, the obvious case being geometry, then you need to put it into something that knows how to represent it and that offers tools for operating on it (the modeler). So here, InterOp's primary responsibility is getting the data into the modeler in the way it expects so it is ready for downstream usage. The user interface for this is very simple because all the work goes on behind the scenes.
There will also be meta data that connects all the different containers together, e.g. attributes and PMI. We're working on figuring out this part.
This is a really cool way of looking at things because it allows us to expand the InterOp interface to handle new data in a concise and flexible way. That's the big picture - which means that in my smaller picture, helping to roll this all out to our customers, there is certainly a lot going on.
Below is an Example of Extracting a Single Instance from a Product Structure