Re: [Kicad-developers] PATCH: Raytracing - a more pleasing way sequencing blocks to render ?
On Thu, 9 May 2019 at 13:06, Wayne Stambaugh wrote:
>
> Hi Henner,
>
> On 5/1/19 9:44 AM, Henner Zeller wrote:
> > On Wed, 1 May 2019 at 06:14, John Beard wrote:
> >>
> >> On 01/05/2019 13:57, Mário Luzeiro wrote:
> >>> Hi John,
> >>>
> >>> yeah the Morton code is to improve cache hits.
> >>>
> >>> Regarding the speed test, since OS are multi-tasking there could be some
> >>> interference on the results so 1s difference is not a very measurable
> >>> difference ( 4% ).
> >>> A possibility would be to run the same scene multiple times and make an
> >>> average of the times.
> >>
> >> Sure, it was just a fun observation. It does change a bit from run to
> >> run, but I was at least expecting a small penalty. Next up, wipes[1] and
> >> then perhaps Snake :-D
> >>
> >> A more robust benchmarking harness would probably be the way to go if we
> >> really were serious about putting the pedal to the metal here.
> >>
> >> But I think the centre-first approach is certainly better usability, but
> >> I'm unsure about the checkerboard.
> >
> > I agree, without checkerboard it makes it quicker to see what is going
> > on in the center. Attached the (even simpler) just spiraling out from
> > the center patch.
>
> I tested this patch and it works as advertised. Would you please fix a
> few minor coding policy issues (missing spaces after opening and before
> closing parentheses) and resubmit it? There is now a clang-format
> (>=3.9) commit hook[1] that allows you to check your code formatting
> before you commit.
Sorry for the formatting mess-up, attached you find the patch properly
clang-tidied.
I really like the new clang tidy script, much more seamless than the
uncrustify stuff from the past.
Thanks,
Henner.
>
> Thanks,
>
> Wayne
>
> [1]:
> http://docs.kicad-pcb.org/doxygen/md_Documentation_development_coding-style-policy.html#tools
>
> >
> >>
> >> Cheers,
> >>
> >> John
> >>
> >> [1]: https://www.youtube.com/watch?v=cGqAu9gj_F0
> >>
> >> ___
> >> 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
diff --git a/3d-viewer/3d_rendering/3d_render_raytracing/c3d_render_raytracing.cpp b/3d-viewer/3d_rendering/3d_render_raytracing/c3d_render_raytracing.cpp
index 27b2ae4bc..3880eaf8c 100644
--- a/3d-viewer/3d_rendering/3d_render_raytracing/c3d_render_raytracing.cpp
+++ b/3d-viewer/3d_rendering/3d_render_raytracing/c3d_render_raytracing.cpp
@@ -28,10 +28,11 @@
*/
#include
-#include
+#include
#include
-#include
#include
+#include
+#include
#include "c3d_render_raytracing.h"
#include "mortoncodes.h"
@@ -2074,6 +2075,13 @@ bool C3D_RENDER_RAYTRACING::initializeOpenGL()
}
+static float distance( const SFVEC2UI& a, const SFVEC2UI& b )
+{
+const float dx = (float) a.x - (float) b.x;
+const float dy = (float) a.y - (float) b.y;
+return hypotf( dx, dy );
+}
+
void C3D_RENDER_RAYTRACING::initialize_block_positions()
{
@@ -2123,26 +2131,24 @@ void C3D_RENDER_RAYTRACING::initialize_block_positions()
m_postshader_ssao.UpdateSize( m_realBufferSize );
-// Calc block positions
+// Calc block positions for regular rendering. Choose an 'inside out'
+// style of rendering
// /
m_blockPositions.clear();
-m_blockPositions.reserve( (m_realBufferSize.x / RAYPACKET_DIM) *
- (m_realBufferSize.y / RAYPACKET_DIM) );
-
-i = 0;
-
-while(1)
-{
-SFVEC2UI blockPos( DecodeMorton2X(i) * RAYPACKET_DIM,
- DecodeMorton2Y(i) * RAYPACKET_DIM );
-i++;
-
-if( (blockPos.x >= m_realBufferSize.x) && (blockPos.y >= m_realBufferSize.y) )
-break;
-
-if( (blockPos.x < m_realBufferSize.x) && (blockPos.y < m_realBufferSize.y) )
-m_blockPositions.push_back( blockPos );
-}
+const int blocks_x = m_realBufferSize.x / RAYPACKET_DIM;
+const int blocks_y = m_realBufferSize.y / RAYPACKET_DIM;
+m_blockPositions.reserve( blocks_x * blocks_y );
+
+for( int x = 0; x < blocks_x; ++x )
+for( int y = 0; y < blocks_y; ++y )
+m_blockPositions.push_back( SFVEC2UI( x * RAYPACKET_DIM, y * RAYPACKET_DIM ) );
+
+const SFVEC2UI center( m_realBufferSize.x / 2, m_realBufferSize.y / 2 );
+std::sort( m_blockPositions.begin(), m_blockPositions.end(),
+[&]( const SFVEC2UI& a, const SFVEC2UI& b ) {
+// Sort order: inside out.
+return distance( a, center ) < dis
Re: [Kicad-developers] KiCad janitor down?
Thanks Orson! On 5/13/19 8:25 AM, Maciej Suminski wrote: > Hi Wayne, > > My laptop's fan has not survived the flight back from KiCon, so I am > still slightly unresponsive without my computer. I do not have the SSH > key to access the Janitor machine at the moment, but I will try to > retrieve it and fix the problem tonight. Sorry for the inconvenience. > > Cheers, > Orson > > On 5/10/19 9:03 PM, Wayne Stambaugh wrote: >> Is the KiCad janitor sleeping on the job again? I push a fix[1] for >> lp:1828214 a couple of hours ago and it still has not updated the bug >> tracker status. Generally it doesn't take this long. >> >> Cheers, >> >> Wayne >> >> [1] >> https://git.launchpad.net/kicad/commit/?id=ae54f34392407cfd9d4628cf3087f07f239cebb2 > > ___ > 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
Re: [Kicad-developers] Kicad's way of drawing filled zones
I guess I should weigh in on this issue. I would prefer we exhaust all other options before bumping opengl to some later version. In the end, we may have to abandoned older systems to get our performance to an acceptable level with complex designs. I consider it more important to serve our power users even if we have to ask users with older systems to run an older version of KiCad for compatibility purposes. I hope we don't have to do that but I am prepared to make that decision should it be necessary. Cheers, Wayne On 5/13/19 5:54 AM, Tomasz Wlostowski wrote: > 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 > > > > > > > > > > ___ > 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/
Re: [Kicad-developers] KiCad janitor down?
Hi Wayne, My laptop's fan has not survived the flight back from KiCon, so I am still slightly unresponsive without my computer. I do not have the SSH key to access the Janitor machine at the moment, but I will try to retrieve it and fix the problem tonight. Sorry for the inconvenience. Cheers, Orson On 5/10/19 9:03 PM, Wayne Stambaugh wrote: > Is the KiCad janitor sleeping on the job again? I push a fix[1] for > lp:1828214 a couple of hours ago and it still has not updated the bug > tracker status. Generally it doesn't take this long. > > Cheers, > > Wayne > > [1] > https://git.launchpad.net/kicad/commit/?id=ae54f34392407cfd9d4628cf3087f07f239cebb2 ___ 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
Re: [Kicad-developers] Kicad's way of drawing filled zones
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 o
Re: [Kicad-developers] Kicad's way of drawing filled zones
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 ___ 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
