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" <mrluze...@ua.pt> 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.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
