Re: gEDA-user: More OpenGL ideas

[Peter Clifton <pcjc2@xxxxxxxxx>]

On Thu, 2010-10-28 at 11:59 -0700, Ben Jackson wrote:
> On Thu, Oct 28, 2010 at 06:52:16PM +0100, Peter Clifton wrote:
> > 
> > The layer textures could be A8 textures, rather then ARGB textures.
> > (Saving 4x memory). This would require the combining to be done in a
> > pixel shader which can colour each layer.
> 
> The fixed pipeline already multiplies the front color by the texture.
> Typically you set the color to 1,1,1 so you get the texture unmodified,
> but you could set it to a color and use a white texture.

The object only gets one colour though.. I was talking about
multi-texturing with (say) eight A8 textures, one representing each
layer. Each would have to blend in its own colour, but given the
assumption (for the most part true) that my layer images would be
mono-coloured, storing the layers as RGBA is wasteful of memory and
memory bandwidth.

Notably, "found" / "selected" objects would have to be drawn / flagged
separately

> > I'm not yet sure how to do colouring of selected components (will
> > probably require the geometry to be re-spat-out with flags on selected
> > parts, or selected parts drawn separately).
> 
> If you remember where each component is in the VBO you can just draw the
> sub-array corresponding to selected component.  You could use the same
> information to avoid drawing it "plain" or something like glPolygonOffset
> to overdraw the highlighted version.

Good point. Currently, the first object / polygon to put down copper in
an area will fill in the stencil, so any subsequent selected object
isn't drawn fully. (It is always occluded by the non-selected colour of
overlapping objects drawn prior to it). (NB: The stencilling introduces
that kind of z-order inversion).

In my scheme, you would draw the selected objects first (marking the
stencil), then subsequent over-drawing would not modify the colour
buffer. This is partly why polygons are sub-composited separately from
lines and other copper objects.. if we didn't, you'd not see the
richness of the line routing when covered by a polygon.

> > For "finding" connected tracks, I thought if might be nice to tag the
> > vertices we emit with a netID number. I don't know how quickly we'd run
> > out of IDs, but it shouldn't be a real issue.
> 
> Every uniform and attribute is a float.  If you use whole float numbers
> you'd only have 24 bits.  If you carefully pack the data into the whole
> 32-bit float you could probably manage to use the exponent bits too.
> But you can always use a 2, 3 or 4 float attribute as well.

Indeed. I'm not sure the limit on attributes, but I know the intel i965
driver will allocate enough message passing space in the GPU to pass as
many varyings as you want. I wasn't explicitly aware we couldn't pass
integer uniforms / varyings.

I don't think we should / can / want to do any searching in each vertex
shader, so any colour selection needs to be based on flag(s) or
identifiers which can be tested in constant time.

If we note where objects are in the VBO, we can just zap new flags into
the vertex attributes defining colour. For the moment, I'm only caching
VBO entries for polygon contours, other objects (aside from arcs) tend
to be so simple it would not be worth the overhead unless we could cache
an entire layer's worth of VBO.

Even intel i965 has only just got NV_PRIMATIVE_RESTART support in mesa
(and I'm not convinced it isn't just a hack to split up the arrays
manually in mesa), so to split tristrip geometry I'm issuing degenerate
vertices: one repeated start vertex and one repeated end-vertex. These
create degenerate triangles with the previous / next strip of actual
triangles, and should be culled pretty early in the graphics pipeline
because they have zero area.

-- 
Peter Clifton

Electrical Engineering Division,
Engineering Department,
University of Cambridge,
9, JJ Thomson Avenue,
Cambridge
CB3 0FA

Tel: +44 (0)7729 980173 - (No signal in the lab!)
Tel: +44 (0)1223 748328 - (Shared lab phone, ask for me)



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