surfaces.txt

[alex25]

i figured out how to use the properties. when creating the mesh one needs to add mesh.properties['name']=name and then on export you can access the original name = mesh.properties['name'] which is the original name of the joe object. i'll post a diff soon.

--alex--

[alex25]

i just committed the changes to svn (revision 155). it would be nice if export-joe.py script will just save the joe object in the current working directory with the name it got from mesh properties instead of prompting for a name (i guess prompt if the mesh property joename is empty).

--alex--

[NaN]

The mesh, texture names are already stored in object properties (addProperty, getProperty). This allows to modify them in blender (logic panel).

But it also makes new object creation error prone. The user has to make sure that the properties are set (use an existing object as template?).

[alex25]

i'm not sure i understand this. all i did was store the original joe file name in the mesh properties (to get around the 21 character limit for object names in blender). now when i export the blender object it uses this name to save the file (thus making sure the saved object has the same name as the original joe object). if the joename property is not set (i.e for a new object) then we should save the object to the blender name + joe extension. i used these changes to fix normals for the spa2008 textures and it worked very well (previously i had to figure out which blender object name corresponded to the original joe file name and it could get very tedious if blender changed the object name because it was too long). what's now in svn is probably more of a proof of concept and it should be made more robust.

and speaking of the scripts, there seems to be a bug somewhere when creating the uv mappings. for some faces the uv map gets rotated but i don't really know why. looks like i can fix it in blender before exporting but it will be nice if this didn't happen in the first place. i can provide you with an example if you want.

--alex--

[alex25]

track_verge19mergepart3.dof-00.joe from spa2008 is an object with a face that has a rotated uv-mapping (the object look right in vdrift but not when imported it in blender).

[NaN]

The mesh creation looks like(simplifed):

Code:

mesh = Blender.Mesh.New()

mesh.verts.extend([Vector(v.co) for v in self.verts])

mesh.faces.extend([f.vertex_index for f in self.faces])

for i in range(len(mesh.faces)):
    ti = self.faces[i].texture_index
    uv = [Vector(self.texcoords[ti[0]].uv()), Vector(self.texcoords[ti[1]].uv()), Vector(self.texcoords[ti[2]].uv())]
    mesh.faces[i].uv = uv

I have no idea what could go wrong here. But there are still broken uv faces.

[/list]

[thelusiv]

NaN, I've looked at your new Blender scripts. Are these the latest versions? They look very good.

The biggest thing for which the old trackeditor must still be used, it seems, is to create roads.trk if you don't have one to import.

I'm thinking about writing a graphical interface for all these scripts using the Blender Draw module:
http://www.blender.org/documentation/249...odule.html

What kind of features would be good? Here are some I've thought of...

• set attributes about the track:
  
  • output directory
    
  • name
    
  • author
    
  • license
    
  • ...
• provide a set of different object profiles, which can be applied to objects to auto-fill the property values (does Blender already have this? all I can find is Object -> Copy Attributes -> Properties...)
  
  • grass
    
  • concrete
    
  • sand
    
  • skybox
    
  • ...
• save all these track attributes and object profiles with the .blend file (in the .blend file?)
  
• choose which mesh is the track
  
• setup objects that are not exported but used as starting points
  
• specify some vertices as the starting line
  
• an "Export Track" button that creates objects.jpk, list.txt, roads.trk, track.txt, surfaces.txt, copies all graphics, and everything else which needs to be done, to get a track into VDrift
  

[NaN]

What kind of features would be good?

I've planned to rewrite the track description format. To allow mesh instances(position orientation) and dynamic track objects(physics) and other stuff. I am a bit stuck on the object instances detection script. And the face indices bug hit by Alex is another show stopper.

It looks like blender is changing the face indices ordering for whatever reason. :x

track_verge19mergepart3.dof-00.joe original:

Code:

[0, 1, 2]
[0, 2, 5]
[6, 7, 8]
[5, 2, 11]
[10, 1, 0]
[10, 9, 1]
[4, 9, 10]
[4, 3, 9]
[8, 3, 4]
[8, 7, 3]

track_verge19mergepart3.dof-00.joe as mesh:

Code:

[MFace (0 1 2) 0]
[MFace (0 2 5) 1]
[MFace (6 7 8) 2]
[MFace (5 2 11) 3]
[MFace (1 0 10) 4]
[MFace (10 9 1) 5]
[MFace (4 9 10) 6]
[MFace (4 3 9) 7]
[MFace (8 3 4) 8]
[MFace (8 7 3) 9]

Compare the fifth face.

[alex25]

It looks like blender is changing the face indices ordering for whatever reason. :x

i don't understand what's going on either. i've been fixing a lot of these faces in blender and then they look right in both blender and vdrift. vdrift must be doing something extra to display them right in the first place (or maybe blender is doing something extra that vdrift ignores resulting in the faces being rotated. it's interesting to note that they are always rotated 90 degrees sometimes clockwise, sometimes anti-clockwise).

--alex--

[thelusiv]

I've planned to rewrite the track description format. To allow mesh instances(position orientation) and dynamic track objects(physics) and other stuff. I am a bit stuck on the object instances detection script. And the face indices bug hit by Alex is another show stopper.

Well, I am going to work on something regardless...whenever the new format is ready, it should be fairly simple to update such a script (it will probably just call functions in vdrift.py anyway). I am working on a project that pretty badly needs these capabilities now...

[portets]

will the import/export scripts work with blender 2.5? and are there any new features in 2.5 that the scripts could take advantage of? 2.5 is going to be a major release.

i figure this question isn't deserving of a new topic

[NaN]

Code:

will the import/export scripts work with blender 2.5

Not until someone rewrites them. They've changed a lot of things in 2.5. I think the whole GUI and all operations(actions) are scriptable now. But the python API is quite unstable atm. They have been renaming a lot on the python side recently. I'd wait untill a stable release is out.

The 21 character limit for names is still there

[thelusiv]

I'm definitely not developing anything for 2.5x until it is stable...I have 2.49.2 installed and am developing for that.

Are the friction coefficient settings in track.txt still used, or does that always come from surfaces.txt now?

[NaN]

Are the friction coefficient settings in track.txt still used,

Only if you want to stay compatible to the pre-surfaces.txt releases.

[NaN]

I've been able to partially fix the uv problem remapping the uv cooords. But there is another serious issue. Some of the models contain "face permutations", means the same face [1, 5, 6] as [5, 1, 6]. Blender will skip them(will see them as the same face breaking the uv coords). The crane_crane.. models for example are losing 21 faces on import.