[Kicad-developers] potrace

[Simon Wells]

kicad seems to have a copy of the potrace code in the tree.
potrace_version.h claims this is version 1.12

the potrace website shows this changelog for 1.13 which was released on
22/10

Some critical bugs in the processing of BMP files were fixed. These bugs
allowed the program to be crashed, or potentially to be abused in other
ways, by feeding it specially crafted BMP files. Thanks to Tomasz Buchert
and Agostino Sarubbo for reporting these bugs. Portability was improved for
C99 and for MSVC++. Thanks to Peter Breitenlohner, Nelson Beebe, and Martin
Gieseking for reporting portability issues.


Is there any reason we have a copy of the code in the tree and are not just
making this a another dependency?

There are binaries for win/lin/osx on the potrace website and it is also
available in brew on osx
___
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] help with 3D normals

[Cirilo Bernardo]

Thanks Jose,

 I'll adjust the IDF plugin code to do just that - split the model so the
top and bottom planes have 1 set of vertices and the vertical edge has
smoothed vectors with Z=0.

- Cirilo

On Thu, Dec 17, 2015 at 1:44 AM, José Ignacio  wrote:

> Those artifacts look like duplicate vertexes with normals pointing
> different directions, ideally, for smooth shading wou'd want to break
> up the mesh on each facet of the model (ie: have all vertexes from the
> star pointing up, the other side pointing down and each side pointing
> perpendicular to each rectangle). In Blender you'd use the edgesplit
> modifier since even without the duplicate vertexes that star would
> look really ugly with automatically computed normals and smooth
> shading.
>
>
> On Tue, Dec 15, 2015 at 10:21 PM, Cirilo Bernardo
>  wrote:
> > Hi folks,
> >
> >  I've added 3D per-vertex normal calculations to the 3D model plugins
> > but I'm calculating bad figures as seen in the *.wrl file below and a
> > corresponding render from view3dscene:
> >
> >
> https://drive.google.com/file/d/0By_XTJN-s8aXX3pCeFhWbTZNYWs/view?usp=sharing
> >
> >
> https://drive.google.com/file/d/0By_XTJN-s8aXSmNEMlhOblRlLUE/view?usp=sharing
> >
> > Does anyone have some idea what I could be doing wrong to get such
> artefacts
> > in the image? I would like to fix my per-vertex normals calculation as
> it's
> > meant
> > to be a tool to help 3D plugin developers create normals lists in cases
> > where
> > the model does not provide the information.
> >
> > - 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

Re: [Kicad-developers] [PATCH] Dark Theme Fixups

[Wayne Stambaugh]

I'll shelve this patch for now since it's usefulness seems to be split
depending on you OS.

On 12/15/2015 7:36 PM, Simon Wells wrote:
> I would prefer to see all the applications get a native toolbar for
> their main toolbar, I have only hacked it on in the kicad manager
> currently to see whether it was popular at all. if not then i won't
> bother, however i don't believe the dark patch to remove the gradient
> works very well on OSX esspecially in the manager as then the toolbar
> has no division from the rest of the window.
>  
> 
> Which top toolbar, kicad, eeschema, pcbnew?
> 
> 
> On Wed, Dec 16, 2015 at 10:14 AM, Simon Wells  > wrote:
> 
> http://s14.postimg.org/rnvw70sr5/Screen_Shot_2015_12_16_at_08_02_19.png
> 
> Here is the main toolbar not as AUI on osx, as can be seen this uses
> the native OSX toolbar so fits in better with other applications,
> The gradients mainly seem to come from the AUI toolkit.
> 
> On Wed, Dec 16, 2015 at 6:08 AM, Simon Wells  > wrote:
> 
> I have tested it on OSX with before and after here
> 
> http://s14.postimg.org/gf0kty89t/Untitled_1.png
> 
> I would prefer to see the top toolbar no longer based on the AUI
> as i think it is unnecessary for that particular toolbar as it
> is not really one that needs to be docked and undocked.
> 
> It this was to occur it would be able to use the native toolkits
> on each operating system rather than what it is currently using,
> including on OSX using the titlebar colour for the toolbar which
> is more natural on OSX
> 
> thanks
> 
> Simon
> 
> 
> 
> 
> 
> ___
> 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] PATCH : Enhanced Python Shell - Proposed version

[Wayne Stambaugh]

Your patch fails to build using swig 3.0.6 on windows due to the
comments you added to kicadplugins.i.  Here is the output:

C:/msys64/home/wstambaugh/src/kicad/product/pcbnew/../scripting\kicadplugins.i(101)
: Error: Unknown SWIG preprocessor directive: The (if this is a block of
target language code, delimit it with %{ and %})
C:/msys64/home/wstambaugh/src/kicad/product/pcbnew/../scripting\kicadplugins.i(105)
: Error: Unknown SWIG preprocessor directive: The (if this is a block of
target language code, delimit it with %{ and %})
C:/msys64/home/wstambaugh/src/kicad/product/pcbnew/../scripting\kicadplugins.i(109)
: Error: Unknown SWIG preprocessor directive: The (if this is a block of
target language code, delimit it with %{ and %})
C:/msys64/home/wstambaugh/src/kicad/product/pcbnew/../scripting\kicadplugins.i(113)
: Error: Unknown SWIG preprocessor directive: And (if this is a block of
target language code, delimit it with %{ and %})
C:/msys64/home/wstambaugh/src/kicad/product/pcbnew/../scripting\kicadplugins.i(118)
: Error: Unknown SWIG preprocessor directive: NOTE (if this is a block
of target language code, delimit it with %{ and %})
pcbnew/CMakeFiles/_pcbnew.dir/build.make:61: recipe for target
'pcbnew/pcbnewPYTHON_wrap.cxx' failed

I tried using the recommended %{ %} to wrap the comments.  It built fine
but crashed when I ran it.  Your best bet is to get rid of the comments
or figure out the proper swig technique for wrapping python comments.  I
tried removing the comments and it worked fine.  You also have some
coding policy violations ( missing spaces before and after parenthesis )
that need to fixed.


