Re: gEDA-user: Building the PCB+GL branch [WAS: Re: Open GL survey (for PCB)]

[Gabriel Paubert <paubert@xxxxxxx>]

On Thu, Jan 29, 2009 at 03:57:52AM +0000, Peter Clifton wrote:
> On Wed, 2009-01-28 at 23:53 +0000, Peter Clifton wrote:
> 
> > > > Give the works so far a try:
> > > > 
> > > > http://repo.or.cz/w/geda-pcb/pcjc2.git
> > > > 
> > > > git clone git://repo.or.cz/geda-pcb/pcjc2.git
> > > > git checkout before_pours origin/before_pours
> > > 
> > > git checkout -b before_pours origin/before_pours
> > >               ^_____ Tells git to create a (local) branch
> > 
> > [snip]
> > 
> > > > (Then build as usual).
> > 
> > Since the latest code pushed (which has begun a slight refactoring), you
> > need to call configure with "--enable-gl" for it to look for and link
> > against the required OpenGL libraries and GtkGLExt.
> > 
> > NB: If you don't pass --enable-gl, the build fails.. I didn't yet get to
> > the point where the GL code in the GTK HID is conditionally compiled in.
> > At the moment, its more a GL fork of the GTK HID.
> 
> 
> Cautionary note:
> 
> Beware of accidentally relying on a anti-polygon behaviour I was playing
> with, which is still in the "before_pours" branch.
> 
> Pressing "j" over a polygon turns it into an anti-polygon, which clears
> away other polygons. (It doesn't work with the electrical connectivity
> check though, which may catch you out, and the whole idea might never
> make it into any official PCB release!)
> 
> (The original idea was that islands might be removed as a batch
> operation by inserting computed anti-polygons).
> 
> 
> If you fancy playing with some other experimental polygon stuff though
> (again, not yet backwards compatible), try the "master" branch which
> does full real-time island removal. The broken pieces of "pour" are
> actually now separate "polygons" internally, so work correctly for
> electrical connectivity checking.
> 
> This allows (for example) one big rectangle fill to work on a board, but
> allows islanded sections of the fill either to be removed, or be
> re-connected (not necessarily to the same net), in order that they are
> kept.
> 
> I've still not figured out how to make this work in a backwards
> compatible way. It much more closely matches PCB's _old_ semantics
> before Harry introduced computational polygon support. That change broke
> backwards compatibility with old layouts (which assumed all pieces of 
> polygon were kept) - I don't want to break anyone's designs again!

Indeed, and I still keep an old version around since it worked perfectly 
for my designs, and was _way_ faster on my slow machines.

Actually my question is why was it changed at all? My PCB manufacturers
had absolutely no problems with the stacked positive/negative mixture
of layers in the photoplotter files.

This said OpenGL is the way to go, even on my desktop (8 years old)
which gives ~450fps in glxgears (with direct rendering). 

BTW: I'm actually right now writing a program with OpenGL and am 
running into bugs with antialiasing on Intel graphics (completely 
different visual results from ATI or Nvidia boards when enabling 
antialising). I don't know whether you plan to enable antialiasing
of not, but we should have the option to disable it if enabled.

Another program which might benefit from OpenGL is gerbv AFAIK.

	Gabriel


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