1
0
mirror of git://projects.qi-hardware.com/wernermisc.git synced 2024-11-15 08:50:38 +02:00

cad/: added description to 2nd series of tests and a pointer from the 1st series

- test1/README: added pointer to 2nd series of tests
- test2/README: described findings and theories so far
This commit is contained in:
Werner Almesberger 2011-07-23 07:38:37 -03:00
parent 83ddf112db
commit 8ad6df6b2d
2 changed files with 136 additions and 2 deletions

View File

@ -1,5 +1,5 @@
Comparison of Free scripted 3D CAD systems
==========================================
Comparison of Free scripted 3D CAD systems, part 1
==================================================
Werner Almesberger <werner@almesberger.net>
@ -14,6 +14,10 @@ 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/test1/
Later experiments showed that small changes to the model can lead to
quite different results. The continuation is at
http://projects.qi-hardware.com/index.php/p/wernermisc/source/tree/master/cad/test2/
Objectives
----------
@ -320,6 +324,15 @@ work went into the addition of fillets and chamfers. Neither of the
two systems provides operations to automate such tasks.
The story continues
-------------------
Later experiments showed that small changes to the model can lead to
quite different and generally better results. The continuation of
this evaluation is at
http://projects.qi-hardware.com/index.php/p/wernermisc/source/tree/master/cad/test2/
References
==========

121
cad/test2/README Normal file
View File

@ -0,0 +1,121 @@
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.
---------------------------------------------------------------------