On 12/16/2015 5:58 AM, Strontium wrote:
> Hello List,
> 
> I believe I have cleaned up my patch and made the enhanced shell do
> everything it should.
> 
> It has a tabbed interface, with simple text editing capabilities.
> 
> Its GUI can be used to introspect the full internal state of pcbnew, as
> exposed by the python interface.
> 
> The editor can be used to code python scripts (with syntax
> highlighting), and it has auto-completion built in.  Ie, type word press
> (dot) and it gives you a list of possibilities which follow. Further,
> you can use the editor to load up KiCad files and edit them without
> having to use an external editor, if one desires.
> 
> It will allow you to save your interactive history, and restore it in a
> new session.  It has a startup file which is executed when the python
> shell first starts, and automatically creates a default if it doesn't
> exist.  All of its configuration, history and startup files are stored
> in the users KiCad configuration directory on each platform.
> 
> The default startup file doesn't do anything, but includes a commented
> out example which will automatically load pcbnew into the shell, and get
> the current board on screen.  Two very common things that need to be
> done most times when you start the python shell.
> 
> The shell is fully written in python, and uses the foundation of
> PyAlamode included with wxpython.  It does not introduce any further
> dependencies on KiCad, everything it achieves is already built into
> KiCad, and not currently exposed.
> 
> It should be possible to extend the shell in future and add features,
> without requiring to hack core code inside pcbnew.
> 
> The changes to the core of pcbnew, that I did, were to facilitate this,
> and I discuss why I did them in earlier posts. They haven't changed in
> this patch.  There may be better ways to achieve this and I am open to
> suggestions.
> 
> I have only tested on Linux, but I do not believe any of the OS specific
> code changes that I made should negatively effect Windows or Mac,
> nevertheless it needs testing on those platforms and I do not have
> access to them.
> 
> Screenshots of it in action:
> 
> http://i.imgur.com/lTFFddR.png
> http://i.imgur.com/qbACtPR.png
> http://i.imgur.com/Yny4Lnc.png
> http://i.imgur.com/q2AjrPi.png
> 
> The code is also available on my github:
> https://github.com/stevenj/kicad-source-mirror/tree/enahnced-python-shell
> 
> Hopefully this is useful.
> 
> Steven
> 
> 
> ___
> 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] PATCH : Enhanced Python Shell - Proposed version

[Strontium]

Hi Wayne,

Thanks for testing this on windows, I really appreciate it a lot.

I moved the offending comments from being inline comments and placed 
them into the Docstring.  It has the added benefit of making them more 
visible to end users.


See: http://i.imgur.com/Zq1pdyV.jpg
(Apologies on the quality of the screen capture.)

I also ran the pure python code I am submitting for the shell through PEP8,
 PEP257 and pyflakes and corrected all problems they highlighted. NOTE: 
They are all style issues and not logic faults.


I don't believe there are style guides for python and KiCad yet, but I 
figured PEP8 and PEP257 would be a minimum.


I believe I fixed the style problem with the C++ code.

Revised patch attached.
Updated code is also on my github.

Steven

On 17/12/15 05:56, Wayne Stambaugh wrote:

Your patch fails to build using swig 3.0.6 on windows due to the
comments you added to kicadplugins.i.  Here is the output:

C:/msys64/home/wstambaugh/src/kicad/product/pcbnew/../scripting\kicadplugins.i(101)
: Error: Unknown SWIG preprocessor directive: The (if this is a block of
target language code, delimit it with %{ and %})
C:/msys64/home/wstambaugh/src/kicad/product/pcbnew/../scripting\kicadplugins.i(105)
: Error: Unknown SWIG preprocessor directive: The (if this is a block of
target language code, delimit it with %{ and %})
C:/msys64/home/wstambaugh/src/kicad/product/pcbnew/../scripting\kicadplugins.i(109)
: Error: Unknown SWIG preprocessor directive: The (if this is a block of
target language code, delimit it with %{ and %})
C:/msys64/home/wstambaugh/src/kicad/product/pcbnew/../scripting\kicadplugins.i(113)
: Error: Unknown SWIG preprocessor directive: And (if this is a block of
target language code, delimit it with %{ and %})
C:/msys64/home/wstambaugh/src/kicad/product/pcbnew/../scripting\kicadplugins.i(118)
: Error: Unknown SWIG preprocessor directive: NOTE (if this is a block
of target language code, delimit it with %{ and %})
pcbnew/CMakeFiles/_pcbnew.dir/build.make:61: recipe for target
'pcbnew/pcbnewPYTHON_wrap.cxx' failed

I tried using the recommended %{ %} to wrap the comments.  It built fine
but crashed when I ran it.  Your best bet is to get rid of the comments
or figure out the proper swig technique for wrapping python comments.  I
tried removing the comments and it worked fine.  You also have some
coding policy violations ( missing spaces before and after parenthesis )
that need to fixed.


On 12/16/2015 5:58 AM, Strontium wrote:

Hello List,

I believe I have cleaned up my patch and made the enhanced shell do
everything it should.

It has a tabbed interface, with simple text editing capabilities.

Its GUI can be used to introspect the full internal state of pcbnew, as
exposed by the python interface.

The editor can be used to code python scripts (with syntax
highlighting), and it has auto-completion built in.  Ie, type word press
(dot) and it gives you a list of possibilities which follow. Further,
you can use the editor to load up KiCad files and edit them without
having to use an external editor, if one desires.

It will allow you to save your interactive history, and restore it in a
new session.  It has a startup file which is executed when the python
shell first starts, and automatically creates a default if it doesn't
exist.  All of its configuration, history and startup files are stored
in the users KiCad configuration directory on each platform.

The default startup file doesn't do anything, but includes a commented
out example which will automatically load pcbnew into the shell, and get
the current board on screen.  Two very common things that need to be
done most times when you start the python shell.

The shell is fully written in python, and uses the foundation of
PyAlamode included with wxpython.  It does not introduce any further
dependencies on KiCad, everything it achieves is already built into
KiCad, and not currently exposed.

It should be possible to extend the shell in future and add features,
without requiring to hack core code inside pcbnew.

The changes to the core of pcbnew, that I did, were to facilitate this,
and I discuss why I did them in earlier posts. They haven't changed in
this patch.  There may be better ways to achieve this and I am open to
suggestions.

