kicad-developers team mailing list archive

[Cirilo Bernardo <cirilo.bernardo@xxxxxxxxx>]

I see the latest changes from Mario Luzeiro and Oleg Endo.  Wow .. the
3D viewer has improved so much since Mario and I rewrote the code 6+
years ago.  I'm very glad to see people continuing to make
improvements.  If anyone has time and wants a challenge there are 2
items I'm not very happy with in the 3D system. One is due to our
early support for VRML only models as well as IGES models, and the
second issue is due to mistakes I made in interpreting the VRML
specification.

1. Legacy issue: the import of a VRML model (including those exported
by kicad) or an IGES model results in a doubling of the triangular
surfaces. So if you import a box described by 12 triangles that is
double to 24 and if you export the model and import it again you get
48 triangles, and so on. The reason is that every facet is rendered
from *both* sides and there is no algorithm for decimating the
triangle data.  The reason triangles were rendered from both sides is
that many (well, *most*) VRML models which we used before the 3D
overhaul were defective and the viewing normals were not guaranteed to
be correct (a facet described as viewable from the wrong side).  IGES
models also suffer this problem because the specification does not
provide a requirement of a 'right-hand rule' to determine the Inner
side vs Outer side of a surface and various CAD packages seemed to
either use a right-hand rule, left-hand rule, or no rule.  The
triangle bloating problem will obviously have disastrous consequences
for rendering time.  As an alternative to decimating the triangles,
any VRML model exported by KiCad could be specially tagged (similar to
how PDF uses some special comments) so that the importer does not
double the triangles. The advantage of this would be that the VRML
models generated from solid models via scripts could also be tagged
and the doubleg could be avoided altogether where appropriate.

2. Incorrect interpretation of VRML spec.  This is really a fairly
minor issue and I don't believe there is any evidence that it has an
impact on VRML models generated from solid models via
OpenCascade/FreeCAD.  Unfortunately I can't remember the exact problem
now, but at least one of the VRML groups are not correctly implemented
and as a result cannot be correctly referenced by more than 1 other
group. Fixing the implementation could produce a more efficient
exported model in some use cases.

Cirilo