kicad-developers team mailing list archive

[Mário Luzeiro <mrluzeiro@xxxxx>]

> Normally culling of polygons with non-camera facing normals is an optimisation and can be turned off.

It is but I'm not sure / dont remember then how it will work with the lighting.

I'm not sure if the "facing normals" are the only issue. It could be also related with triangle orientation?


> Is this not possible in the 3d render libraries we're using?

The libraries are OpenGL and KiCad source code :)

Mario

________________________________________
From: Bevan Weiss <bevan.weiss@xxxxxxxxx>
Sent: 30 September 2020 22:32
To: Cirilo Bernardo
Cc: Mário Luzeiro; kicad-developers@xxxxxxxxxxxxxxxxxxx
Subject: Re: [Kicad-developers] Thanks for all the new work on the 3D rendering.

Normally culling of polygons with non-camera facing normals is an optimisation and can be turned off.
Is this not possible in the 3d render libraries we're using?


Regards,
Bevan
On 1 Oct. 2020, at 06:23, Cirilo Bernardo <cirilo.bernardo@xxxxxxxxx<mailto:cirilo.bernardo@xxxxxxxxx>> wrote:

Hi Mario,

 I never thought of a good way to manage the doubling of the vertices /
viewing from both sides. Since this is a problem of IGES as well as
VRML models (especially models not produced via MCAD) and it
makes no sense to me to complicate KiCad or the 3D viewer, maybe
one way to fix this would be to mark a bad model file by putting a
'_' at the end of the name, for example 'broken-model_.igs". Files
with that tag will be assumed to have bad normals and the vertices
will be doubled, otherwise normals are assumed to be good.

Cirilo


On Thu, Oct 1, 2020 at 12:36 AM Mário Luzeiro <mrluzeiro@xxxxx> wrote:

 Thanks Cirilo!
 It has been small additions but resulted in good improvements...

 results in a doubling of the triangular surfaces

 Could an option be added to this? ( both exporter and 3D-Viewer )

 I didn't know / don't remember this condition, but I have an idea of some inverted models cases too...

 Mario

________________________________

 From: Kicad-developers <kicad-developers-bounces+mrluzeiro=ua.pt<http://ua.pt>@lists.launchpad.net> on behalf of Cirilo Bernardo <cirilo.bernardo@xxxxxxxxx>
 Sent: 29 September 2020 04:51
 To: KiCad Developers
 Subject: [Kicad-developers] Thanks for all the new work on the 3D rendering.

 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

________________________________

 Mailing list: https://launchpad.net/~kicad-developers
 Post to     : kicad-developers@xxxxxxxxxxxxxxxxxxx
 Unsubscribe : https://launchpad.net/~kicad-developers
 More help   : https://help.launchpad.net/ListHelp

________________________________

Mailing list: https://launchpad.net/~kicad-developers
Post to     : kicad-developers@xxxxxxxxxxxxxxxxxxx
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp