Scene Graph ??? - Graphics

"Frashman" <frashman@freenet.de> wrote in message
news:fhgcre$67k$1@inn-newsserver.rz.tu-ilmenau.de...
> 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

"Frashman" <frashman@freenet.de> wrote in message
news:fhgcre$67k$1@inn-newsserver.rz.tu-ilmenau.de...
> 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

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.

On Nov 15, 11:02 am, Frashman <frash...@freenet.de> wrote:
> 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?
>

I would suggest you have a look of David Eberly's "WildMagic", he has
books ("3D Game Engine Design", etc) which mostly cover on designing
a scene graph and operations on it.

On Nov 15, 11:02 am, Frashman <frash...@freenet.de> wrote:
> 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?
>

I would suggest you have a look of David Eberly's "WildMagic", he has
books ("3D Game Engine Design", etc) which mostly cover on designing
a scene graph and operations on it.

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@freenet.de> wrote in message
> news:fhgcre$67k$1@inn-newsserver.rz.tu-ilmenau.de...
>> 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
>
>
>

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@freenet.de> wrote in message
> news:fhgcre$67k$1@inn-newsserver.rz.tu-ilmenau.de...
>> 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
>
>
>

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@freenet.de> wrote in message
> news:fhgcre$67k$1@inn-newsserver.rz.tu-ilmenau.de...
>> 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
>
>
>

I definitely second your opinion!

Dan
J & L Associates
Developer of "lean and mean" ActiveSolid.

"jbwest" <jbwest@comcast.net> wrote in message
news:IPydnSXJL9m7VqbanZ2dnUVZ_vKunZ2d@comcast.com...
>
> "Frashman" <frashman@freenet.de> wrote in message
> news:fhgcre$67k$1@inn-newsserver.rz.tu-ilmenau.de...
> > 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
>
>
>