Hello Dirk,
> Note that these volumes are in local coordinate space, so they never
> change unless you change Nodes underneath them. If you want world
> volumes you need to call getWorldVolume();
Yep, that got it. Thanks a lot!
> In a sense the Camera is part of the scene graph, at least the part that
> matters: the beacon. The Observers are set on top of the camera, as they
> need information that can't be extracted from the Beacon matrix.
The beacon is the node towards which the camera is looking, correct? If that's
the case, that's why it wouldn't have worked in my case. See below.
> > So for example, when the observer moves forward, I have a
> > Transform node which has the whole scenery as its children, and I move that
> > backwards by the same amount.
>
> Hm, yes, that sounds complicated. What are you trying to achieve?
The program I'm doing is basically a shooter game where you have targets and you
have to hit them with arrows. The thing that's causing all these headaches is
this : The player is in a boat which moves on water (obviously) and the targets
are on islands or floating in the air.
Basically, I started by trying to move the camera with the boat, but I was lazy
(I admit it! :-) so I thought that making the scenery (the targets, islands,
etc.) move instead would be easier. It does simplify some things, but it seems
to complicate others as I've come to find out in the last days.
The scene graph I made is this:
Root
/ \
Boat SceneryRoot__________________________
/ \ | \ \ \ \
Arrow1 Arrow2 Target1 Target2 Obstacle1 Island1 etc.
With every node having its transform node as parent, but those were omitted from
the representation above for simplicity. What I do is that when my program calls
boat->translate( Vec3f v ); , behind the scenes the boat calls
sceneryRoot->translate( -v ); .
If I could have put the camera in the scene graph, I could have just done this:
Root__________________________________
/ \ \ \ \ \
Camera Target1 Target2 Obstacle1 Island1 etc.
|
Boat
/ \
Arrow1 Arrow2
And then just moved the camera itself, and the boat would have moved with it.
And then the targets would have really been immobile.
The other reason why (I think) my way will actually make things simpler is that
my program will be run in a CAVE (with VR Juggler), and since my program always
keeps the camera at (0, 0, 0) in reality (since it's the scenery that's moving
around the observer) then there shouldn't be any problem with the person in the
CAVE moving around (in the confines of the CAVE, which is the boat in my
program).
Or did I get the camera beacon thing wrong? If that's the case, I'll just turn
my things around and it'll simplify my program a lot!
Thanks,
J-S
--
______________________________________________________
Jean-Sebastien Guay [EMAIL PROTECTED]
http://whitestar02.webhop.org
-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems? Stop! Download the new AJAX search engine that makes
searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click
_______________________________________________
Opensg-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/opensg-users
