> Hi Shaping, Hi Dirk.
> Shaping wrote: >> >> ... 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. > > I don't know what is entailed in linking a C++ lib to Smalltalk. In any descent Smalltalk, you can link a C library (CDECL or STDCALL calling convention), and call the C routines like they were methods on a class, where the class is an ExternalInterface (VW's term; it goes by other similar names in other Smalltalks) representing the C library. You'd build Smalltalk equivalents of the C++ classes, reify as much state as you need on the Smalltalk site, and pass these parameters into the C calls. The guts of the C++ methods, of course, would have to be in the C library. It's a lot of work. I wanted to do this several years ago with Performer, but SGI don't give you the source with your license. I even talked to their lawyer about it, and he said that SGI was not interested in a Smalltalk port. Now they're just barely interested at all in anything Performer. OpenSG > has a reflective interface for data, which can make these things > 'relatively' easy. I would like to know more about how this works. > I know Allen Bierbaum has done one for Python, he might be able to give > you some hints if you're interested. Yes. Please make him aware of my efforts, if he is not already. > >> 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. > > OpenSG does that, too, in some contexts. Especially when it comes to using > a cluster of machines to split the load, OpenSG makes things fairly simple > compared to other solutions. I didn't know that was an issue for you. It is not so much an issue across a cluster (but could becomes an issue latter). I want to be able to use all of the cores in the new octacore machine I'm getting soon. > >> How well does it work? Are there good examples of anyone using OpenSG's >> multithreading? > > Very well, of course. ;) There are some examples, I don't know if I would > call them good, but they show the pieces and this list is very fast in > responding to problems if they show up. I'll look for links to the examples. > >> That's OK. I don't think I would ever want to do that, anyway. > > Well, that depends, I guess. If the process of creating your geometry to > display is not very fast (wich it might not be if you do it in Smalltalk), > it can be useful to prepare the next iteration's geometry while the > current one is being drawn. Oh, I'm thinking then that this is just a second (or nth) scene graph. Don't we want to be able to do this in OpenSG? > >> 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? > > it is more finished in the sense that it has pretty good documentation > (professional Technical Writers are really helpful for that). Both OpenSG > and OSG have decent Tutorials, but not on par with performers > documentation. Beyond that, technically, I don't think Performer is better > than either one. OK, good to know. I still have lots of reading on the site to do. If I talk to the OSG guys, what will they say in defence of OSG? If there is not an earth-shaking difference between OSG and OpenSG, then why don't the two of you get together, combine efforts, and discard one of the names (or make a new one)? > >> I read through these last night. Most of the differences seem to relate >> to supported file-formats. > > Those are easy to write, so they tend to get long, yes. ;) > >> 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. > > I can't really think of anything, Good to hear, but what about the multiple, concurrently constructed SGs? My model is a space-and-time pig when it comes to computing all of the graphical elements that will be displayed for a large version of it (limited only by system memory and your willingness to wait). I don't have much need yet for textures. The graphical model is all geometry and a little color. but then again, I'm the one who > decides what goes in there, so if something is bad I fix it (or get > somebody else to fix it). > > 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
