Menu
▾
▴
Re: [sgl-dev] SGL and TuxFleet
|
From: Scott M. <smc...@er...> - 2000-11-17 05:47:41
|
Alexander Rawass wrote:
>
> Hi,
>
> first thanks *a lot* for modifying the fleet_scene_* files I sent you,
> that was more than I expected :-))))
I am sure that what I gave you is not complete yet. Today, I have
finally gotten around to downloading plib-1.3.1 and building
it and trying to write the SSG equivalent to testLoaders. It
has been an enlightening experience which required wandering
through Steve's code trying to figure out what is different.
>
> In attachment the modified/compiling version of these files.
> I also attached the plib-ssg version of TuxFleet for comparison.
>
> But no 3D models get drawn on the screen yet :-(
I believe this has something to do with the fact that internally
plib rotates the camera matrix by a rotation of 90 degrees
about the X-axis (I don't know whether it is positive or
negative -- depends on your point of view)....read on for
more details.
> Scott McMillan wrote:
> >
> > First, it is unfortunate you use the testLoader program has
> > the example for some aspects of SGL. It illustrates a complex
> > way of doing traversals. Some of the simpler test programs
>
> Which exactly?
maybe testStatelets (was testGeoState), but it could probably
use some simplifying as well. What I gave you should be as
simple as it gets. I hope what I gave you works like I think
it should.
> > are better for this. I am enclosing changes that I have made
> > to your class (I have not compiled this b/c I don't have the
> > TuxFleet or PLIB installed)....
>
> As soon as TuxFleet works better with sgl I will give out a new release
> with some demo *.obj models and demo mission/model files for sgl.
>
> > Here are some comments:
> >
> > - In order to better help you I need to understand what the
> > member functions are supposed to do. For
> > example what does it mean to "setup the ith light", are fov's
>
> In setupLight I try to set them all to off, to switch them on back later
> in setLight ... setupLight is just an old kludge to test something.
That sglLight class should give you a good start on a replacement
for PLIB's lights. Note, that all ssgLights are infinite lights.
It does not appear that you can set the 4th component of the lights,
and they are initialized to zero.
> > in radians, are fov values half field values, how are the
>
> The FOV is given in degrees, fov_x=45 means you can see 45 degrees left
> and 45 degrees right.
That's a half field value, so in my code you would have to set an
fov_x of 90 to get this behaviour.
>
> > lights supposed to behave? etc. etc.
>
> The lights are turned on and positioned in setLight, their position is
> given in absolute coordinates, they should shine a ball of light in all
> directions.
As I said above, I believe all PLIB lights are infinite which means
the light comes in one direction from a position an infinite distance
away.
>
> > - You must make sure that a proper graphics context is current
> > when calling sgl::initialize() which means when you construct
> > this object.
>
> I should have, I'm calling that when GL is fully initialized (for plib
> I'd call ssgInit() at that time)
Okay that is right.
>
> > - Also are you driving the view postion and orientation by
> > setting the camera view matrix? That is, do you have some
> > external code that determines where you are in the 3D
> > world and then you call FleetSceneSGL::setCamera. If
>
> The camera position is given in absolute coordinates, I'm calculating
> that on my own.
>
> > this is the case, then you do not really need the zup_camera.
>
> Aah - I got confused because in the testLoaders example you were using a
> view_matrix as well a Polar-Camera.
I use the cameras in sglu as motion models that set the
appropriate GL_MODELVIEW_MATRIX when applyView is called).
Currently, SGL depends on GL's modelview matrix being set before
draw is set. This same matrix is passed into the cull function.
They are not equivalent to the ssgContext which also handles the
projection matrix.
When you call ssgCullAndDraw(root_node) in PLIB. It accesses
the current ssgContext to set the GL_PROJECTION_MATRIX, and
the GL_MODELVIEW_MATRIX. You will have to do these by explicitly
before you cull and draw an SGL scene graph.
The real pain, is that Steve Baker pre-multiplies the modelview
matrix by a rotation of 90-degrees about the x-axis. It is a
standard procedure in the vissim world, but one which I absolutely
detest.
When I was using my sgluPolarCamera_zup as the motion model, I
had to perform the following to undo everything that PLIB does
as follows:
sgMat4 view_mat;
// applies my camera's view matrix
camera->applyView();
glGetFloatv(GL_MODELVIEW_MATRIX, (float*)view_mat);
// rotate 90 degrees about the x-axis
for (int i=0; i<4; ++i)
{
float tmp = view_mat[i][1];
view_mat[i][1] = -view_mat[i][2];
view_mat[i][2] = tmp;
}
sgTransposeNegateMat4(view_mat);
context->setCamera(view_mat);
ssgCullAndDraw(root_node);
I am guessing that your view matrix is already correct for sending
into ssgContext::setCamera(...) which means you have to reverse the
operations above before sending it to SGL. Something like the
following:
// set the projection matrix here
glMatrixMode(GL_PROJECTION);
glLoadIdentity();
glFrustum(-x2, x2, -y2, y2, nr, fr); // like I mentioned last time
sgMat4 your_mat = {...};
sgTransposeNegateMat4(your_mat);
// rotate 90 degrees about the x-axis
for (int i=0; i<4; ++i)
{
float tmp = your_mat[i][2];
your_mat[i][2] = -your_mat[i][1];
your_mat[i][1] = tmp;
}
glMatrixMode(GL_MODELVIEW);
glPushMatrix();
glLoadMatrixfv((float*)your_mat);
root->cull(..., your_mat, ...);
>
> > In the code I am sending back I have removed this.
> > I also may need to know what the implied coordinate system of
> > the viewing camera is supposed to be.
>
> z shows up
> x shows right
> y shows forward
Okay this seems consistent with my experience.
> > - SGL does nothing to set up the proper viewport or GL projection
> > matrix. If you do not do this elsewhere than there need to be
> > commands in FleetSceneSGL (the sglu cameras do not do this
> > for you). I have added a call to set up the projection matrix
> > but the glViewport command is missing.
>
> I put a glViewport(0,0,640,480) in, but no change.
>
> > - SGL does not currently have support for lights in the scene.
> > If these lights need to in a constant position relative to the
> > scene (and not the viewer) then additional code is needed in
> > cullAndDraw to make sure they are positioned after the camera
> > matrix is applied. I have implemented a crude way to do this
> > in the code I am sending you, but I really don't know what the
> > proper functionality was so I made some guesses.
>
> I've got no big light-system at the moment.
>
> Currently, 1-3 lights are set up on startup on absolute positions, they
> never move or change after that.
>
> > P.S. If the intent is to not depend on any PLIB code, then the
> > interface to wrapper classes like this (and any other core code)
> > should not depend on types defined in PLIB (or SGL). That is,
>
> That's true for class FleetScene, although I'll never get rid of plib-sg
> (simple geometry math routines) in my engine/game code.
Since I have been able to mix and match SGL, SGLU, SSG, and SG code
I am no longer concerned about this.
>
> > you should not pass parameters of type sgVec4. Instead you
> > should use something more generic like float[4];
>
> I'll change that.
>
> Some comments on the files you sent me:
>
> from buildFrustum:
>
> void FleetSceneSGL::buildFrustum();
> {
> float x2 = near_clip*tan(fov_x*0.5);
> float y2;
> if (fov_y == -1.0) // square pixels
> {
> y2 = x2*(float)win_y/(float)win_x;
> }
> else
> {
> float t = near_clip*tan(fov_y*0.5);
> ^^^^^^^
> }
>
> I expect this float t should mean float y2?
replace 'float t' with 'y2' ... i.e. don't declare a new variable.
>
> void FleetSceneSGL::setupLight(int i)
> {
> // HACK only support 8 lights for now:
>
> I thought that GL can only use 8 lights at all? (GL-newbie!)
Eight lights are guaranteed to be supported at a minimum by
all OpenGL implementations. Some may support more.
I hope this helps,
scott
--
Scott McMillan Email: smc...@er...
|
