Thank your for your detailed answer.
And i agree with you, a finished scene graph is maybe always to heavy
and to much overload for unused stuff.
my main reason to look for a modern scene graph is only to understand
concepts (and if i try to understand these, i don't want to learn old
stuff)
you gave me some stuff to read, thank you for this.
if i feel ready, i try my own first steps for my application. whatever i
want to do with it ;-)
sincerely,
frank
jbwest schrieb:
> "Frashman" <frashman@[EMAIL PROTECTED]
> wrote in message
> news:fhgcre$67k$1@[EMAIL PROTECTED]
>> Hey Guys,
>>
>> I'm student and experimenting with OpenGL and look for a modern
approach
>> for designing my own object oriented scene graph.
>>
>> I saw, that there are several implementations for it. like cosmo3d,
>> opensg, open scene graph and so on.
>>
>> i have two questions.
>>
>> 1. witch is not so overloaded an has a modern design?
>> 2. is there a tutorial, guides or articles for a modern way to design a
>> scene graph?
>>
>> thank you for your help!
>>
>> sincerely,
>> Frank R.
>
> I'll add Xith3D as a modern JAVA scene graph, JAVA having some arguably
much
> nicer features than C++. (Let's not argue, I'm not trolling).
> http://www.xith.org/
has citations for some articles for you. SG and
OSG
> (unfortunately close names) are both modern and quite active. One (I
forget
> which, I get them confused) is pretty popular in some European circles.
> COSMO as in SGI's old cosmo ? Hmm, thought it died years ago. Hint: look
for
> one that is intrinsically multithreaded. That's at least a clue for
> "modern-ness".
>
> next question is, are you sure a scenegraph is the right thing? I'm sure
it
> sounds like heresy, but after fighting (old) scenegraphs for too many
years
> I've just about given up on them. I've always found that writing a big
> sophisticated app inevtiably finds some significant "impedance mismatch"
> tradeoffs between optimizing app data for rendering traversal, and
> optimizing app data for, well, app use. Usually, what kills me is data
> "bloat", too many copies of too much big data. And when you system is
paging
> to death, well, one's better off without...
>
> Consider, if you will, that the objective is (outside of an academic
> exercise), to be able to write a sophisticated app in the apps' most
natural
> semantics, and (yet) be able to efficiently render graphical aspects
> thereof. My solution to date: write a fit-for-purpose scenegraph, one
that
> matches my app's data semantics. It's always been cheaper (for me, in
the
> long run) to do that than to try to finagle an existing graph system
(for
> very, very large apps), for which a scenegraph hasn't been built. More
than
> once I've seen projects ramp up well on existing graphs, as the basic
stuff
> comes up quickly. Then when you get to that last really differentiating
> 10% -- you hit the wall, and just can't do it well. In an OO world, do
you
> model pure graphical objects, or do you model app objects (that happen
to
> have a ::draw, etc).
>
> Scenegraphs sort of inevitably have a "bias" towards the class(es) of
apps
> that the sponsors have paid for. If you as an app developer have a
similar
> class of app, great. One size-fits-all scenegraph? I dunno...
>
>
>
> jbw
>
>
>
|
