Dave McClurg wrote:
>
> Could we add an optional index array to ssgVtxTable so that a CUBE takes
> 8 vertices and not 36 vertices (with GL_TRIANGLES) ?
Well, hopefully you'd use two GL_TRIANGLE_STRIPs (just 16 vertices) or
two GL_TRIANGLE_FAN's (only 14 vertices) - but your point is a valid one.
> Or is there a reason for not doing so?
There is good reason to develop another ssgLeaf class that can do that - but
I'd like to keep ssgVtxTable the way it is right now because it's the fastest
for simple glBegin/glVertex.../glEnd rendering. But I want to build new leaf
nodes that are more appropriate for compiled vertex arrays - which are the
fastest way to render stuff under most PC-based systems.
It's really just a matter of my time for doing this stuff.
I also need to think about how to deal with multi-texture (which entails
multiple glTexCoord arrays) and glTexGen (which uses a mapping "rule"
instead of texture coordinates.
In each case, a class derived from ssgLeaf will be the way to go.
> I'd like to incorporate most of IVCON (http://www.psc.edu/~burkardt/ivcon.html)
> into SSG. Would that be a good thing?
>
> Before these import/export modules bloat out SSG,
> what type of wrapper should we use?
> Should import/export modules just be linked in or should we have
> a more formal plugin type of arrangement?
Well, I guess this is a case for dynamic linking. DSO's under Linux
and DLL's under Windoze. Step #1 will be to write a portable
dynamic linker wrapper.
The lack of import/export functions in the past blinded me to the
need to do this - but with PPE demanding lots of these, it's
starting to make sense.
--
Steve Baker http://web2.airmail.net/sjbaker1
sjb...@ai... (home) http://www.woodsoup.org/~sbaker
sj...@ht... (work)
|
