sky rendering

[joevenzon]

Hmm, well in their screenshot the trees occasionally rise above the background, but in general, you're right. Hmmmm. I wonder if they're using a zoom lens style FOV, though, and positioning the camera back further... which would make the background appear larger in their screenshot. That would explain why that beige building looks so large in their screenshot and so tiny in vdrift.

Also, you might want to turn on mipmapping for the trees.

[joevenzon]

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?

You could just export the track to .joe format once you get it into blender. The extra step of exporting as dof and editing them in tracked is pretty unnecessary -- no lighting from that step will get exported to .joe (VDrift calculates lighting in real-time).

[alex25]

You could just export the track to .joe format once you get it into blender. The extra step of exporting as dof and editing them in tracked is pretty unnecessary

except that exporting directly to joe format never quite works. trying to export imola directly to joe i get (after a while):

Code:

found default filename from GUI
Traceback (most recent call last):
  File "export-all-joe-0.3.py", line 691, in bevent
    save_joe(g_filename.val + "-object-" + nextObject.name + ".joe", nextObject)
  File "export-all-joe-0.3.py", line 525, in save_joe
    joe.save(file)
  File "export-all-joe-0.3.py", line 216, in save
    self.frames[i].save(file)
  File "export-all-joe-0.3.py", line 180, in save
    self.texcoords[i].save(file)
  File "export-all-joe-0.3.py", line 145, in save
    data=struct.pack(self.binary_format, temp_data[0], temp_data[1])
SystemError: frexp() result out of range

and i end up with an empty object. exporting to dof works just fine. this is with blender 2.44.

--alex--

[alex25]

r1819: Set track to default to no vertical skyboxes

broke vertical skybox tracking since GetParam() doesn't know what to do with "vertical tracking skyboxes" and always returns false.

--alex--

[joevenzon]

broke vertical skybox tracking since GetParam() doesn't know what to do with "vertical tracking skyboxes" and always returns false.

No, GetParam() returns whatever is set in the track.txt file. If there's nothing in there, it defaults to false. On Imola this returns true, since it's turned on in the track.txt file. You can put in a cout to see for yourself, if you want. :-) I did find a bug that was causing the old value to stick on if you loaded multiple tracks in a row, though -- that's fixed in R1822. Can you see if R1822 behaves as you expect? At this point it behaves as I expect, but we may have differing expectations!

[joevenzon]

except that exporting directly to joe format never quite works. trying to export imola directly to joe i get (after a while):

Code:

found default filename from GUI
Traceback (most recent call last):
  File "export-all-joe-0.3.py", line 691, in bevent
    save_joe(g_filename.val + "-object-" + nextObject.name + ".joe", nextObject)
  File "export-all-joe-0.3.py", line 525, in save_joe
    joe.save(file)
  File "export-all-joe-0.3.py", line 216, in save
    self.frames[i].save(file)
  File "export-all-joe-0.3.py", line 180, in save
    self.texcoords[i].save(file)
  File "export-all-joe-0.3.py", line 145, in save
    data=struct.pack(self.binary_format, temp_data[0], temp_data[1])
SystemError: frexp() result out of range

and i end up with an empty object. exporting to dof works just fine. this is with blender 2.44.

Hmm, then we should fix the exporter! The error is happening when it's writing the UV coordinates. According to this:
http://mail.python.org/pipermail/python-...86515.html
that error usually happens when the value is much too big, much too small, or Not A Number. I've added checks for this into the export-all script. It's in the VDrift art repository, R90.

[alex25]

No, GetParam() returns whatever is set in the track.txt file. If there's nothing in there, it defaults to false. On Imola this returns true, since it's turned on in the track.txt file. You can put in a cout to see for yourself, if you want. :-) I did find a bug that was causing the old value to stick on if you loaded multiple tracks in a row, though -- that's fixed in R1822. Can you see if R1822 behaves as you expect? At this point it behaves as I expect, but we may have differing expectations!

r1822 seems to work fine. when i was testing before, i was loading multiple tracks in a row so that might explain why i though vertical tracking stopped working.

--alex--

[joevenzon]

