kicad-developers team mailing list archive

[Bevan Weiss <bevan.weiss@xxxxxxxxx>]

Do we currently have a line that says:
glEnable(GL_CULL_FACE)

That turns on face culling, so removing that should:
a. Render the back of triangles
b. Decrease the performance a little where back faces are indeed internal / non-visible (although z-cull should help with these also)



Regards,
Bevan


On 1 Oct. 2020, 07:48, at 07:48, "Mário Luzeiro" <mrluzeiro@xxxxx> wrote:
>> 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