Managed to grab a screenshot of the bad normals:
http://i.imgur.com/Z9Wy34a.png
I can upload the board and 3D files if anybody wants. It seems to be
somewhat intermittent and only happen on some instances of the model and
not all the time.
On Sat, 2014-08-16 at 23:56 -0400, Andrew Zonenberg wrote
Also it appears that the "show 3D models" option is broken. It defaults
to unchecked and whether I click or not the 3D models are still drawn.
On Sat, 2014-08-16 at 23:20 -0400, Andrew Zonenberg wrote:
> Possibly a bug in the order layers are drawn in? Alpha blending requires
> specific draw order
Possibly a bug in the order layers are drawn in? Alpha blending requires
specific draw orders to get good results. Top-down requires one order,
bottom-up another
On Sat, 2014-08-16 at 22:13 -0500, Jason Whiteman wrote:
> In my unreleased (due to incomplete status of the entirety of changes
> I was
In my unreleased (due to incomplete status of the entirety of changes I was
working) soldermask arbitrary color / silkscreen arbitrary color
enhancement - I noticed that the soldermask bottom side obstructed traces
so I had to adjust the transparency until both sides were balanced. I
didn't spend
Just to be clear, the bad normals started happening a while ago and this
most recent patch isn't at fault. I haven't had a chance to check older
versions and see if it was introduced by your new normal calculation
code, my parallelism patch, or something else.
On Sat, 2014-08-16 at 22:50 -0400, An
Testing your patch against latest BZR kicad with latest wx from SVN on
Debian 7 amd64, GTX 460m with binary nvidia drivers. Board is 4 layers.
The board looks fine as seen from the top
(http://i.imgur.com/jv4Rfvg.png). Purple color is intentional, I was
trying to make it look like the OSHpark stan
It appears that I can push the files to launchpad. I will make sure the Linux
version builds and load it up so you can look at it to see if it is useful.
Michael
On Aug 16, 2014, at 5:15 PM, Wayne Stambaugh wrote:
> On 8/16/2014 6:28 PM, Michael Narigon wrote:
>> All,
>> I am actually pretty
On 8/16/2014 6:28 PM, Michael Narigon wrote:
> All,
> I am actually pretty far along with this separation of build. Is there a
> recommended location I could post some files so you could see how I
> approached it? I basically expanded the kicad-install.sh script with
> additional steps. One of t
On 8/16/2014 6:22 PM, Cirilo Bernardo wrote:
> - Original Message -
>
>> From: Wayne Stambaugh
>> To: KiCad Developers
>> Cc:
>> Sent: Sunday, August 17, 2014 2:44 AM
>> Subject: [Kicad-developers] KiCad build.
>>
>> One of the tasks that I have committed to working on in the KiCad road
On 8/16/2014 3:27 PM, Dick Hollenbeck wrote:
> On 08/16/2014 11:44 AM, Wayne Stambaugh wrote:
>> One of the tasks that I have committed to working on in the KiCad road
>> map is to clean up the current mess we have created by allowing
>> dependency libraries to be built as part of the KiCad source
All,
I am actually pretty far along with this separation of build. Is there a
recommended location I could post some files so you could see how I approached
it? I basically expanded the kicad-install.sh script with additional steps. One
of the main things I do is I work with completely clean set
- Original Message -
> From: Wayne Stambaugh
> To: KiCad Developers
> Cc:
> Sent: Sunday, August 17, 2014 2:44 AM
> Subject: [Kicad-developers] KiCad build.
>
> One of the tasks that I have committed to working on in the KiCad road
> map is to clean up the current mess we have created
On 8/16/2014 3:07 PM, Jason Whiteman wrote:
> I'm not sure if I'm in the minority - but I have deferred work due to
> build issues with the dependencies. I'm capable of sorting this out
> myself - but wasn't willing to invest the time beyond what I had already
> invested in order to move forward.
On 08/16/2014 11:44 AM, Wayne Stambaugh wrote:
> One of the tasks that I have committed to working on in the KiCad road
> map is to clean up the current mess we have created by allowing
> dependency libraries to be built as part of the KiCad source build. The
> only exception I see for the time be
I'm not sure if I'm in the minority - but I have deferred work due to
build issues with the dependencies. I'm capable of sorting this out myself
- but wasn't willing to invest the time beyond what I had already invested
in order to move forward. Your decoupling will lead to more burden on the
dev
On 8/16/2014 12:08 AM, Andrew Zonenberg wrote:
> DRC_ITEM::m_noCoordinate can be left uninitialized if the second or
> third DRC_ITEM constructor is called and not followed by
> SetShowNoCoordinate().
>
> Fix attached.
>
Patch committed in r5077. Thank you for contributing to KiCad!
Wayne
__
One of the tasks that I have committed to working on in the KiCad road
map is to clean up the current mess we have created by allowing
dependency libraries to be built as part of the KiCad source build. The
only exception I see for the time being is Boost. Although I am have my
reservations on th
On 8/16/2014 5:48 AM, Derek Kozel wrote:
> :) I'll try and fix it today.
Thanks!
>
> My question was more of a procedural one. Does the development team
> prefer that I use the 593782 bug as the reference for this fix, as the
> problems are in the same vicinity, or should I open a new bug given
Dick Hollenbeck:
I don't see this bug when I use: A) new code from last night + B) wx3.x. I
see bug with
wx2.8.
I'm built kicad with wx3 (from ubuntu's repository) and this bug is gone.
Dick Hollenbeck:
I don't know for sure whether using wx3.x alone will fix this, but you could
try. If
:) I'll try and fix it today.
My question was more of a procedural one. Does the development team prefer
that I use the 593782 bug as the reference for this fix, as the problems
are in the same vicinity, or should I open a new bug given that the
original problem is actually fixed and post my patc
20 matches
Mail list logo