Alright, sounds good. Since I changed the default some tracks (that didn't need to before) may need to specify vertical tracking skyboxes on.

[alex25]

Hmm, then we should fix the exporter!

okay, so that error seems to be fixed, i can export imola and it looks good (although i didn't do an exhaustive comparison with the old method). but now if i try to export suzuka using the joe export script, i get:

Code:

Traceback (most recent call last):
  File "export-all-joe-0.3.py", line 695, in bevent
    listfile.write(os.path.basename(nextObject.getData().faces[0].image.getFilename())+"\n")
AttributeError: 'NoneType' object has no attribute 'getFilename'

one of these days maybe i'll learn python.

--alex--

[alex25]

no lighting from that step will get exported to .joe (VDrift calculates lighting in real-time).

this statement is not quite true: there is lighting information exported but vdrift is probably not using it. on the other hand, the trackeditor is using this information and if i don't add it in racer before converting the dof files to joe, then the objects are very dark in the trackeditor and it's almost impossible to do any track editing. maybe the track editor needs to be updated as well.

--alex--

[joevenzon]

If I recall correctly, the .dof format doesn't have surface normals (which are what lighting is calculated with in VDrift), but it bakes lighting into the mesh by adjusting the vertex color. This is a crappy way to do it and so the dof2joe converter discards the vertex color info (the .joe format doesn't even store it) and generates normals using a simple "solid shading" type algorithm. If you export directly from blender, then whatever the normals are in blender will be written to the .joe files. If you want to force the same sort of normals, you should be able to select everything in blender and go into edit mode and hit the "Set Solid" button. Also, make sure you have "double sided" turned off in blender, as that seems to make the normals a bit nuts sometimes.

[alex25]

If I recall correctly, the .dof format doesn't have surface normals (which are what lighting is calculated with in VDrift), but it bakes lighting into the mesh by adjusting the vertex color. This is a crappy way to do it and so the dof2joe converter discards the vertex color info

i am not an expert on the "joe" format (you should be) but as i said in my previous message, if i don't add lighting in racer the converted objects look very dark in the track editor. if i do, then they look okay and i can trace the track. clearly there is some information that's being added/saved there.

--alex--

[joevenzon]

I looked into this more, and the racer dof format can also store normals (although it doesn't always) -- my mistake. As for the .joe format, it only stores normals (not vertex color), and will generate normals if they aren't in the dof file (which they aren't for some tracks' .dof files). However, all of this should be moot as the normals get written from blender by the joe exporter. It sounds like the normals aren't set up properly in blender, and the racer track editor is fixing it. I can offer some suggestions about how to make sure the normals are correct in blender: select all objects (A), open the editing panel (F9), make sure the mesh is not double sided (in the Mesh box), then hit "Set Solid" (in the Link and Materials box). Have you tried this already? If so, could you send me the blender file (maybe delete most of the objects first so it's not huge)?

[alex25]

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.

i think i finally figured out how the sky rendering works in rFactor. looks like they can specify the position of the sky objects which then helps position the objects properly.

i propose we do something similar. probably the best place to do this is in track.txt. if an objects is flagged as a skybox then one would look for the corresponding position in track.txt. for example, let's take imola. the rFactor specifies the following:

Code:

MeshFile=skyboxi.gmt {Pos=(0.0,-27.0,0.0)}
MeshFile=Sky.gmt {Pos=(0.0,-7.0,0.0)}

the equivalent in track.txt would be:

Code:

spea0349_bka.dof-00 position: 0.0 -27.0 0.0
skyb0348_sky.dof-00 position: 0.0 -7.0 0.0

this could get a bit more complicated because in some cases the horizon object gets broken into multiple objects. this leads me to a second option where we would extend the skybox flag to mean 1 for the horizon and 2 for the sky. in this case track.txt would look like:

Code:

horizon position: 0.0 -27.0 0.0
sky position: 0.0 -7.0 0.0

personally i would go with this second option, and if we agree on it i could probably come up with a patch (and fix all the tracks as well). let me know what you think.

--alex--

[joevenzon]

A third option would be to include position offset as 3 additional parameters per object in the objects/list.txt file. A long time ago there was a position offset but I removed it since it didn't seem that useful.

A fourth option would be to simply go into blender (or whatever modeling program you want to use) and move the objects around by those units.

I like the fourth option... having position offset data anywhere else but inside the model is redundant, and it'd require no change to the source. Is there any reason why this wouldn't work?