1
0
mirror of git://projects.qi-hardware.com/wernermisc.git synced 2024-12-18 19:31:53 +02:00
wernermisc/cad/test2
2011-07-23 11:16:02 -03:00
..
button.py cad/test2/: copied original version of sources from cad/test1/ 2011-07-23 11:16:02 -03:00
button.scad cad/test2/: copied original version of sources from cad/test1/ 2011-07-23 11:16:02 -03:00
Makefile cad/test2/: copied original version of sources from cad/test1/ 2011-07-23 11:16:02 -03:00
README cad/: added description to 2nd series of tests and a pointer from the 1st series 2011-07-23 07:38:37 -03:00

Comparison of Free scripted 3D CAD systems, part 2
==================================================

Werner Almesberger <werner@almesberger.net>

This is the continuation of my evaluation of scripted 3D CAD systems.
It shows new findings and improvements since the last test.


Introduction
============

This file and the sources of the models can be found in
http://projects.qi-hardware.com/index.php/p/wernermisc/source/tree/master/cad/test2/


New findings and hypotheses
===========================


The road to hell is paved with good intentions
----------------------------------------------

The original model tried to prevent the creation of artefacts through
rounding errors. It turned out that this isn't only unnecessary with
Cadmium, but it massively slows down the rendering.

Also, after removing these preventions the bug the "noise" parameter
worked around no longer appeared.

This is a comparison of run time (in seconds) and mesh size:

                real    user    system  faces   vertices
Before:         4901.0  4904.4     1.5  8362    3183
After:           316.3   315.9     0.3  2942    1473

This makes Cadmium only about 3.7 times slower than OpenSCAD's CGAL
rendering, a marked improvement from the previous factor of 57. The
resulting mesh is now less than half the size of the mesh generated
by OpenSCAD.

Furthermore, the model is much easier to design and more
understandable without these extra tolerances.


Context: preventing artefacts
-----------------------------

When subtracting volumes from each other, surfaces that coincide in
both the original volume and the one subtracted from it, can remain
as arbitrarily thin artefacts.

This 2D example illustrates the effect:

- given an original shape A like this

  +---------------+
  |               |
  |               |
  |               |
  |               |
  |               |
  +---------------+

- we want to subtract the following shape from it:

         +--------+
         |        |
         +--------+
 
- expecting this to result in something like

  +---------------+
  |               |
  |      +--------+
  |      |
  |      +--------+
  |               |
  +---------------+

- however, if the subtraction isn't perfectly exact, we may get this
  instead:

  +---------------+
  |               |
  |      +--------+
  |      |        |<--- very thin surface
  |      +---^----+
  |          |    |
  +----------|----+
             |
          empty space

- to avoid this problem, we could enlarge the shape that is
  subtracted:

         +---------+
         |         |
         +---------+


Artefacts in OpenSCAD's mesh may also be rounding errors
--------------------------------------------------------

The artefacts found in the mesh produced by OpenSCAD may also be
caused from rounding errors. In this case, the problem would be parts
that are fused along a common surface. As in the above example, this
could be solved by making the parts overlap a little.

Whether this is truly the source of the artefacts still needs to be
verified.


OpenCSG problems may be an OpenGL compatibility issue
-----------------------------------------------------

It could be that OpenCSG showing volumes to be removed just with a
different color without actually removing them is caused by using
OpenGL emulation in Mesa. This needs further investigation.

---------------------------------------------------------------------