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.
