> I took a quick look at Jun (I'm hoping > http://www.sra.co.jp/people/aoki/Jun/Main_e.htm is reasonably up-to-date).
Yes. The > one thing that none of the standard scenegraphs support out of the box is > boolean/topological operations, but the geenral geometry and rendering > should be fine. All reasonable scenegraphs support models, coloring and > opacity, so that shouldn't make difference for the decision. I've sped up Jun over the years, but it still will not run as fast as C, and VW does not support native threads, except in certain kinds of nonblocking external calls. Reflective dynamic language is powerful and difficult to give up. I've been Smalltalking for about 14 years. C++ is hard to tolerate after you've come this way. C is good close to the metal, but is not very expressive. I'm really looking to do port to Smalltalk, if I can. I will talk a look again tonight a my old friend Smalltalk MT, which is interesting, but I could never in the past make it my base dev-environ. It is, however, the only Smalltalk I know of that actually succeeds at letting you write multithreaded code, and compile your frameworks to a DLL. There were some rough edges last time a checked a few years ago, mostly related to memory management. If the GC frequency/duration ratio is not smooth, the environment won't work for rendering. I would like to port OpenSG or OSG to MT or someother multithreaded Smalltalk, if it exists. Strongtalk would actually be my first choice, if it had a graphical debugger and were more stable. Work on this environ is progressing but slowly: http://www.strongtalk.org/index.html. > > The interesting aspect is whether you want to use multi-threading to > parallelize creation and display of your model. I do. SGI have their multipipe SDK programming model, which, as I currently understand it, uses callbacks into your program(s) running in different processes/threads, in order to share the rendering load. My app could benefit from this, but I don't know yet how I want to partition the rendering. In that case OpenSG has an advantage, as it > is designed to do that. How well does it work? Are there good examples of anyone using OpenSG's multithreading? > OSG won't let you change the graph while it's being drawn. That's OK. I don't think I would ever want to do that, anyway. I spoke with an SGI engineer today. He said essentially that Performer is being supported, but not being advanced actively. The guys who budded off OpenSG and OSG have greatly diminished the market for Performer. Too much open-source prevents Performer from competing, but I get the impression that Performer is more finished and ready for serious project work than OpenSG and OSG. Is this correct? > > You can get a general overview of OpenSG at > http://opensg.vrsource.org/trac/wiki/Features, and a (partial) comparison > of OpenSG and OSG at http://opensg.vrsource.org/trac/wiki/Comparison. I read through these last night. Most of the differences seem to relate to supported file-formats. Someone please tell me all of the things they want very badly to do with OpenSG, but cannot yet do because OpenSG doesn't support the needed feature. > Hope it helps Yes, thanks. Shaping > ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ Opensg-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/opensg-users
