Hi Shaping,
Shaping wrote:
>
> 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.
That sounds painful, indeed. :)
> 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.
Yeah, they're not doing software any more. Not enough business for them, I
guess.
> OpenSG
>> has a reflective interface for data, which can make these things
>> 'relatively' easy.
>
> I would like to know more about how this works.
In a nutshell we have a FieldContainer base class that almost everything in the
system is derived from. It has an interface that can tell you which fields an
FC
has, and it has access methods for those fields. It's not fully reflective in
that it only talks about data, not methods, but it can help make certain things
a lot more extensible. The code to this is 99% auto-generated, so if you need
other interfaces you could probably add things to tit (that's going to get a
little messy, though, so if you can stick to the existing interface). Take a
look at FieldContainer and FieldContainerType. I'm not sure what the best
example code for that would be. Allen? Gerrit?
> Yes. Please make him aware of my efforts, if he is not already.
he's on this list, so I'm assuming he knows already. ;)
> 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.
Multi-threading works fine, using multiple graphics cards in one machine to
speed up one image is something that we don't have specifically. You can run
one
box as a cluster, but that's probably not the most efficient way of doing
things.
> 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?
OpenSG: of course. But from what i understand it is a problem in OSG (but I
don't know the details).
> 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?
Not sure, you'll have to ask them. :-) The one thign they will harp on is the
larger community, which is true, but I;m not aware of any technical superiority.
> 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)?
The philosophies behind the two are very different, so merging them is not
really a viable option.
>>> 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?
No problem.
> 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.
That sounds simple enough. You might want to think about textures anyway. They
are essentially free on graphics hardware these days, and they allow you to
specify the interpolation order between different colors, and not have to
depend
on an RGB interpolation to make sense. Just a thought.
Yours
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
