cool! I'm going to insert a plug here for something related that I have been working on, and indeed have designed a board in: http://sourceforge.net/projects/kicadocaml/ Also has an OpenGL interface, also uses vertex lists (or arrays) for drawing speed + bounding-box culling. Has push routing, continuity testing, cross-probing, gridless design, BOM creation, DRC & rat's nest, but none of this is toally reliable yet (esp. the push routing). If someone were to ask nicely, I might try to make the push routing more useful. (as well as a way of opening gEDA boards? or does someone else want to do this?) cheers! Tim
On Sun, Jun 15, 2008 at 11:13 PM, Joshua Boyd <[EMAIL PROTECTED]> wrote: > On Jun 15, 2008, at 8:27 AM, Peter Clifton wrote: >> >> Thanks for looking, I'm not sure exactly what is required. It will >> basically be the libraries needed for the GTK version (GTK, GLib >> etc..), >> plus GtkGlExt, libGL, libGLU. > > Well, as I have time, I'll keep working on getting the dependencies > ready to give it a shot on Solaris. None of the linux machines I own > have any realistic 3D hardware at the moment. There is an Atom board > with 945 graphics that catches my eye though. > >> I've still got that, I'm not sure how much overhead is associated with >> gluNewQuadric(), my profiling showed hotspots in actually flushing >> commands in the GPU ring-buffer. > > As I understand it, your quad takes one buffer flush, while each disk > also takes a flush, so three flushes per call to that ghid function. > If you combine the single quad and the disks as part of a triangle or > quad strip, you would reduce your flushing by a two thirds. > >> I'm not sure, but what does it take the Z-coordinate to be if we don't >> specify it? (Does it stay at the last Z vertex value, 0)? > > The z value is 0. As I said though, this could end up making no real > difference, but I still think it would be cleaner. >> >>> They mention vertex buffer objects, >>> that I think that may not be the most backwards compatible, but I >>> don't know how far back you want to support. Personally, I like to >>> keep 1.2 supported as much as I can. I'd hold out for 1.0, but >>> working with textures in 1.0 is too painful. >> >> Is that the same as vertex lists? That might help if we can stamp out >> the same triangles again and again for doing vias and pads etc., but >> we'll have to add some some caching mechanism. > > vertex buffer objects are related to vertex lists, but with some > additional abilities. They are newer than I'm used to working with. > > Once you fix up a few easy things, geometry caching is probably where > you will have to look for additional performance. > > > _______________________________________________ > geda-dev mailing list > [email protected] > http://www.seul.org/cgi-bin/mailman/listinfo/geda-dev > _______________________________________________ geda-dev mailing list [email protected] http://www.seul.org/cgi-bin/mailman/listinfo/geda-dev
