Daniel Sperka wrote:
> ============================== switching off digent mode!
> =========================
> Hmmm. That makes a lot of sense. I'll have to check, but my gut tells me that
> I'll need 1000's of
> nodes. Not a big deal, but as users control the configuration I cannot ensure
> that they'll never
> run out of nodes.
>
> I was hoping to be able to do something like
>
> geo->setDList(nextAvailable);
>
> and run a separate thread which periodically cleans up used DLists and sends
> fresh ones across for
> compilation.
Ok, it's just that you could view a Geometry core sort of as a wrapper
for a DList. From that point of view, what you describe above becomes:
Have the thread construct geos and build the display lists (someone who
knows the best way to do this, please chime in), then add them to some
pool where you pull one out on demand.
If you are really worried about memory consumption by the geometries,
you could think about removing the vertices from the geo after the DList
is constructed and trick it into not rebuilding (but still using) the
DList (well, actually I'm not sure this is possible, but maybe this is
useful for other applications with huge static models...)
Cheers,
Carsten
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys -- and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Opensg-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/opensg-users
