Re: gEDA-user: pcb flip-sides

[Peter Clifton <pcjc2@xxxxxxxxx>]

On Thu, 2009-10-29 at 13:20 -0400, DJ Delorie wrote:
> The whole problem of "physical stack" is something we're working on
> separately.  I think we've agreed that the physical stack is
> determined by the layer *group* order, from the "component" group
> through the "solder" group.

I got very (very) ((very)) confused by the code. Since everything is
indexed by the same range of numbers, it is easy to make mistakes. I
suspect I have made mistakes..

When I'm in 3D view, I order z-coordinates by the physical stack order,
but I suspect I'm mistakenly ordering by an array index for sequence of
rendering.. If I take a board, and _move_ a layer, the z-coords move
correctly, but I'm still rendering in the old sequence. (DOH)

>   This breaks when you have copper outside
> those two, like "component, solder, signal1, signal2" but oh well.

If we can fix persistence of layer colours, we can offer some quick and
easy ways to fix that kind of issue.

What this doesn't define.. is material thickness etc..

> The second thing the core needs to know is the editing stacking order
> - the order in which the user has selected to view the layers, and the
> priority order that it uses for selecting things you click on (like
> traces).

(3D view should ignore that.. at least for now. I suspect I'll try to do
something "clever" with transparency to ensure that you can always see
the layer you're trying to edit). Swapping rendering order produces
visual brokenness.

>   The core needs to know which of the seven traces you just
> clicked on is the one you meant, and to do that, it needs to know
> what's "on top" visually.

I think some kind of de-saturation of colours for non-selectable layers
might be useful. 2D view keeps the same semantics as the old GTK HID 2D
view (as much as possible). With 3D, there is too much conflict to allow
selecting tracks on the non-current layer since the cross-hair has a
z-coordinate too!. (Not that I've implemented of these restrictions /
visualisations yet.)

> What the core does NOT need to know is the rotational orientation of
> the board on the screen, or the scale - it only needs to know relative
> distance from the viewer, so it can figure out what a mouse click does

(The 3D stuff might necessitate allowing the GUI more explicit control
on this point - even if the GUI ends up having to lie to the core about
what layers are visible).

> and what order to draw things in.

PCB+GL (3D view) takes over completely here, as the core cannot sensibly
be taught enough detail to cater for every rendering requirement.. for
example: each through-hole has the portion of its walls above the
current layer drawn (every layer).

_Not_ replacing the core's drawing routines in that case would require
the GUI to cache all rendering commands until after it had enough
information to build the complete picture of the board (ie.. it might as
well figure it out from the board data-structures).

I may have to move some of the more useful drawing routines in draw.c to
be exported API - possibly into hid/common/draw_helpers.c

Best wishes,

Peter C.




_______________________________________________
geda-user mailing list
geda-user@xxxxxxxxxxxxxx
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user