I have only tested on Linux, but I do not believe any of the OS specific
code changes that I made should negatively effect Windows or Mac,
nevertheless it needs testing on those platforms and I do not have
access to them.

Screenshots of it in action:

http://i.imgur.com/lTFFddR.png
http://i.imgur.com/qbACtPR.png
http://i.imgur.com/Yny4Lnc.png
http://i.imgur.com/q2AjrPi.png

The code is also available on my github:
https://github.com/stevenj/kicad-source-mirror/tree/enahnced-python-shell

Hopefully this is useful.

Steven


___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : 

Re: [Kicad-developers] help with 3D normals

[José Ignacio]

Actually, I researched a bit better and it appears vrml has a concept of
"crease angle"
http://accad.osu.edu/~pgerstma/class/vnv/resources/info/AnnotatedVrmlRef/ch2-26.htm
So you shouldnt split the mesh when saving to wrl, since a compliant viewer
should take into account the creaseangle field when calculating the normals
for rendering. And the model splitting logic should happen in the viewer
when sending the faces to opengl.

You just need to make sure you have no face normals pointing the wrong way
and have no holes or duplicate vertexes in the mesh.
On Dec 16, 2015 2:51 PM, "Cirilo Bernardo" 
wrote:

> Thanks Jose,
>
>  I'll adjust the IDF plugin code to do just that - split the model so the
> top and bottom planes have 1 set of vertices and the vertical edge has
> smoothed vectors with Z=0.
>
> - Cirilo
>
> On Thu, Dec 17, 2015 at 1:44 AM, José Ignacio 
> wrote:
>
>> Those artifacts look like duplicate vertexes with normals pointing
>> different directions, ideally, for smooth shading wou'd want to break
>> up the mesh on each facet of the model (ie: have all vertexes from the
>> star pointing up, the other side pointing down and each side pointing
>> perpendicular to each rectangle). In Blender you'd use the edgesplit
>> modifier since even without the duplicate vertexes that star would
>> look really ugly with automatically computed normals and smooth
>> shading.
>>
>>
>> On Tue, Dec 15, 2015 at 10:21 PM, Cirilo Bernardo
>>  wrote:
>> > Hi folks,
>> >
>> >  I've added 3D per-vertex normal calculations to the 3D model plugins
>> > but I'm calculating bad figures as seen in the *.wrl file below and a
>> > corresponding render from view3dscene:
>> >
>> >
>> https://drive.google.com/file/d/0By_XTJN-s8aXX3pCeFhWbTZNYWs/view?usp=sharing
>> >
>> >
>> https://drive.google.com/file/d/0By_XTJN-s8aXSmNEMlhOblRlLUE/view?usp=sharing
>> >
>> > Does anyone have some idea what I could be doing wrong to get such
>> artefacts
>> > in the image? I would like to fix my per-vertex normals calculation as
>> it's
>> > meant
>> > to be a tool to help 3D plugin developers create normals lists in cases
>> > where
>> > the model does not provide the information.
>> >
>> > - 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

Re: [Kicad-developers] PATCH: To facilitate easier Via Curtain/Filling

[Torsten Hüter]

Hi Steven,

 

my question are the side-effects of this patch, do you have checked all possible cases?

 

For instance if I'm retaining the nets, what happens if I've forgotten to erase tracks or vias in my design, would that create copper islands?

 

How can I discriminate between the intentional and nonintentional placement of free vias?

 

--

 

I've seen that you have startet your own python script for stitching. Please have a look at my code, I'd really like that we don't have too many implementations of the same feature (Ben has also announced another version). I'm using single pad components for the vias, but should be relative easy to adapt.

 

http://bazaar.launchpad.net/~torstenhtr/kicad/kicad_via_stitching/files/head:/pcbnew/scripting/tools/viastitching/

 

--

 

I like the idea of a special via class. I could imagine that the pcbnew/class_pad.h could be extended or a new class is derived from that. The reason is, that DRC and zone calculations work already well for it and a free via is for manufacturing the same as having a through hole pad. Just a start/stop layer needs to be added for burried/blind vias.

 

Thanks,

Torsten

 

Gesendet: Mittwoch, 16. Dezember 2015 um 02:49 Uhr
Von: Strontium 
An: kicad-developers@lists.launchpad.net
Betreff: Re: [Kicad-developers] PATCH: To facilitate easier Via Curtain/Filling

Hi Wayne, Everyone,

This is the process now. If you have a fill zone, and you start to lay
a track within it, KiCad will assign that track/via to the net of the
zone of the layer you are on. AND, as a board Designer, that's exactly
what you would expect. But then, following this design process, you
press the DRC button.

All of a sudden the Track/Via you just laid in the fill zone, and which
KiCad gave you a Net for, loses its net assignment, and becomes
"unconnected". Now the fill area flows around it, avoiding it by the
distance of the fill clearance.

Its a case of Kicad Giving with one hand (the net from the fill) and
then taking away with the other (net reassignment). All my patch does,
is align these so that once the net has been given by KiCad, it wont
needlessly be taken away. It might be reassigned because of a pad
connection, but it wont otherwise be "lost".

This "misalignment" between the DRC Net reassignment and the laying
code, causes multiple problems, on real boards:

1. If you do this, and it doesn't cause a DRC. You may not notice it,
because a "unconnected" track/via is not a DRC error or warning. So the
design intent of your board is thwarted, you may have fill planes now
disconnected at certain points and not enough vias connecting them,
disconnected islands of fill, etc. This board goes to production, and
is actually flawed. All because the designer ran "DRC" check before
sending it AND there is nothing obvious to highlight the change KiCad
made to the board, to the designer. The only way to find them is a
detailed visual inspection, after every DRC Check.

2. To work around point 1, you need need to criss cross your board with
interconnecting tracks from pads with that net to the vias, so they keep
their assignment. This causes a problem that if you now edit, you have
all of these tracks, which you are only using to keep nets assigned to
your vias, making it very difficult to edit/relay, etc. In many cases
the nearest pad may be on the other side of the board, requiring you to
manually lay a track to it.

