[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Gnu3dkit-dev] Re: [Gnu3dkit-discuss] gnuDKit.info: RenderKit - question
[Gnu3dkit-dev] Re: [Gnu3dkit-discuss] gnuDKit.info: RenderKit - questions
Sun, 10 Nov 2002 17:04:29 -0500
On Saturday, November 9, 2002, at 03:53 AM, Philippe C.D. Robert wrote:
On Saturday, November 9, 2002, at 03:59 Uhr, Brent Gulanowski wrote:
uh ... did you do too much C++ programming lately? ...:-} But in
general - for the exposed API - please avoid direct ivar access,
esp. in ObjC! If there is a speed penalty it is certainly not caused
by simple accessors. Or do I missunderstand what you mean here?
I dunno, Phil, I'm just trying to come up with some brainstorming to
compensate for your wet-blanket worries. If you promise not to write
about "big showstopper" problems, I promise not to diverge into
fragile non-OOP techniques for circumventing them. Hey -- this is
just the discussion list, after all.
Of course, I didn't meant to be 'offensive'. What we need *know* is a
plan how to start with the real work, otherwise 0.4 will never take
off... BTW I am not even sure if 0.4 is a good number, because it
sounds like a simple successor to 0.3.x .... what do you think?
No offense taken. ... I don't have any opinion on version numbers --
it's rather arbitrary unless you produce a proper feature release
schedule (aka roadmap).
Wrt the work, for me there is one last real issue which I do not yet
really see through, the scene representation. What if sb would like to
use not a scene graph but an octree or some CSG? How can we offer a
good API to incorporate such scenes in the 3DKit? Ideas?
I am seriously interested in this issue. I think it would make sense to
always have a scene graph, but allow for chunks of that graph to have
alternative scene representations embedded within them. We need to
decide what information we want to preserve in the scene
representation. Do we want to preserve the hierarchical nature of
represented objects? Whenever possible. But this information is
filtered out during rendering, so maybe we can find a way to decouple
the information about object assembly from the geometric information.
Do we want to be able to preserve information about non-polygon
primitives? Ideally. But polygons have to be produced prior to
rendering (in some renderers, at least). What little research I have
been able to do lately suggests that subdivision surfaces may be
valuable here. There is a chance that hardware support for subdivision
surfaces will become common -- ATI's TruForm comes to mind, though I
can't recall if it the same. I think subdivision surfaces are not at
odds with the scene graph -- but it may require duplication of data.
They might also be able to provide CSG without using voxels (I'm weak
in this area).
Then the question is, what about speedy rendering? Fast drawing
pipelines demand triangles -- they are oblivious to structural
organization or semantics. I would like to discuss multiple
representations being used simultaneously. Or again, decoupling could
be sufficient, as long as vertex sets are a constant size or we can
find an effective means for managing changes to raw geometric
information about an object representation.
So how do we decouple the data? Two possibilites:
1) provide both parametric and polygon representations, in redundant
pairs (one of each for each object)
2) keep polygon data in large, re-sizable lists, and have the abstract
objects point into the lists to identify their own polygon
It might even be conceivable to use 2) with BSP and other visibility
sorted representations, but it might be unduly complicated. 1) would
probably not work with such reps unless there was a lot of duplication,
and then it seems unlikely that the objects could be modified without
completely re-building the polygon reps from scratch.
I know it is common to think of scenes as being a combination of static
objects which can be broken up into visible polygon lists, and dynamic
objects which require live visibility determination, but that is an
annoying artificial distinction. Buildings fall down, bridges move,
landscapes change -- nothing is really static. Is this a distinction we
will be forced to maintain for the forseeable future?
Brent Gulanowski address@hidden
Working together to make great software.
- [Gnu3dkit-dev] Re: [Gnu3dkit-discuss] gnuDKit.info: RenderKit - questions,
Brent Gulanowski <=