Hi Shaping,
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. OpenSG
has a reflective interface for data, which can make these things
'relatively' easy. I know Allen Bierbaum has done one for Python, he
might be able to give you some hints if you're interested.
> 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.
> 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.
> 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.
> 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.
> 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, 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
Dirk
-------------------------------------------------------------------------
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