OR Place a single pad component which simulates a VIA, but then you cant
use microvias, and you need to now manage the "extra" components.

3. Changing vias/tracks to "unassigned" may introduce "DRC" errors on
the board that weren't there before the DRC pass. So, in effect, KiCad
is actually generating these DRC errors with the DRC check Pass, they
didn’t exist BEFORE the DRC check, but do after. Which, as a board
designer, is surprising and off-putting.

Basically, and at its core, this patch makes the net reassignment code
compatible with the code that lets you place a track/via on a fill plane
and pick up its net. Without it, its like KiCad telling you what you
are doing while editing is OK. But then changing its mind later.

And while my patch allows me to much more easily, manually, lay GND vias
for filling, etc, its utility is not limited to "Via Curtains" or "Via
Fills". For example, you may simply want to put a few extra vias
between two VCC planes to share the current load. This patch makes that
easy and consistent.

I can certainly understand the desire not to implement "quick fixes"
that increase "cruftiness", I wouldn't want that either. And while this
patch is small, I don't think this patch increases cruftiness but
actually reduces cruftiness and makes the board design DRC process less
surprising to a board designer and more consistent with the way the
layout tools work.

Steven

___
Mailing list: https://launchpad.net/~kicad-developers
Post to : 

Re: [Kicad-developers] PATCH: To facilitate easier Via Curtain/Filling

[Strontium]

Hi Torsten,

Regarding the side effects, the patch actually eliminates a side effect, 
and introduces no others.  As it stands, if a via/track is changed to 
unassigned, it has an impact on fill zones and then it IS possible for 
those zones to not fill properly and you can end up with disconnected 
islands or thin traces, as they try and avoid the newly "unassigned" 
vias.  There is no warning/error for this, and it doesn't necessarily 
cause a DRC violation.  The board will change to something the designer 
didn't draw, and they have no way of knowing it, other than a visual 
inspection of every fill zone.


It will continue to reassign any nets that it can, that doesn't change, 
and is essential.  All it does is recover the nets that would change to 
unassigned after the reassignment pass, back to what they were before 
the reassignment pass started.


If a designer wanted to find these stubs, all they need to do is hide 
the fill zones and they become easy enough to see.


Basically, with this patch, if you drew it, that's how it stays. If you 
put a GND stub track in the middle of a GND fill plane, it will have no 
effect on the fill zone, the fill will just cover it.


Its because this patch allows the board to remain "as drawn" that it 
becomes easier to Manually fill vias and Manually stitch vias (both 
through hole and micro).  Without it, you either need to use pads as 
vias, and do without microvias and have to place many redundant 
components in the process, or you need to lay redundant tracks to every 
single via to make them retain the net.


As for my python scripts, they are quick and dirty hacks, at best, to 
solve the problems I had.  They are essentially just assistance to 
manually placing the vias.  I don't for a second promote them as a 
working solution to via filling/stitching.  And I would be keen to work 
with others who have an interest in this for a good solution to that 
problem.


Steven



On 16/12/15 20:23, "Torsten Hüter" wrote:

Hi Steven,
my question are the side-effects of this patch, do you have checked 
all possible cases?
For instance if I'm retaining the nets, what happens if I've forgotten 
to erase tracks or vias in my design, would that create copper islands?
How can I discriminate between the intentional and nonintentional 
placement of free vias?

--
I've seen that you have startet your own python script for stitching. 
Please have a look at my code, I'd really like that we don't have too 
many implementations of the same feature (Ben has also announced 
another version). I'm using single pad components for the vias, but 
should be relative easy to adapt.

http://bazaar.launchpad.net/~torstenhtr/kicad/kicad_via_stitching/files/head:/pcbnew/scripting/tools/viastitching/
--
I like the idea of a special via class. I could imagine that the 
pcbnew/class_pad.h could be extended or a new class is derived from 
that. The reason is, that DRC and zone calculations work already well 
for it and a free via is for manufacturing the same as having a 
through hole pad. Just a start/stop layer needs to be added for 
burried/blind vias.

Thanks,
Torsten
*Gesendet:* Mittwoch, 16. Dezember 2015 um 02:49 Uhr
*Von:* Strontium 
*An:* kicad-developers@lists.launchpad.net
*Betreff:* Re: [Kicad-developers] PATCH: To facilitate easier Via 
Curtain/Filling

Hi Wayne, Everyone,

This is the process now. If you have a fill zone, and you start to lay
a track within it, KiCad will assign that track/via to the net of the
zone of the layer you are on. AND, as a board Designer, that's exactly
what you would expect. But then, following this design process, you
press the DRC button.

All of a sudden the Track/Via you just laid in the fill zone, and which
KiCad gave you a Net for, loses its net assignment, and becomes
"unconnected". Now the fill area flows around it, avoiding it by the
distance of the fill clearance.

Its a case of Kicad Giving with one hand (the net from the fill) and
then taking away with the other (net reassignment). All my patch does,
is align these so that once the net has been given by KiCad, it wont
needlessly be taken away. It might be reassigned because of a pad
connection, but it wont otherwise be "lost".

This "misalignment" between the DRC Net reassignment and the laying
code, causes multiple problems, on real boards:

1. If you do this, and it doesn't cause a DRC. You may not notice it,
because a "unconnected" track/via is not a DRC error or warning. So the
design intent of your board is thwarted, you may have fill planes now
disconnected at certain points and not enough vias connecting them,
disconnected islands of fill, etc. This board goes to production, and
is actually flawed. All because the designer ran "DRC" check before
sending it AND there is nothing obvious to highlight the change KiCad
made to the board, to the designer. The only way to find them is a
detailed visual inspection, after every DRC Check.

2. To work around point 1, you 

Re: [Kicad-developers] New development policies.

[Nick Østergaard]

I think this is good, partly because I think calling it legacy canvas
is more accurate (hence that is what I have called it always) and it
is a stronger indicator that it is deprecated. On a side note to this,
I think we might need to actually describe a bit better what the
difference is on the kicad website, but I am really bad at doing such
things so I have not done it. I guess a lot of newcomers could easily
become confused.

