Le 13/05/2019 à 11:54, Tomasz Wlostowski a écrit : > Hi, > > I've been away for the weekend, here's the reply for all the > questions/comments: > >> As far as I am aware, all commercial tools in the space have more > advanced / modern system requirements than KiCad >> The integrated Intel GPUs that are old enough to not have OpenGL 3.0 > are no longer supported by Intel > > Most (if not all) commercial EDA tools that use GPUs run under Windows > only, which - paradoxically - gives the authors more freedom while > choosing which GPU features to use. While OpenGL 2.1 (with only VS/PS > shaders) is more-or-less supported on all Linux distros, GL 3.0 (with > Geometry Shader support) is at least troublesome. I'm not sure if the > speed/memory improvements provided by using GS will be more beneficial > than additional support effort (fallback to 2.1 on unsupported systems?). > >> I have a *strong preference* for the solution 3. > > JP, You convinced me. This will solve the drawing issue without using > heavy weapons (like GL 3.0). The only thing I'm not sure about is how to > communicate the zone has a 0-width outline (still keeping the minimum > width parameter in the file). Should we add zone property field in the > file format? > > Removing "thick" polygon outlines solves some other issues too - I > noticed Hyperlynx stores polygons with 0-width outlines, so the ones > exported currently from KiCad are thinner than they should be because > there's no inflation code in the exporter. Other EDA software exporters > might also be affected. > >> I don't think any desktop computer released after 2010 would have > issues with GL3 unless the hardware/OS is defective in some way. > > Hardware wouldn't, but drivers would. I still have issues running Half > Life 2 EP2 (a 9-year old game) on a 4-year old laptop with Intel > graphics under Linux... > >> Is it possible to determine openGL hardware support at runtime and use > advanced API on newer machines while switching to fallback for older ones? > > I'd rather go to JP's idea of not using thick outlines instead of > supporting rendering backends for two different OpenGL versions. > >> I don't see the need to tie OS support to hardware support. It's > totally plausible to say, for example, "we'll support users on Debian 6 > but onlyif they have a <10 year old graphics card" > > Expect a lot of complaints on the bug tracker and the forums then :) > >> What about moving the knock-out code to the relative-error calculation > first? Vias probably don't need 32 segments around the edge. Look at > buildZoneFeatureHoleList(). We currently use 32 as the minimum value > for segments per circle > > Good idea, especially combined with JP's solution. Are you going to fix > this? > >> For instance: trying to render just the visible part of the board ( > culling ) or on the case on render the full board, implement some kind > of "level of detail" to render a less accurate version ? ( eg as you > pointed the vias could be a special case and simplified while on distance ) > > We only render the visible part of the board only (glDrawElements() with > indices generated from the currenlty visible item set obtained by > traversing the VIEW's rtree). I'm not sure if it the geometry LOD > wouldn't severely degrade the performance (the cost of generating and > uploading a 1 GB VBO on LOD change - most of board geometry is cached in > the GPU memory) or be just complex to implement (GAL has no LOD for > primitives cached in the GPU RAM). > >> - render the via outline using a rectangular texture with transparent > corners >> - render the via hole in the zone as a simple square, side length = > via diameter, and underneath the texture, so the texture's curve fills > in the square's corners? > > Vias are already rendered using 1 triangle (not even quad) per each, > except the 'texture' is generated by the pixel shader instead of being > static. > >> Would be possible to share that Victor-s project or where we can get it? > > I have been asked to not share the board. Please ask Victor if he'd want > to send you the design. Might be useful for optimizing 3D support. > > Best, > Tom
Hi Tom, If we are talking about V6.0 version, we should add zone property field in the file format like (outline_thickness 0.0) to avoid serious issues (generating broken boards for fabrication). Perhaps also adding a parameter like (circle_optimization [low, normal, high] to optimize shapes with arc/circle items (perhaps useful in microwave applications) I am not a specialist of Hyperlynx and other similar tools, but i am guessing it is not the only one tool that does not handle thick outlines in polygons. A few (or many?) new features will create new file format info, and therefore will create incompatibility with 5.x versions. I made a few very rough tests, and I am thinking we can use to create zone holes: 32 segments by circle for round and oval pads 16 segments by circle for vias and other pads 16 or 8 segments by circle to inflate the zone filled areas, after build them. 8 segments give a reasonably good shape. With these optimizations, the segment count could be even lower than the current optimization. -- Jean-Pierre CHARRAS _______________________________________________ Mailing list: https://launchpad.net/~kicad-developers Post to : [email protected] Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
