kicad-developers team mailing list archive

[jp charras <jp.charras@xxxxxxxxxx>]

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