2015-12-16 15:45 GMT+01:00 Simon Wells :
> Due to the "Default Canvas" being called the "Legacy Canvas" is it not time
> to change it in kicad. The current naming of Default canvas also is a bit
> confusing as you would normally see the "Default" one listed as its name as
> well.
>
> The patch i have attached changes all references to Default canvas that i
> could find, and also changes the enums to CANVAS_LEGACY from CANVAS_DEFAULT
>
> ___
> 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] PATCH: To facilitate easier Via Curtain/Filling

[Wayne Stambaugh]

Steve,

You have written a well thought out argument for fixing the DRC.  If we
fix the DRC via checking code, your patch would be unnecessary.  This is
why I am reluctant to commit it.  If I commit your patch, when we
finally do get around to fixing the DRC, someone will have to remember
to remove it because it will no longer serve any purpose.  The root
cause of the problem is the DRC.  The DRC via checking should include
checking for an electrical connection between zones (and/or footprint
pads for heat sinking purposes) having the same net name as the via not
just trace segments which is the current DRC behavior.  This would have
the added advantage of not having to draw traces in a zone (which is
silly) in order to add stitching vias.  The problem is that fixing the
DRC is not a simple patch which is why it hasn't been done yet.  I would
fix it myself but I am up to my eyeballs fixing Eeschema and trying to
be project leader.  I hope you understand why I am reluctant to commit
your patch.  I understand why you are pushing your patch.  Any developer
who has been around long enough is guilty of quick hacks to solve their
immediate problem.  Myself included.  As project leader, I have to look
at the big picture.

Cheers,

Wayne

On 12/15/2015 8:49 PM, Strontium wrote:
> Hi Wayne, Everyone,
> 
> This is the process now.  If you have a fill zone, and you start to lay
> a track within it, KiCad will assign that track/via to the net of the
> zone of the layer you are on.  AND, as a board Designer, that's exactly
> what you would expect. But then, following this design process, you
> press the DRC button.
> 
> All of a sudden the Track/Via you just laid in the fill zone, and which
> KiCad gave you a Net for, loses its net assignment, and becomes
> "unconnected".  Now the fill area flows around it, avoiding it by the
> distance of the fill clearance.
> 
> Its a case of Kicad Giving with one hand (the net from the fill) and
> then taking away with the other (net reassignment).  All my patch does,
> is align these so that once the net has been given by KiCad, it wont
> needlessly be taken away.  It might be reassigned because of a pad
> connection, but it wont otherwise be "lost".
> 
> This "misalignment" between the DRC Net reassignment and the laying
> code, causes multiple problems, on real boards:
> 
> 1. If you do this, and it doesn't cause a DRC.  You may not notice it,
> because a "unconnected" track/via is not a DRC error or warning.  So the
> design intent of your board is thwarted, you may have fill planes now
> disconnected at certain points and not enough vias connecting them,
> disconnected islands of fill, etc.  This board goes to production, and
> is actually flawed. All because the designer ran "DRC" check before
> sending it AND there is nothing obvious to highlight the change KiCad
> made to the board, to the designer.  The only way to find them is a
> detailed visual inspection, after every DRC Check.
> 
> 2. To work around point 1, you need need to criss cross your board with
> interconnecting tracks from pads with that net to the vias, so they keep
> their assignment.  This causes a problem that if you now edit, you have
> all of these tracks, which you are only using to keep nets assigned to
> your vias, making it very difficult to edit/relay, etc.  In many cases
> the nearest pad may be on the other side of the board, requiring you to
> manually lay a track to it.
> 
> OR Place a single pad component which simulates a VIA, but then you cant
> use microvias, and you need to now manage the "extra" components.
> 
> 3. Changing vias/tracks to "unassigned" may introduce "DRC" errors on
> the board that weren't there before the DRC pass.  So, in effect, KiCad
> is actually generating these DRC errors with the DRC check Pass, they
> didn’t exist BEFORE the DRC check, but do after. Which, as a board
> designer, is surprising and off-putting.
> 
> Basically, and at its core, this patch makes the net reassignment code
> compatible with the code that lets you place a track/via on a fill plane
> and pick up its net.  Without it, its like KiCad telling you what you
> are doing while editing is OK.  But then changing its mind later.
> 
> And while my patch allows me to much more easily, manually, lay GND vias
> for filling, etc, its utility is not limited to "Via Curtains" or "Via
> Fills".  For example, you may simply want to put a few extra vias
> between two VCC planes to share the current load.  This patch makes that
> easy and consistent.
> 
> I can certainly understand the desire not to implement "quick fixes"
> that increase "cruftiness", I wouldn't want that either. And while this
> patch is small, I don't think this patch increases cruftiness but
> actually reduces cruftiness and makes the board design DRC process less
> surprising to a board designer and more consistent with the way the
> layout tools work.
> 
> Steven
> 
> ___
> Mailing list: 

Re: [Kicad-developers] help with 3D normals

[José Ignacio]

Those artifacts look like duplicate vertexes with normals pointing
different directions, ideally, for smooth shading wou'd want to break
up the mesh on each facet of the model (ie: have all vertexes from the
star pointing up, the other side pointing down and each side pointing
perpendicular to each rectangle). In Blender you'd use the edgesplit
modifier since even without the duplicate vertexes that star would
look really ugly with automatically computed normals and smooth
shading.


On Tue, Dec 15, 2015 at 10:21 PM, Cirilo Bernardo
 wrote:
> Hi folks,
>
>  I've added 3D per-vertex normal calculations to the 3D model plugins
> but I'm calculating bad figures as seen in the *.wrl file below and a
> corresponding render from view3dscene:
>
> https://drive.google.com/file/d/0By_XTJN-s8aXX3pCeFhWbTZNYWs/view?usp=sharing
>
> https://drive.google.com/file/d/0By_XTJN-s8aXSmNEMlhOblRlLUE/view?usp=sharing
>
> Does anyone have some idea what I could be doing wrong to get such artefacts
> in the image? I would like to fix my per-vertex normals calculation as it's
> meant
> to be a tool to help 3D plugin developers create normals lists in cases
> where
> the model does not provide the information.
>
> - 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

Re: [Kicad-developers] New development policies.

