Forums

Full Version: sky rendering
You're currently viewing a stripped down version of our content. View the full version with proper formatting.
Pages: 1 2 3 4 5 6 7
while playing with yet another track conversion, i discovered something i find interesting about the way vdrift renders the sky (horizon in particular). it looks like (and i haven't looked at the code yet) the horizon model gets projected outward from the origin. now, this this doen't really make any difference when the track is placed near the origin, but when the track is offset from origin by a large amount you end up with the horizon being projected way up in the sky. for this particular track i ended up centering the horizon on the origin and then it rendered fine but i was wondering how hard it would be to implement projecting the horizon outward (perpendicular that is). i guess that would imply the need to do some kind of offset translation for the model and then project it.

another area where vdrift lags behind the other simulators when rendering the horizon is the relative flag. basically, instead of projecting the horizon on the sky, we can mark it as relative to the viewpoint position. how hard would it be to implement this? i think this would also improve the frame rate, as the objects behind the horizon won't get rendered and then we'll also gain the ability to simulate various visibility conditions (or rainy days the clouds/horizon are closed in, sunny days are spaced out).

the track in question is racer nurburgring (http://www.rfactorcentral.com/detail.cfm...rdschleife) i will probably not check it in for the time being (we already have a version and for this one we'll probably need to get permission to convert it) but i want to play with it for a while as it is a lot more realistic. if only rfactor would work under wine.

--alex--
Quote:it looks like (and i haven't looked at the code yet) the horizon model gets projected outward from the origin

Quote:instead of projecting the horizon on the sky, we can mark it as relative to the viewpoint position. how hard would it be to implement this?

I don't quite follow what you mean by these statements... but I'll try to explain how the sky and horizon are rendered in VDrift.

First of all, any objects not marked as "skybox" get rendered at the origin. Originally there was a way to add a fixed offset, but that's not really supported anymore. All positioning data is stored in the coordinates of the objects themselves. Let's walk through an example. A vertex at 100,0,0 with the camera at 90,0,0 is drawn at the (zero offset) origin 0,0,0 plus the vertex coordinate 100,0,0 minus the camera position 90,0,0 equals 10,0,0. Take a second to look that over... it makes sense, because it means that when the camera is close to an object, the object looks closer.

Second, all objects marked as "skybox" get rendered at the origin (like above) but do not take into account the camera position. This means that a vertex at 100,0,0 with the camera at 90,0,0 is drawn at 0,0,0 plus vertex coordinate 100,0,0 equals 100,0,0. This makes sense, because it means that no matter how far you drive, the sky still looks like it's the same distance away.

Note that for simplicity I ignored the camera rotation in the examples above (so basically the camera is facing exactly forward).

VDrift used to allow you to mark objects as skybox and full bright separately, so you could have a skybox that is lit normally (blech) or a normal object that has no lighting and is always bright. I took that feature away thinking no one wanted it and now assume that all skyboxes are fully lit and everything that isn't a skybox is lit. If you want me to go back to the old system of allowing separate flags, let me know.

In fact, all of this code is pretty easy to change, so if it makes your life easier, let me know what you want and I'll set it up.
joevenzon Wrote:I don't quite follow what you mean by these statements... but I'll try to explain how the sky and horizon are rendered in VDrift.
i'll take some pictures tomorrow to show you. in the meantime i'll try to find some time to actually look at the render code.

--alex--
joevenzon Wrote:I don't quite follow what you mean by these statements...

i tried to make a schematic representation of what i think is happening when rendering the sky

[Image: track.jpg]

in red is the track, blue is the original horizon, which intersects the track. we make the horizon of type sky but instead of being projected onto the sky dome outward (along the black arrows) it is projected from the origin and ends up as the green box. when you sit on the track in vdrift you'll see the horizon drawn way up in the sky.

if the track was at zero on the vertical axis, then the projetion onto the sky dome will happen pretty much along the black arrows (outward) and the horizon would look normal.

i hope this helps explain what i was trying to say.

--alex--
So, for this track, the sky renders correctly when marked as a skybox but the horizon looks like it's up in the air when marked as a skybox. And I assume if you don't mark the horizon as a skybox, then it's drawn in the correct place but is a normal object so it's intersecting the track at some point (based on your drawing). Is that all correct?
Based on the above, I made it so objects marked skybox track the camera's y (vertical) offset, checked in SVN R1554. Let me know if this fixes the problem for your horizon, or makes the horizon go even further into the sky (in which case I need to flip the sign). Also, note that this change applies to all skybox objects, so it may mess up the sky on some tracks. If anyone notices that this happens, I can make a separate "horizon" parameter so the old method is used for the sky.
joevenzon Wrote:So, for this track, the sky renders correctly when marked as a skybox but the horizon looks like it's up in the air when marked as a skybox. And I assume if you don't mark the horizon as a skybox, then it's drawn in the correct place but is a normal object so it's intersecting the track at some point (based on your drawing). Is that all correct?
i didn't try it with the sky but for a lot of rFactor tracks the sky is a bubble so it might not show up.

--alex--
joevenzon Wrote:Based on the above, I made it so objects marked skybox track the camera's y (vertical) offset, checked in SVN R1554.
wouldn't it be better just to change the viewpoint from the origin to the center of the horizon and then project it? that way the horizon won't change as the car goes up and down on the track. anyway i'll take a look at your changes and i'll try to play with them.

--alex--
alex25 Wrote:wouldn't it be better just to change the viewpoint from the origin to the center of the horizon and then project it?

this idea would only work if we had a horizon type object. actually i think it would be better to have a relative flag so the horizon is drawn relative to the camera (instead of being projected onto the sky dome).

--alex--
joevenzon Wrote:Let me know if this fixes the problem for your horizon, or makes the horizon go even further into the sky (in which case I need to flip the sign). Also, note that this change applies to all skybox objects, so it may mess up the sky on some tracks. If anyone notices that this happens, I can make a separate "horizon" parameter so the old method is used for the sky.

i've tested it with the nurburgring track i am working on and the horizon now gets drawn properly. much better. now that i know where this is being done in the code i am going to take a stab at playing with drawing the sky relative to the viewpoint.

--alex--
and a few screenshots:

[Image: nring1.png]
[Image: nring2.png]
[Image: nring3.png]
[Image: nring4.png]
[Image: nring5.png]

--alex--
Wow, that Nordschleife track is gorgeous, it's so much better looking than our old one. I can't wait til you get it finished! It even has the graffiti on the track...wonderful! Big Grin Big Grin

By the way, was this conversion from a Racer track, or something else? I noticed you mentioned rFactor tracks somewhere, have you been able to import tracks from there?
thelusiv Wrote:By the way, was this conversion from a Racer track, or something else? I noticed you mentioned rFactor tracks somewhere, have you been able to import tracks from there?

it's an rFactor conversion. i ended up buyng 3DSimED (which is not a converter, as they say on their web page) so now i can import tracks from almost all the simulators (rFactor, GTL, GTR, GPL etc.). then i export the tracks to 3ds, load them into blender, fix up a few things here and there. save them as dof's, import them into racer's tracked to add lighting, convert them to vdrift format. i have a lot of unfinished tracks on my computer mostly because i can't decide which version i like better. also, there is the issue of rendering the sky. all the other simulators render the sky as relative to the camera view (so it moves with the car as you drive around the track) and our way of rendering the sky doesn't make it look too good. i tried to changed the drawing code in objects.cpp but i couldn't get the horizon to move around.

--alex--
So, what are the licensing implications (if any) using this data? Sorry I'm not very familiar with the licenses used by rFactor, or the attitude of the developers towards this sort of thing.
alex: any objects you tag as skybox are drawn relative to the camera view (so it moves with the car as you drive around the track). I don't understand why you think this isn't the case, and you now have me very confused, because I thought I had figured out what you were saying. Until I understand you better I'm going to switch the skybox rendering back to the old method. Try to catch me on IRC....
Pages: 1 2 3 4 5 6 7