Re: [Gnu3dkit-dev] Bounding volume recalculation

[Brent Gulanowski]

On Tuesday, October 8, 2002, at 02:08  AM, Philippe C.D. Robert wrote:

> Brent,
>
> On Dienstag, Oktober 8, 2002, at 07:36  Uhr, Brent Gulanowski wrote:
> > v0.3 has a separate recurse for bounding volumes updates. Eberly (3D 
> > Game Engine Design) recommends performing bounding box checks when on 
> > the way back up the rendering recursion. Is this an option?
>
> In 0.4 graph traversal is done much more flexible, ie. you have 
> various kinds of traversals. This is done like that because first the 
> design is cleaner and easier to enhance and second it can be better 
> optimised on multi processor systems. BTW you cannot easily perform 
> the bbox update while traversing upwards because the app might change 
> the graph afterwards (before rendering the next frame) - or do you 
> think of sth different here?

No, I think I agree with you -- bounding boxes are part of the state, 
not the view, and the two may run in different threads. v0.3 had not 
yet implemented threads or thread safety. I've brought up threads in a 
previous email already.

> And I dare to say that the 3DKit is not aimed at games, in games you 
> need a highly tuned, specific implementation, so the 3DKit is more 
> designed to serve visualisation, modelling and research needs.

I'm interested in all of these areas. I think they reside on a spectrum 
of priorities. They will all converge eventually (as far as the 
simulation task is concerned). The things learned in producing games 
for people will one day be very important in applications for training 
A.I. software that learns through experience: high information content, 
scripted actions, objective-based scenarios, etc. Games make sacrifices 
in some areas of the simulation task to support the presentation, but I 
don't think it's necessary to ostracize them. I see 3D graphics as a 
sub-role of the task of simulating a physical environment (real, ideal, 
or imagined): any or all of substances, energy, mechanical physics, 
time, objects, and behavioural entities.

3DKit's role seems to be to manage objects, light spectrum energy and 
perceptual time. (Have I missed anything?) Of these, the task of light 
simulation is partly delegated to OpenGL. This leaves physics, other 
forms of energy, and entities for other parts of the application. I 
previously asked about what application types 3DKit was to be aimed at. 
My personal philosophy is that it is better to think of all 3D work as 
one task, identify the sub-tasks, and then assess how different 
applications prioritize those sub-tasks. My ideal 3D management 
application would be able to handle all simulation types, and would 
dynamically adjust its workflow based on hints provided by the user. 
I'm not expecting 3DKit to aspire to that role. But five to ten years 
from now, such a system is a likelihood. While it's important to make 
the near term goals explicit and realisitic, it's also important to 
position one's work in a larger context. If you don't, you risk making 
yourself redundant, or worse, incompatible :-).

This is just philosophy. I don't expect anyone to agree with me. I hope 
it's not offensive to anyone. I assure you that I have learned to 
distinguish between my personal goals and the goals of any project I 
contribute to (if those are codified, it's that much easier). I guess I 
just wanted to bear my soul a bit :-).

Cheers,
--
Brent Gulanowski                                address@hidden

Ce n'est pas une signature.     -Magritte