[Simon Wells]

Due to the "Default Canvas" being called the "Legacy Canvas" is it not time
to change it in kicad. The current naming of Default canvas also is a bit
confusing as you would normally see the "Default" one listed as its name as
well.

The patch i have attached changes all references to Default canvas that i
could find, and also changes the enums to CANVAS_LEGACY from CANVAS_DEFAULT


legacy-canvas.patch
Description: Binary data
___
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] New development policies.

[Nick Østergaard]

I was thinking it could just be a small description in on of the blog
posts, alternatively an addition to one of the existing ones or just a
completely new one.  GAL versus default.

2015-12-16 16:40 GMT+01:00 Mark Roszko :
> That's something that should be in the documentation not website. We
> shouldn't be keeping documentation in two places.
>
> On Wed, Dec 16, 2015 at 10:16 AM, Nick Østergaard  wrote:
>> I think this is good, partly because I think calling it legacy canvas
>> is more accurate (hence that is what I have called it always) and it
>> is a stronger indicator that it is deprecated. On a side note to this,
>> I think we might need to actually describe a bit better what the
>> difference is on the kicad website, but I am really bad at doing such
>> things so I have not done it. I guess a lot of newcomers could easily
>> become confused.
>>
>> 2015-12-16 15:45 GMT+01:00 Simon Wells :
>>> Due to the "Default Canvas" being called the "Legacy Canvas" is it not time
>>> to change it in kicad. The current naming of Default canvas also is a bit
>>> confusing as you would normally see the "Default" one listed as its name as
>>> well.
>>>
>>> The patch i have attached changes all references to Default canvas that i
>>> could find, and also changes the enums to CANVAS_LEGACY from CANVAS_DEFAULT
>>>
>>> ___
>>> 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
>
>
>
> --
> Mark

___
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] New development policies.

[Mark Roszko]

That's something that should be in the documentation not website. We
shouldn't be keeping documentation in two places.

On Wed, Dec 16, 2015 at 10:16 AM, Nick Østergaard  wrote:
> I think this is good, partly because I think calling it legacy canvas
> is more accurate (hence that is what I have called it always) and it
> is a stronger indicator that it is deprecated. On a side note to this,
> I think we might need to actually describe a bit better what the
> difference is on the kicad website, but I am really bad at doing such
> things so I have not done it. I guess a lot of newcomers could easily
> become confused.
>
> 2015-12-16 15:45 GMT+01:00 Simon Wells :
>> Due to the "Default Canvas" being called the "Legacy Canvas" is it not time
>> to change it in kicad. The current naming of Default canvas also is a bit
>> confusing as you would normally see the "Default" one listed as its name as
>> well.
>>
>> The patch i have attached changes all references to Default canvas that i
>> could find, and also changes the enums to CANVAS_LEGACY from CANVAS_DEFAULT
>>
>> ___
>> 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



-- 
Mark

___
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

[Kicad-developers] PATCH : Enhanced Python Shell - Proposed version

[Strontium]

Hello List,

I believe I have cleaned up my patch and made the enhanced shell do 
everything it should.


It has a tabbed interface, with simple text editing capabilities.

Its GUI can be used to introspect the full internal state of pcbnew, as 
exposed by the python interface.


The editor can be used to code python scripts (with syntax 
highlighting), and it has auto-completion built in.  Ie, type word press 
(dot) and it gives you a list of possibilities which follow. Further, 
you can use the editor to load up KiCad files and edit them without 
having to use an external editor, if one desires.


It will allow you to save your interactive history, and restore it in a 
new session.  It has a startup file which is executed when the python 
shell first starts, and automatically creates a default if it doesn't 
exist.  All of its configuration, history and startup files are stored 
in the users KiCad configuration directory on each platform.


The default startup file doesn't do anything, but includes a commented 
out example which will automatically load pcbnew into the shell, and get 
the current board on screen.  Two very common things that need to be 
done most times when you start the python shell.


The shell is fully written in python, and uses the foundation of 
PyAlamode included with wxpython.  It does not introduce any further 
dependencies on KiCad, everything it achieves is already built into 
KiCad, and not currently exposed.


It should be possible to extend the shell in future and add features, 
without requiring to hack core code inside pcbnew.


The changes to the core of pcbnew, that I did, were to facilitate this, 
and I discuss why I did them in earlier posts. They haven't changed in 
this patch.  There may be better ways to achieve this and I am open to 
suggestions.


I have only tested on Linux, but I do not believe any of the OS specific 
code changes that I made should negatively effect Windows or Mac, 
nevertheless it needs testing on those platforms and I do not have 
access to them.


Screenshots of it in action:

http://i.imgur.com/lTFFddR.png
http://i.imgur.com/qbACtPR.png
http://i.imgur.com/Yny4Lnc.png
http://i.imgur.com/q2AjrPi.png

The code is also available on my github:
https://github.com/stevenj/kicad-source-mirror/tree/enahnced-python-shell

Hopefully this is useful.

Steven
diff --git a/pcbnew/CMakeLists.txt b/pcbnew/CMakeLists.txt
index ff99a93..469ddbf 100644
--- a/pcbnew/CMakeLists.txt
+++ b/pcbnew/CMakeLists.txt
@@ -678,6 +678,12 @@ if( KICAD_SCRIPTING )
 DESTINATION ${KICAD_DATA}/scripting/plugins
 FILE_PERMISSIONS OWNER_EXECUTE OWNER_READ OWNER_WRITE GROUP_EXECUTE GROUP_READ WORLD_EXECUTE WORLD_READ
 )
+
+# scripting python shell
+install( DIRECTORY ${PROJECT_SOURCE_DIR}/pcbnew/scripting/kicad_pyshell/
+DESTINATION ${KICAD_DATA}/scripting/kicad_pyshell
+FILE_PERMISSIONS OWNER_EXECUTE OWNER_READ OWNER_WRITE GROUP_EXECUTE GROUP_READ WORLD_EXECUTE WORLD_READ
+)
 endif()
 
 if( KICAD_SCRIPTING_MODULES )
