Re: [Plib-devel] ssgVtxTable and SSG Import/Export modules

[Steve B. <sjb...@ai...>]

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)