Hi, Allen Bierbaum wrote: > Has anyone had time to look at this yet? > > Please help out, 30 minutes is really all it should take. :) > > Thanks, > Allen > > I would appreciate a page "Concepts" or "Best Practices", where proven solutions to middle or large size problems are described. For example: Carsten Neumann wrote: > ... 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...) >
If it works, then I would really appreciate a page collecting such concepts. Another example for illustration: For changing geometry the application creates or changes Geometry nodes in regular intervals. How to do that locally without synchronization in a cluster.. Such a page would be really helpful besides the "fine-scale" documentation. Regards, Christoph ------------------------------------------------------------------------- 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
