Hello Markus,
Markus Wienhöfer wrote:
> Hi everyone,
>
> I hope this is the right place to ask these questions.
yes, definitely.
> 1) We'd like to be able to navigate the scene using the Walk Navigator.
> As I understand it this navigator also checks for object intersection
> and blocks movement through objects. In the documentation I saw the
> possibility to set a ground and world for the navigator. Is this needed
> or optional.
After a quick look into the code, I'd say it is needed for correct
operation.
> Currently our Navigator seems to work partially - when
> hovering over the ground and switching to walk, the view "snaps" back to
> ground level. Two problems arise though: the navigator seems to stop
> when reaching a wall (simple plane in our case), the view penetrates the
> wall though, additionally the navigator gets stuck - unable to move
> back. Second problem is that it happens that the view tilts to one side.
> I tried to set an UpVector, but with no success. Do I need a ground
> object? I seem to remember from old times with Performer that if no
> ground was given a ray was cast "downward" to check for a ground?
the nodes you pass in as world and ground to the navigator are used as
the roots of a simple intersection test. So basically you should be able
to set them both to the root of your scene, although that might be
inefficient and perhaps even create false intersection if you have
things like a skydome or similar.
> 2) Fly and Walk Navigator: When clicking left or right mouse button the
> view only advanced one frame. When keeping the button down _and_ moving
> the mouse, the scene moved forward. I tried to fix this by connecting
> the glut idle callback to the display function. Now keeping the mouse
> button pressed seems to work. Pressing and moving seems to speed up the
> movement alot though. Shouldn't this be a consistent speed? What are we
> doing wrong?
hm, is your display callback called directly somewhere or are you making
sure to only have it invoked indirectly by calling glutPostRedisplay ?
It seems that moving the mouse triggers more calls to Navigator::moveTo
than when it is called from Navigator::idle. Sorry, offhand I've no idea
what might cause that or what to do about it.
> 3) Lighting and Shadows: We are trying to light a simple room with a
> couple of pillars with 2 point lights and 1 directional light.
>
> Point light problems: The shadows cast seem to be correct mostly,
> although some shadows seem to be in wrong places. Is this because point
> lights do have a direction although they should be omnidirectional?
>
> Spotlight: The Spotlight seems to correctly light the pillars, but not
> the floor. The floor gets lit by the other lights correctly though, so
> normals should be ok.
in theory lights should only affect the nodes below them in the graph.
Early versions of OpenSG did not get this quite right and AFAIK now
strange things are being done to avoid breaking apps that rely on the
old behavior.
Anyway, how does your scenegraph look like, where are the objects in
relation to the lights ?
> 4) mgr->SetStatistics(): I tried to use the Statistics view I saw in a
> couple of the tutorials. Setting this to true though doesn't change our
> scene display. Is this because we are using a shadow viewport?
Hm, it should not, as turning on the statistics only adds another
foreground to the viewport. Depending on how/if you create your window
or viewport you might confuse the SSM and it adds the
SimpleStatisticsForeground to the wrong viewport perhaps ?
Hope it helps,
Carsten
-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Opensg-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/opensg-users
