bobwall
09-04-2004, 03:32 PM
Hi, I'm a first year college student who has done a
computer terrain generation research project last year
in high school. I chose to design my own scene graph
system because I was just sick at all the examples on how
to implement one since they were exclusively rendering oriented.
Until recently, my understanding of scenegraphs was
only limited to oct/bsp trees and portals. I looked at
Performer and Inventor and decided that they're too bloated
and not abstract/generic enough to use for non rendering
purposes (correct me if I'm wrong).
I'm an absolute design purist and have a tendency to
reinvent the wheel whenever I find something that is
too complex or fundamentally wrong
to use unless everyone else is using it. What I'm
looking for is a minimal api that is very generic and
practical like Renderman (hardly changed in 20 years)
which is my model of perfection for an api (even though
it wasn't designed with volumetric rendering in
mind). It should be able to handle graphs for the
following purposes:
1. Culling (frustum, occlusion, portals, etc).
2. Collision detection. (could use the same graph as
for culling depending on the graph type)
3. Determining relevant lights for an entity (not very
knowlegeble here)
4. Keeping track of meta data for entities (i.e. the
road name of a street) (maybe this doesn't belong in a
graph)
5. Dynamic updates - most of the scene graph concepts
I read about are hiearchical and static (hard to
update when something moves).
So basically, my question is:
Is there or will there be a defacto standard API for scenegraphs that
can handle all the above or will I have to do that myself?
I know that all the above can be done completely without a scene graph and directly at the entity level instead, but that's no good when you have millions of entities in the world.
Also, I want to be able to depict very generic relations that are not limited to being hiearchical. What would be the programming implementation of a graph that can contain both cyclic (portal) nodes and directed (oct tree) nodes?
Could you also elaborate on the similarity between scene
graphs and relational databases? I still don't understand
how a scenegraph could be implemented by a relational database.
Thanks for any help,
Yale
computer terrain generation research project last year
in high school. I chose to design my own scene graph
system because I was just sick at all the examples on how
to implement one since they were exclusively rendering oriented.
Until recently, my understanding of scenegraphs was
only limited to oct/bsp trees and portals. I looked at
Performer and Inventor and decided that they're too bloated
and not abstract/generic enough to use for non rendering
purposes (correct me if I'm wrong).
I'm an absolute design purist and have a tendency to
reinvent the wheel whenever I find something that is
too complex or fundamentally wrong
to use unless everyone else is using it. What I'm
looking for is a minimal api that is very generic and
practical like Renderman (hardly changed in 20 years)
which is my model of perfection for an api (even though
it wasn't designed with volumetric rendering in
mind). It should be able to handle graphs for the
following purposes:
1. Culling (frustum, occlusion, portals, etc).
2. Collision detection. (could use the same graph as
for culling depending on the graph type)
3. Determining relevant lights for an entity (not very
knowlegeble here)
4. Keeping track of meta data for entities (i.e. the
road name of a street) (maybe this doesn't belong in a
graph)
5. Dynamic updates - most of the scene graph concepts
I read about are hiearchical and static (hard to
update when something moves).
So basically, my question is:
Is there or will there be a defacto standard API for scenegraphs that
can handle all the above or will I have to do that myself?
I know that all the above can be done completely without a scene graph and directly at the entity level instead, but that's no good when you have millions of entities in the world.
Also, I want to be able to depict very generic relations that are not limited to being hiearchical. What would be the programming implementation of a graph that can contain both cyclic (portal) nodes and directed (oct tree) nodes?
Could you also elaborate on the similarity between scene
graphs and relational databases? I still don't understand
how a scenegraph could be implemented by a relational database.
Thanks for any help,
Yale