Basically, there are two priorities when using a software component, particularly a 3D modeling kernel:
- Does it do what you want/need it to?
- Is it always fast enough to be practical?
As a developer for 3D ACIS Modeler, I spend a lot of time thinking about how to make 3D ACIS Modeler faster and, at the same time, more correct. Conventional wisdom often laughs at people who try to compromise correctness for speed: if there is a mathematically right answer, that’s always what you should get.
On the other hand, there is a point where if an operation is too slow it is useless. For example, a faceting algorithm that took 2 hours to facet a sphere would be pretty much useless. Interactive applications push this idea even further. If you want to call an API every time the end user drags their mouse on the screen, the API speed limits your frame rate. To achieve 10 fps, you need the API to take less time that .1 sec. With the computer power that is available today, there are some amazing things CAD applications can do (e.g., the pull operation in SpaceClaim Corporation). ACIS is driven by our customers. This blog was prompted by a project Matthias and I are doing in R25 to make entity-entity distance interactive.
So how can we make 3d more interactive? I have a couple of ideas, but I’d love to hear yours as well:
- The basic algorithms need to be optimal
- Nothing O(n-squared) or worse unless it is impossible to avoid it.
- Is there any costly work being done repeatedly?
- Ask the right questions.
- If you can get by with less work per mouse move, do.
- Pre-compute/memorize if possible.
- Multithread whatever slows you down.
- Avoid static and global variables whenever possible.
- Take advantage of Thread-safe ACIS.
- Optimize greedily
- Profile to find what the bottlenecks are, and focus attention there
- Program lazily
- The more an operation costs, the more can be gained by doing it opportunistically, instead of doing it all the time.
Posted: September 10th, 2013 |
The idea for this post started on Aug 11, 2011, when I read Gregg’s post about choosing a scripting language for 3DScript, the CGM interactive test bed. That article had a lot of good ideas, but I feel like it kind of missed the point regarding Lisp/Scheme/Functional Programming. He used a do loop to try to make the point that the syntax is rather goofy. The reason scheme came up at all is that it is used as a scripting language for acis3dt.exe our 3D ACIS Modeler Test application.
I actually agree that the syntax for a do loop is goofy. However, learning about Lisp (and the lispy features of perl, see http://hop.perl.plover.com/) has made me a much better programmer than I would otherwise be. In some ways, this thesis is older than the hills. To illustrate this, Google various subjects surrounding Lisp, Functional Programming, etc., for example, map-reduce. When I talk with other programmers, I get the feeling that the message bears repeating.
So please bear with me while I sketch a few specifics. Also, feel free to add your own in the comments:
- Referential transparency makes things a lot easier to reason about. Put another way: it is much easier to deal with C/C++ code that doesn’t modify global and static variables.
- The best way to speed up code is to get a smarter algorithm.
- Writing programs as compositions of simple (but high order functions), makes it much easier to reason about them:
- There are a few functional programming clichés that often help in dramatically speeding things up
- Make the algorithm lazy
- Mathematical proofs are very easily given in terms of induction/recursion
- The literature on Lisp has lots of discussion about how you can convert between recursion and iteration.
- Thinking about classes in terms of closures is helpful to me.
A common anti-pattern in legacy code is monolithic and large functions which give a detailed to do list. Typically, I end up extracting functions from the huge monster, turning them into classes, and then parameterizing their behavior. This is really almost the same thing as taking a code snippet, making a closure over the variables you need to encapsulate, etc.
C/C++ still tends to be ubiquitous because:
(a) So many system libraries are written in C or C++
(b) Well written C++ can be very fast
However, C-style languages don’t lend themselves to simple and concise reasoning about code. If there were a well-established Lisp with a good linker, it might eat C’s lunch.
Here's a cartoon on the subject http://imgs.xkcd.com/comics/lisp.jpg
What do you think?
Posted: July 26th, 2013 |
The R24 release of 3D InterOp is now available for download. Although they are available online, not everyone pours over the 3D InterOp Release Notes for R24 like we might hope. What follows is a shorter summary of what’s new in 3D InterOp Suite R24. The description of what’s new falls into three areas; new products, functional enhancements, and platform changes.
Addressing the first, 'new products' area, several additions are included in the R24 release of 3D InterOp. 3D InterOp Graphical now provides the ability to import Solid Edge files. In addition, the new Solid Edge Reader Component allows the import of product structure or exact geometry. The Solid Edge Reader Component is also available as a Direct translator or a Parasolid kernel-based translator. Still on the subject of expanded graphical import, the STEP Graphical Component in 3D InterOp now supports importing graphical PMI from STEP files.
Beyond data translation, many applications have a need to publish graphical data. 3D InterOp Graphical now provides support for writing 3D PDF files. This provides an easy way to distribute 3D information to an audience using the ubiquitous Adobe PDF Reader.
The second area describes the functional enhancements in the R24 release. This is by far the largest area with significant enhancements to every translator. As with each release, 3D InterOp R24 includes faster performance for every translator, especially for large multi-body parts. By leveraging the benefits of multi-processing, most applications should see up to 40% faster translation.
One of the unique characteristics of 3D InterOp translators is the ability to import the various data types as independent chapters of a book. Applications can selectively access product structure, graphical data, geometry, or PMI information. This offers tremendous flexibility to application developers. However, once an application imports data, R24 provides the ability to associate information between these different 'data buckets'. For example, applications can relate PMI information with the Geometry that’s associated with a given GEOMTOL. Or functionality can be presented which allows a user to associate (or link) the graphical display with the associated PMI information highlighted. In other words, this new functionality provides full associativity with owning model geometry and datum / datum targets enabling the applications to walk from graphical PMI to semantic PMI similar to originating source CAD system.
Figure 1: Linking between Graphical PMI and Mechanical/Semantic PMI
Several of the translators now allow the import of materials properties. Material properties could include name, density, or strength. This is now supported in the CATIA V5, NX, Creo, SolidWorks, and Inventor Reader Components. For even more flexibility, the CATIA V5, NX, Creo, and SolidWorks Reader Components now support User Defined Attributes (UDA). This allows applications to import custom name and value pairs.
Although platform changes are not the biggest news, they tend to affect the largest number of users. Mac OS X has changed significantly for this release. The product is now available as 64-bit binaries with the architecture name 'macos_a64'. This new 64-bit support replaces the previous 32-bit support. Microsoft Visual C++ 2010 support was upgraded to Microsoft Visual C++ 2010 (SP1). Additionally, 3D InterOp now supports the Microsoft Visual C++ 2012 32-bit compiler and Microsoft Visual C++ 2012 64-bit compiler on the Windows 32/64-bit (excluding Windows XP) operating systems.
R24 marks the beginning of depreciation for the gcc 4.1.2 (RHEL 4.0 OS), VS 2005 for (Microsoft Windows), and IBM VisualAge C++ 10.1 (Microsoft Windows) compilers. R24 is the last version that supports Windows Vista, Windows XP, as well as the VS 2008 compiler.
Hopefully, this overview has piqued your curiosity to learn more about the R24 release of 3D InterOp Suite. The best resource to see more detail is the 3D InterOp Release Notes for R24. There’s also an excellent on-demand webinar 3D InterOp R24 - Much More Than Just Reading Data hosted by Vivekan Iyengar, Director of Product Development for Spatial.
Posted: July 17th, 2013 |
A geometry kernel is a big thing. It’s a huge thing. Maybe even big enough to see from space. By most accounts, even the Great Wall of China is not visible from space. However, other huge infrastructure is: highways, airports, bridges, and dams. This is the scale for this post. Decades of work, in a five topic flyover.
1. Creating 3D models
If you asked a guy on the street what a geometry kernel was for, odds are he’d reply "creating 3D models". Most 3D ACIS Modeler enabled applications create 3D models. And if you’ve read this far, you’ve probably created a 3D model at some point in your life. The basic steps haven’t changed a lot in the last 25 years.
Sketching is the process used to create a collection of curves, circles, ellipses, lines, and B-splines. Sketching is just connecting the dots, users input points and tangents, then applying constraints on a 2D grid. The collection of curves matches part of a design, or makes one up.
Curves can create surfaces by extruding, revolving, sweeping, or skinning. Surfaces can be trimmed and stitched to create solids.
The construction of primitive solids follows from specific parameters. This may include solids such as spheres, tori, cuboids, etc.
Finally, overlapping simple solids can be combined with Boolean operations like union and subtract to make a complex 3D model. In 3D ACIS Modeler, 3D models can also be non-manifold, combining solids, two sided sheet bodies and wires.
While all the above is standard fare for a geometry kernel, creating stable, fast high-level APIs for a geometry kernel is no small feat. One of the training exercises at Spatial for new 3D ACIS Modeler developers is writing a function to create a solid tetrahedron using low-level interfaces. It’s surprisingly hard - try for yourself.
I cover the other 4 essentials in my eBook. Please click below to download.
1. Don't Reinvent the Wheel
You're designing a new product, but you have an old part that's almost right for the job. Don't redesign it from scratch, import it from its source format and tweak it to meet your current needs.
2. Keep it Tight
If you're designing a part for manufacturing, you need the end product to be water-tight. If your model is “leaky”, your production run might just sink before it gets ever gets launched. If you’re re-using data files and they are not in the best of shape, importing them may help to patch some of those holes during the healing phase and make for clear sailing during production. In this way, data re-use not only extends the life of the model, but it may very well make your model ship-shape to boot!
3. Beauty AND/OR the Beast
Sometimes you just want to show off your model so all you really need is a "glam shot" of your little beauty, but other times you need to work with your model which means loading the whole big beast into your application. You should be able load only the stuff you want when you want it.
4. Garbage In, Garbage Out...or Maybe Not!
If you have models that are a little "dirty", don't throw them out! Clean them up with healing during translation. Models are precious resources and they can have a very long shelf-life. But over the course of time, old data formats fall out of favor and make way for new ones. That doesn’t mean you have to take your old models to the thrift store, but you might need to translate them into a new format. With high-quality translations that include healing, you can effectively refurbish your old models and make them new again. Data re-use can make your old junk into a new treasure.
5. Maximize Your Resources
You've already made an investment in model design, now it's time to get the most from your model by maximizing the number of applications that can work with it. High fidelity translations between a wide variety of formats naturally increase your opportunities to re-use your model.
Valuable development resources should focus on solving your customers’ needs. Adding data interoperability shouldn't be a burden. A simple interface allows your developers to maximize their time working on adding value to your application.
Design and production requires different kinds of data at different points in the process. Getting the kinds of data you need - and no more - just when you need it maximizes your ability to collaborate all along the way.
Some of the models you work with are big, I mean HUGE, monstrous even. Maximize your time working with your model rather than going for coffee by using your machine's resources to the fullest extent possible. That means choosing an interoperability component that is multi-process and multi-thread enabled.
Leah Morgan is a Senior Developer in 3D InterOp
Learn More about 3D InterOp and Data Translation
Posted: April 2nd, 2013 |