diff --git a/pcbnew/pcbframe.cpp b/pcbnew/pcbframe.cpp
index b19fca1..185fcb9 100644
--- a/pcbnew/pcbframe.cpp
+++ b/pcbnew/pcbframe.cpp
@@ -70,8 +70,6 @@
 #include 
 #include 
 
-#include 
-
 #if defined(KICAD_SCRIPTING) || defined(KICAD_SCRIPTING_WXPYTHON)
 #include 
 #endif
@@ -980,9 +978,6 @@ void PCB_EDIT_FRAME::UpdateTitle()
 }
 
 
-wxSize PYTHON_CONSOLE_FRAME::m_frameSize;   ///< The size of the PYTHON_CONSOLE_FRAME frame, stored during a session
-wxPoint PYTHON_CONSOLE_FRAME::m_framePos;   ///< The position ofPYTHON_CONSOLE_FRAME  the frame, stored during a session
-
 void PCB_EDIT_FRAME::ScriptingConsoleEnableDisable( wxCommandEvent& aEvent )
 {
 
@@ -990,7 +985,7 @@ void PCB_EDIT_FRAME::ScriptingConsoleEnableDisable( wxCommandEvent& aEvent )
 bool pythonPanelShown = true;
 
 if( pythonPanelFrame == NULL )
-pythonPanelFrame = new PYTHON_CONSOLE_FRAME( this, pythonConsoleNameId() );
+pythonPanelFrame = CreatePythonShellWindow( this, pythonConsoleNameId() );
 else
 pythonPanelShown = ! pythonPanelFrame->IsShown();
 
diff --git a/pcbnew/pcbnew.cpp b/pcbnew/pcbnew.cpp
index 0abbd00..2277c65 100644
--- a/pcbnew/pcbnew.cpp
+++ b/pcbnew/pcbnew.cpp
@@ -241,36 +241,26 @@ static bool scriptingSetup()
 }
 }
 
-// TODO: make this path definable by the user, and set more than one path
-// (and remove the fixed paths from /scripting/kicadplugins.i)
-
-// wizard plugins are stored in kicad/bin/plugins.
-// so add this path to python scripting default search paths
+// wizard plugins are stored in ../share/kicad/scripting/plugins.
+// so add the base scripting path to python scripting default search paths
 // which are ( [KICAD_PATH] is an environment variable to define)
+// [KICAD_PATH]/scripting
 // [KICAD_PATH]/scripting/plugins
 // Add this default search path:
-path_frag = Pgm().GetExecutablePath() + wxT( 

Re: [Kicad-developers] GLM versioning

[Wayne Stambaugh]

I'll bump this down to 0.9.5.1 until the new 3D viewer code is merged
into the product branch.  I may have to bump it back up during the merge
but that may not be until after next ubuntu lts version is released so
it may be less of an issue.

On 12/16/2015 4:53 AM, Jean-Samuel Reynaud wrote:
> So it's mean that for ppa daily build, I have to create or found a
> backport for glm (for ubuntu 14.04)?
> 
> 
> Le 16/12/2015 10:45, Cirilo Bernardo a écrit :
>> 0.9.5.1 is definitely good enough for the main branch; it's only the new
>> 3D work (which is still far from merging) which might require a higher
>> version (or it might not - it hasn't been tested with 0.9.5.1).
>>
>> - Cirilo
>>
>> On Wed, Dec 16, 2015 at 7:58 PM, Jean-Samuel Reynaud
>> > wrote:
>>
>> Hi,
>>
>> Currently the version on CMakeLists.txt is 0.9.5.4. On Ubuntu 14.04 the
>> available version is 0.9.5.1.
>> Did I build a backport of libglm for ubuntu or 0.9.5.1 is enougth ?
>> or other solution ?
>>
>>
>> Regards,
>> Le 05/12/2015 23:11, Cirilo Bernardo a écrit :
>> > I had a look at GLM issues and it's a bigger hassle than I initially
>> > imagined.
>> >
>> > 1. earlier versions provided a very primitive FindGLM which did not
>> > handle versions
>> > 2. current versions deprecated FindGLM in favor of the glmConfig.cmake
>> > files etc
>> > which in principle allow you to use glm as an 'external' project -
>> > except of course
>> > (a) we still lack a FindGLM (b) installation of these cmake external
>> > project files
>> > is unreliable across distributions and platforms and (c) even if these
>> > external
>> > project files were present it is not clear how we take advantage
>> of the
>> > version info.
>> >
>> > On top of all that, GLM hard-codes the revision number into the
>> top level
>> > CMakeLists.txt and there is no guarantee that this number is the
>> same as
>> > the actual version information which is stored as #defines in
>> setup.hpp.
>> >
>> > SO - it looks to me like the most sensible thing to do is (a) take the
>> > deprecated
>> > FindGLM.cmake file as a primitive starting point to implement our own
>> > version
>> > which supports versioning. The greatest challenge then is
>> extracting the
>> > version information from setup.hpp in a platform independent way.
>> >
>> > - 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
> 

___
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] GLM versioning

[Cirilo Bernardo]

0.9.5.1 is definitely good enough for the main branch; it's only the new 3D
work (which is still far from merging) which might require a higher version
(or it might not - it hasn't been tested with 0.9.5.1).

- Cirilo

On Wed, Dec 16, 2015 at 7:58 PM, Jean-Samuel Reynaud 
wrote:

> Hi,
>
> Currently the version on CMakeLists.txt is 0.9.5.4. On Ubuntu 14.04 the
> available version is 0.9.5.1.
> Did I build a backport of libglm for ubuntu or 0.9.5.1 is enougth ?
> or other solution ?
>
>
> Regards,
> Le 05/12/2015 23:11, Cirilo Bernardo a écrit :
> > I had a look at GLM issues and it's a bigger hassle than I initially
> > imagined.
> >
> > 1. earlier versions provided a very primitive FindGLM which did not
> > handle versions
> > 2. current versions deprecated FindGLM in favor of the glmConfig.cmake
> > files etc
> > which in principle allow you to use glm as an 'external' project -
> > except of course
> > (a) we still lack a FindGLM (b) installation of these cmake external
> > project files
> > is unreliable across distributions and platforms and (c) even if these
> > external
> > project files were present it is not clear how we take advantage of the
> > version info.
> >
> > On top of all that, GLM hard-codes the revision number into the top level
> > CMakeLists.txt and there is no guarantee that this number is the same as
> > the actual version information which is stored as #defines in setup.hpp.
> >
> > SO - it looks to me like the most sensible thing to do is (a) take the
> > deprecated
> > FindGLM.cmake file as a primitive starting point to implement our own
> > version
> > which supports versioning. The greatest challenge then is extracting the
> > version information from setup.hpp in a platform independent way.
> >
> > - 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

Re: [Kicad-developers] GLM versioning

[Jean-Samuel Reynaud]

Hi,

Currently the version on CMakeLists.txt is 0.9.5.4. On Ubuntu 14.04 the
available version is 0.9.5.1.
Did I build a backport of libglm for ubuntu or 0.9.5.1 is enougth ?
or other solution ?


Regards,
Le 05/12/2015 23:11, Cirilo Bernardo a écrit :
> I had a look at GLM issues and it's a bigger hassle than I initially
> imagined.
> 
> 1. earlier versions provided a very primitive FindGLM which did not
> handle versions
> 2. current versions deprecated FindGLM in favor of the glmConfig.cmake
> files etc
> which in principle allow you to use glm as an 'external' project -
> except of course
> (a) we still lack a FindGLM (b) installation of these cmake external
> project files
> is unreliable across distributions and platforms and (c) even if these
> external
> project files were present it is not clear how we take advantage of the
> version info.
> 
> On top of all that, GLM hard-codes the revision number into the top level
> CMakeLists.txt and there is no guarantee that this number is the same as
> the actual version information which is stored as #defines in setup.hpp.
> 
> SO - it looks to me like the most sensible thing to do is (a) take the
> deprecated
> FindGLM.cmake file as a primitive starting point to implement our own
> version
> which supports versioning. The greatest challenge then is extracting the
> version information from setup.hpp in a platform independent way.
> 
> - 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

Re: [Kicad-developers] help with 3D normals

[Mário Luzeiro]

Hi Cirilo,

A "big picture" comment about the normals and normals in VRML:

VRML does not support explicitly (or implicitly? O_o) "normals 
per-vertex-per-face".

Take your file as reference, you stored vertex list, indexes list and "normals 
per-vertex" (== size of vertex list).
So in this case (and it is what VRML supports ) you are storing normals per 
vertex (with the same size)== size of the vertex list, it means that vertexes 
will share normals.

However, in your model example, that may not be what you want for that model.
Since you have top and bottom planes and contours triangles, they are in a 
completely in opposite directions.
If you share this way the vertices it will look stranger because they will get 
normals that the geometry and your mind is not expecting.

For example:
http://download.autodesk.com/us/fbx/3ds_max_help/fbx_3dsmax_online/files/WS1a9193826455f5ff-6d86117c4584e5420a2.htm
In the first image, they use same normals per vertex as you, and you see that 
the cube shading will look strange because the calculated normal of the vertex 
are pointing in the direction (of the first image)

The "per vertex normals" are better used when you have smooth transitions in 
the model, example:
http://4.bp.blogspot.com/-cmhdqSY0yrQ/UJGdjgUeH-I/BMk/DgLVaeg4LrQ/s1600/vertexLighting.jpg
http://www.math.ubc.ca/~cass/courses/m308-03b/projects-03b/drader/images/bezier_patch_example_2.jpg
http://static.highend3d.com/tutorialimages/229/nm_high.jpg

For your star model the facenormals (or not storing any normals at all) is the 
best solution.

This was in fact an issue while working in VRML / 3d-viewer because some models 
files come with bad normals or normals per-vertex but they look better flatted 
(because the nature geometry of the model)
So I had implemented and two methods to internal calculate the normals, the 
regular normal per face and a "smooth" "normal per-vertex-per-face" (that was a 
slow but good quality algorithm)

If you really want to store "normal per-vertex-per-face" in VRML, you have to 
store all triangles individually. i.e:
V1,V2,V3, V4,V5,V6, V7,V8,V9 ... // vertices list for individual triangles
1,2,3, 4,5,6, 7,8,9 ...// indexes of triangles with NO REUSE
N1,N2,N3, N4,N5,N6, N7,N8,N9 // normal list for individual vertices of 
individual triangles

In summary:
Face normal: good for objects with sharp geometry (cubes.. rectangular shapes.. 
etc)
Per-vertex normals: good for objects that are already smooth by nature (eg the 
cylinder contours sides, sphere.. it also work good in objects that are very 
tesselated ==lots of triangles to make approximations or smooth transitions )
Per-vertex-per-face normals: if the object have sharp and smooth parts.

My suggestion would be:
For VRML, only store face normals (or dont store it and loader/render will 
calculate it.. no problem) or store per-vertex normals (as you are doing) if it 
if OK for model.
Store "Per-vertex-per-face normals" if you don't mind with the file size, if 
not, loader plugins can calculate it (from original file vertice / face 
information) in run time (slow) if you want.. and you may store it the new 
model in cache.

Anyway, this may not be related with the cause of your normal issue.

Cheers,
Mario 'KammutierSpule' Luzeiro


From: Kicad-developers 
[kicad-developers-bounces+mrluzeiro=ua...@lists.launchpad.net] on behalf of 
Cirilo Bernardo [cirilo.berna...@gmail.com]
Sent: 16 December 2015 04:21
To: KiCad Developers
Subject: [Kicad-developers] help with 3D normals

Hi folks,

 I've added 3D per-vertex normal calculations to the 3D model plugins
but I'm calculating bad figures as seen in the *.wrl file below and a
corresponding render from view3dscene:

https://drive.google.com/file/d/0By_XTJN-s8aXX3pCeFhWbTZNYWs/view?usp=sharing

https://drive.google.com/file/d/0By_XTJN-s8aXSmNEMlhOblRlLUE/view?usp=sharing

Does anyone have some idea what I could be doing wrong to get such artefacts
in the image? I would like to fix my per-vertex normals calculation as it's 
meant
to be a tool to help 3D plugin developers create normals lists in cases where
the model does not provide the information.

- 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