sky rendering

[alex25]

Try R1807....

nurburgring is okay, but now at imola the horizon seems to be projected upwards. if i look at the 3ds model in blender the base of the hills is at the same level as the starting point on the track but now in vdrift i can see the underneath of the horizon texture. unfortunately i don't know how the track is supposed to look like in rFactor. also, the groove fix (something about the z-offset) for nurburgring is gone from the scenegraph branch.

--alex--

[joevenzon]

Add this line to the imola track.txt:

Code:

vertical tracking skyboxes = no

That tells vdrift not to do the vertical skybox movement (so basically does the old behavior). This defaults to yes if it's not specified.

What's the groove fix?

[alex25]

Add this line to the imola track.txt:

Code:

vertical tracking skyboxes = no

That tells vdrift not to do the vertical skybox movement (so basically does the old behavior). This defaults to yes if it's not specified.

What's the groove fix?

i know about that, but then i think the horizon is too low. something is not quite right, i'll try to figure it out.

as for the groove fix, this is your posting (i can't figure out how to link to it):

alex25: that track kills my poor 7600GS's 128MB of RAM. I have to run on medium textures (the horror!). I updated SVN with a z-buffer offset to the blended objects (like the wear marks on the road) to fix the artifacts they had.

it's on the second page of this thread.

--alex--

[joevenzon]

Ah, gotcha. I've added that back into R1809 (I think). This is the trouble with re-writing the 3d engine... I forgot all of these little tweaks and quirks that need to be added! :-)

[alex25]

nurburgring is okay, but now at imola the horizon seems to be projected upwards. if i look at the 3ds model in blender the base of the hills is at the same level as the starting point on the track but now in vdrift i can see the underneath of the horizon texture.

the difference between nurburgring where the horizon moves as expected and imola (where it seems to go the worng way) is that the vertical offset is positive at nurburgring while it's negative at imola. so i think it's a sign problem with the vertical tracking of skyboxes. joe, can you check the code to see if it behaves they way it should if the vertical offset is negative? thanks.

--alex--

[alex25]

i don't really now what i am doing, so bear with me. i am trying to understand how the drawing of the sky works, so i started reading the code. in src/graphics.cpp around line 1396 we have the following code:

Code:

if (i->GetDraw()->skybox)
                        {
                                glPushMatrix();
                                double temp_matrix[16];
                                game.cam.PutTransformInto(temp_matrix);
                                glLoadMatrixd(temp_matrix);
                                if (game.track.GetVerticalTrackingSkyboxes())
                                {
                                       glTranslatef(0,game.cam.position.y,0);
                                 }
                                glMultMatrixf(i->GetMatrix4()->data);
                        }

this does the vertical tracking for the skyboxes. because i don't know what i am doing (and looking at the values of cam.position.y and object_center_y), i changed glTranslatef(0,game.cam.position.y,0) to glTranslatef(0,-objpos.y,0) where objpos is the y position of the skybox center:

Code:

VERTEX objpos(i->GetDraw()->object_center);
        objpos = i->GetDraw()->parent->TransformIntoWorldSpace(objpos);

and suddenly the horizon at imola and nurburgring and suzuka and barcelona and melbourne (and all the other rFactor based tracks i've been playing with) started getting drawn correctly (or at least what i think it should look like). the sky didn't look too good if it was just a dome (presumably because the object center was way up and the sky got pulled in) but that's a minor inconvenience (and it can be addressed by having a separate sky and horizon type). for the racer and gpl (grand prix legends that is) tracks one would need to disable vertical tracking (because the horizon in that case is a cylinder or dome encompassing the whole track of very large size).

so, based on the above, can somebody who knows more about openGL explain to me why this wouldn't be the transformation we want to apply to the horizon? thanks.

hope i made myself clear.

--alex--

[alex25]

and the obligatory pictures (from imola):

this is with the above patch applied (new vertical tracking):



this is how it looks now (with vertical tracking disabled):



and this is how it looks with the current vertical tracking enabled:



i will argue the first picture is how it should look.

--alex--

[alex25]

the correct transformation is probably:

Code:

glTranslatef(-objpos.x,-objpos.y,-objpos.z);

having thought a little bit more about this, what it does it takes the sky and moves it to the position of the camera and then it draws it. the old code would move the camera to the orgin (vertically) and then draw the sky. for this i take:

Code:

game.cam.PutTransformInto(temp_matrix);
glLoadMatrixd(temp_matrix);

to mean we initialize the gl transorm matrix to the position of the camera. correct me if i am wrong.

--alex--

[joevenzon]

It sounds like you understand it pretty well but I'll step through the code and explain it bit by bit anyway:

Code:

glPushMatrix();

This just tells OpenGL to remember the current transform matrix because we're going to want to return it to this state later on.

Code:

double temp_matrix[16];
game.cam.PutTransformInto(temp_matrix);
glLoadMatrixd(temp_matrix);

This LoadMatrix call overwrites the current transform matrix with the camera rotation (but not the camera translation).

Code:

if (game.track.GetVerticalTrackingSkyboxes())
{
     glTranslatef(0,game.cam.position.y,0);
}

If the IF is true, this adds (to the current transform) a translation up by the camera height.

Code:

glMultMatrixf(i->GetMatrix4()->data);

This adds (to the current transform) the object's transform, which is a 90 degree rotation to get the object coordinates and the opengl coordinates to line up and a translation by the object coordinates.

The upshot of all of this is that for skybox objects the scene is set up so that the camera is put at the center of the scene (0,0,0), the camera is rotated properly, if vertical skybox is true it's moved upward to its height, and the object is placed at whatever coordinates it was modeled at.

Now, as for your change to doing

Code:

glTranslatef(-objpos.x,-objpos.y,-objpos.z);

This would mean that the scene would be set up so that the camera is put at the center of the scene (0,0,0), the camera is rotated properly, and if vertical skybox is true the *center of the object* is placed at the center of the scene (0,0,0) or if it's false the object is placed at whatever coordinates it was modeled at.

It's important to note that the i->GetDraw()->object_center variable is the *calculated center* of the object's mesh, so for example if the object's mesh starts at 0 height and goes to 50, the object_center would be 25.

Anyway, if you're okay with using this translation I'll make the change and check it in (even if it does make "vertical tracking" a bit of a misnomer).

[alex25]

It's important to note that the i->GetDraw()->object_center variable is the *calculated center* of the object's mesh, so for example if the object's mesh starts at 0 height and goes to 50, the object_center would be 25.

this is the part that bugs me as well. i wish there was such a thing as an object origin to use for the transformation point. i wonder if rFactor objects (or racer) have such an origin point. i am pretty sure joe objects don't because i searched for it. in the absence of this "origin", i can see two types of sky: one you transform relative to the center (should work for most horizons and ellipsoid skies) and one you transform relative to the base (like domed skies and cylindrical skies+horizon from racer).

--alex--

[alex25]

if the horizon is made up of multiple objects, then the center of the object in the x-z plane (y is vertical) is totally wrong and the horizon ends up looking funny. i think for now the safe transformation is

Code:

glTranslatef(0.,-objpos.y,0.)

anyway, it looks like the sky and horizon objects are always centered on the origin in the x-z plane so this should be safe.

i will commit this change to svn.

--alex--

[alex25]

i will commit this change to svn.

hmm, looks like i lost my svn commit privileges...

--alex--

[joevenzon]

Since we switched SVN servers I think user accounts got lost. If you pop onto IRC thelusiv can add you, or you can reach him through this site.

this is the part that bugs me as well. i wish there was such a thing as an object origin to use for the transformation point. i wonder if rFactor objects (or racer) have such an origin point.

The origin point in .joe files is just 0,0,0. How are you getting the rfactor/racer objects into .joe format?

My guess is that in rfactor/racer they don't do the "object center" translation -- it's a bit odd. They probably either do nothing or translate up by the camera height. Do you have any way to check out pictures of imola running in racer/rfactor? I wonder what it looks like... maybe it *is* just like the middle picture you posted.

[alex25]

How are you getting the rfactor/racer objects into .joe format?

import all the rFactor objects into 3dSimEd, export them as a 3ds file, import that into blender (and fix things if needed), export it as dof objects. import the dof objects into tracked from racer, add lighting and then convert them to joe, etc. simple, isn't it?

--alex--

[alex25]

Do you have any way to check out pictures of imola running in racer/rfactor? I wonder what it looks like... maybe it *is* just like the middle picture you posted.

well, at http://www.rfactorcentral.com/detail.cfm...ola%202005 they have some track shots of imola. the second shot from the top shows the background and i tried to capture the same image in vdrift.

this is with the vertical tracking i proposed (the one that's now in svn):



and this is with no vertical tracking



i think the one with vertical tracking enabled (the top one) looks more like their image.

--alex--