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 [email protected] http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
