kicad-developers team mailing list archive
-
kicad-developers team
-
Mailing list archive
-
Message #40654
Re: Kicad's way of drawing filled zones
-
To:
Ruth Ivimey-Cook <ruth@xxxxxxxxxx>, KiCad Developers <kicad-developers@xxxxxxxxxxxxxxxxxxx>
-
From:
Tomasz Wlostowski <tomasz.wlostowski@xxxxxxx>
-
Date:
Mon, 13 May 2019 11:54:29 +0200
-
Authentication-results:
spf=pass (sender IP is 188.184.36.46) smtp.mailfrom=cern.ch; lists.launchpad.net; dkim=none (message not signed) header.d=none;lists.launchpad.net; dmarc=bestguesspass action=none header.from=cern.ch;
-
Autocrypt:
addr=tomasz.wlostowski@xxxxxxx; prefer-encrypt=mutual; keydata= mQINBFRh3ssBEADmCSrn6qwXrSwI2/LcFSv0aXNHrUQ0MyOAHAW1Rn3LNXLcSCxep1w0iH8q M+ag0XxRVf87DGqjv8wKLGc8nIkGtrMSOuiF+hsrtjAiIrOyOipTABLapqGVj1Dm/26NCtiM /0ZU3XjKcSS5rrj4epKaTM0qW7xp6VceZgH79MbiSCjrt/r9Yhx4tGbWBaCSgTOUHwNB3/Oq 0E5VjU5SAQBQhwG71mES/xaIIUxtfxAPLxpvaq81cjTuT2VQ30T65fSDVikwXrc7M/a2hUG0 nyreo4CktY4pazofQpBA8f8gDPOY1CezY1o1or1Ey6Td/YM/G/Q2G9RZZTjPgD1KRdWIC+nG oCP0lcrMh8Ee+JgR2X7iAAfyVuKAeokxkGnCLon2qiuRG6yAGsEeunJDSd0XtBXzn71GqQH6 0NJzndNoI2PptbHMgc6bINbODkl/RFjVLVGMxDQbgxui2inpjayUZVCQ6SHiiY8BMJrpvTWK GvmgXllxGw+9IQ51u/I0W6hBdy0W/P2oXrP7V2GPDdvyIGJaecjvbkEnD1AbRvxlOjVTGFnC cW08ohzNHGfQK/MXaIpnZAWzRqJz8Wx13KkrdN1hT5quJtaHsvuxBclgHmzbqLlfvLnU7iOa tdN/JzL4L3czEFLJhnHOf9e5zd8yith9vGLUwPxjCzQvz5kBEQARAQABtC1Ub21hc3ogV2xv c3Rvd3NraSA8dG9tYXN6Lndsb3N0b3dza2lAY2Vybi5jaD6JAj4EEwECACgFAlRh3ssCGyMF CQlmAYAGCwkIBwMCBhUIAgkKCwQWAgMBAh4BAheAAAoJEMD02zLS2+sBdxkQAM3Nwk6cU8JT A0uR83NsQEUWjoGboIkVtO5amqWqWGLBguolhEt/NTuzQtmD6rFFhPcOpXDKRKdd6ySdlUB7 8XIgQQTEex6uQpWWV/cLACz6a0u0BONA+VPFzRpWSpOMKpCOcm7izGX9H4CZu4f+bqhL3zaC 38Ki5XxyyioGUzyWd/tw84nz2JgrP1zcYih0Qq82ooO1sRIUrJrm7onb4dH29p7d12uGiQZt go+xeYcDW3TlN4m2tmd7l/JqsD8F0CqtvWrGMsdbr1NE5Y2vyIpG3rkkCiTrlUs0SFyqAC7L qRswP6UZa7enNMhRtJN7eqyrya8J7deRTB6qubP8kTGTt+UTlIgivSqThEN9cJu4cWOsdr3X /D9h7aej1jDSerwKIm7UdmrjkOsgUiZhFMphdAgelmfcVdl7CjsqnnYa5eeeVfEMeT3Fv79V qUcg6LfwUGB56gO4OsnMLGCzCbn6kuwbtlCcV10MsTVzvKNFOrs3mm+yZ2msdLJSV2QMNtHW EVXJV2Tlye+XiYtljdyA6GthK+T/Z9qj8nblunMMN9TwCPkIzzKgyKPxIup/MV7CzN2y8nbp BqkFhApTlXt+NflNdqkfqrWcm+XDXbTwvUzFrKVc8QczpVOMuk7kS+MwxtGGEL6QuML/W8hb k1iEeeAQNiNorHshYTJzGb+luQINBFRh3ssBEADQpjP/NdQTZFh11UxsKAOM3KVPSjYxyOEO Gd65/klc3ZBTXJAaC2XmUhYU/kzhyJU7/dd+ywhsLYsWB21mVucAsANra1BkTFXPQFPQwsPP 15QnWQQwFdX7AoMZYceiXqNSWc48DvnXqlUB8TqzB3dSHys9tzfmc+2TDAlM/TpYKWTtY9Fc 2xsx3ZvOzHE1wi6KmdMuK5qc5QBWY16FJtcFA2D5scd24Zy2cO+QS7fDuQHVQpuV+y8unUQC l3VBdOb21WpYrkyUCJU5yRxTP7kbHOIaNyr6S05zArg0TtEfaqCSDOrljxzxSqLtgnD35enE G9/lvQbX8rG0nR1W4ZnhnEx0hAJk2eJ7v9X2Fiq+3rYiEhUsthfBexxoailNxrFIYFr1qBiG zj1HvzoEQZ0Mz/WU156JJBSKAg1IrWzKswIrcv1FoRVhISiEo4nfJslBthZbJjGJ5veYSU5V K4yUNEvcG98+Z4YKFLREXBq6V1AmiFUVbZ1FblK8TGvQaQ3YJlOWEtDA1yrHnujz5wgxtBSM pUsNApQOs2c0MaksfIgkM1McRDwTemup+wmPJ2U8Hvb5A6lI1G+iiUrXPYahdy8XRMxyM1aU xQz53A8Ex+YK/Qn/16k9BZYs/0k3tXb+WBFBcsq732oCo6n4hbfCoG4gYDn7jlEhnm/aQ1Vr eQARAQABiQIlBBgBAgAPBQJUYd7LAhsMBQkJZgGAAAoJEMD02zLS2+sB6kgQAM4V4jIUJo98 rbCU0Yy8YLahwQK5TynS8+zsQ/s9q+aYT8qWzdcjavfRKA3VArGP8qYBXRIQW7QbceSChTOG hhai+5nIJbWhGXVfEUtZ2txahcY2ecfsDEkvCOK7pLKsCq7eYQzMHV8ZPwGWPq+hZa+6msHh R2yUHo6NV2u2HjVJROaM2nUSZT6hOMhzp+zYwl1XEZKqo+QxDtLWJQ66MZIOAngyWN9/ePUJ 0dxG6V+r9MjgHS/OtVlgCKtvAYJCRGcGiSaL+wjhiaZ1/nwBAL0mwN2UaoP+oYjI09J5/Mff tbtQQHMQwRxy31b6N1ZFunnVkR0MeBlT8JtUI31zroRoQ/4u0+wXTYaeTANa0R73Y/m8aIhE sj2ZDD6NISA0Yxnm1rXUyJZosrcS5WjrpgjAjQvkFpm7Sx8Sx+QWpS+DcL8rJntzwL9cPHPA 3tutTbZ9vQrH20TT8Z4nFzTvytFKb5bydF92Fawph2NjFcwzMi/6i37tS1q1X93ky10vq2M4 MaTxIwyjENy6GT5mPh2YlKhWHN5K+8K7rf6QBsvud+SdN3T1AEJojZEYIvxXi0MMpfB4iqlu z+oUbkdDqZonG9QZIME1/BJ3y5oVp5h1r6+vs58a5p/lHjurNYMgbNmWUAcW3trFwXWJispd DhAcLoHO+yCvkKJabrfOZoa2
-
In-reply-to:
<dd264d56-9f73-8e24-5960-1da27354e224@ivimey.org>
-
Openpgp:
preference=signencrypt
-
User-agent:
Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1
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
Follow ups
References