gnu3dkit-dev
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Gnu3dkit-dev] OGL 2.0 shading


From: Brent Gulanowski
Subject: Re: [Gnu3dkit-dev] OGL 2.0 shading
Date: Sun, 26 Jan 2003 19:37:28 -0500


On Sunday, January 26, 2003, at 05:39 PM, Gerard Iglesias wrote:

On Sunday, January 26, 2003, at 05:43 PM, Philippe C.D. Robert wrote:

On Sunday, January 26, 2003, at 12:16 Uhr, Gerard Iglesias wrote:
Maybe the G3DCamera would be able to be present in a 3D scene, as a 3D node ? Maybe not a simple 3D note pointing to the camera will do the trick, but I like the idea of a camera being a graphic node ?

I don't like this concept too much, although I am aware that many scene graphs use it. Why do you think it should be done this way?

Because a lot of camera can be used in a scene with different role, and sometimes I want to see them and control them in the scene from the point of view of an other.

But the camera you see and control in the scene can be a kind of special 3D node that is a camera manipulator, not the camera itself...

A visual rep of the camera is not the camera. You do need a way to explicitly connect them if you want to be able to see the location of one camera from the point of view of another, but we can leave that up to the specific application. It's intuitive to connect an object in a scene, to represent the camera, with the frustum, but the camera itself does not necessarily have to be a node. Some cameras won't associate with any geometric representation at all. Others will be what I call "attached" to an object which might be controlled by an A.I. routine when a user wants to see what the A.I. sees.

It depends on what controls what, but I think it would be simple if a camera could be attached to a geometry node (as an outlet) and aligned on an axis and synchronized to that axis. If the object moved, the camera would follow. If you don't want to have an ivar in the geometry node class, then a camera delegate could be used, which would do the work of keeping the camera in synch with the orientation of the object, keeping camera management out of the geometry node class.

And maybe the thing I am confused is the way the camera is designed is a mix of a 3D view plus the frustum camera, without being a view. Ok, I forgot that this way allow to connect the camera to an NSView or something else, hence doesn't depend on AppKit (it was the way I was trying to use gnistep+3DKit 2 years ago, when I was still in a graphics company :( ).

But it would be better to me to separate the view functionalities to the frustum ones.

I'm sure this is how it is going to be, if I understand you right.

Brent Gulanowski
--
Mac game development news and discussion
http://www.idevgames.com

reply via email to

[Prev in Thread] Current Thread [Next in Thread]