> 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.we...@gmail.com> Sent: 30 September 2020 22:32 To: Cirilo Bernardo Cc: Mário Luzeiro; kicad-developers@lists.launchpad.net 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.berna...@gmail.com<mailto:cirilo.berna...@gmail.com>> 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 <mrluze...@ua.pt> 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.berna...@gmail.com> 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@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp ________________________________ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp _______________________________________________ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
