Blender Importer/ Export for rFactor (1) GMT's

Traveller

Blender Importer/ Exporter for rFactor (1) GMT's

I'm pulling this out of the rFactor2 forum since it is, for the time being, designed for rFactor1.

Anyway, I'm presently working on the import side of the house, since it should be easier to know what values to work with-- and what to do with them. I've read the GMT, plugged the values into what I believe to be correct variables, and have begun to plug them into the Blender variables for work.

My overall thought is to be able to load SCN's and GMT's-- my desire to do so being one of the motivations. To that end, I've thought about assigning vertex groups for the materials. The attached image outlines what I mean. It is an extremely partial load of a track object. The name of the object comes from within the GMT file, the mesh name mimics it, and the various material vertex lists are broken out below. You will note that there is no mesh, material, normals, etc. data yet. I'm working on how to plug those values into the Blender variables.

Anyone with experience with Blender Python scripts, please feel free to respond.
 
Last edited:
Progress. Basic models loaded. Multiple GMT's can be loaded individually and will be separate objects in the Blender scene. Can be considered a test of the SCN and GEN file capability. Next up, adding textures....
 
Very impressive work! I'll be one of the first to fiddle with it when you release it.
 
I think this is great. Blender is a great 3D app and the fact that is free will much more people to get into modding.

Thanks indeed for this huge contribution to our community! :)
 
Hi, I'm new to this game. and I feel interested, as yours conversations, does it mean I can model a race car myself and import to the RFactor?
 
Last edited:
More progress. GMT's with textures, UV's etc. loaded. GMT's loaded from SCN files. I went away from GEN file support due to the LOD's in them. However, if you want to view a car, create a simple text file in Notepad, or whatever, list the GMT's you want to see, then save with a SCN file extension. The importer is no frills, in that all files need to be in the same directory/folder.

I also went away from the vertex groups, as they did not have what I was looking for. However, the empty parent object, with child material meshes does work the way I envisioned.

As you can see from the render portion of the attachment, I have to figure out how GMT file values match with Blender values for various types of textures and materials. For instance, I am currently using face.alpha in Blender for a GMT glass material. That may change, or may not. However, the exporter will look for and use the values found in Blender for the GMT values to write.
View attachment 179
 
Some time has passed because I switched gears in development.

It became apparent to me that Blender 2.49B would not be ideal because of the custom data within GMT's. I did not see an easy way to store or access that data from within Blender. There may be a way, however it is beyond my Blender Python scripting abilities at this time.

I took a look at the Blender 2.5x line and found that access to custom data-- termed Custom Properties-- is built in. You can insert, view and edit data from within the Blender interface. Inserting and accessing that data can also be done from the Python script. The data is also saved with the .blend files, so it is not lost when the session ends. To that end I started to port this over to 2.56A in late March. I thought I would be done by the first weekend in April. I was short of that estimate by about two weeks.

However, Wednesday of this week I finished the port so that I had the same level of functionality in 2.56A as I did in 2.49B-- just in time for the 2.57 release. I made the few necessary changes to get it to work in 2.57 and began to flesh out the custom properties. See attached screenshot.

Work will now progress with 2.57 and beyond, with finalizing the import script. Once that is done, I'll start on the export script. For ease of use, adding base rFactor type objects to scenes, rFactor meshes to existing objects, or rFactor properties to existing non-rFactor objects will be looked at.

I don't know how long it will take, as everything I do with this is new to me.

Oh, one big benefit of the 2.5x line is that it is a whole lot faster than 2.49B. For instance, one SCN that took around 40 seconds to load in 2.49B takes about 10 seconds in 2.57.
 
A very interesting project. Can the exporter handle vertex shading? Or if not, is it something that doesn't look too hard to implement? Another useful feature would be z-bias so that decal objects don't get involved with z fighting.
 
I say let 'em fight it out and may the better Z win, regardless of its bias.

Seriously, I'm still working on the importer. I haven't even got to the exporter yet. Let alone all of the stuff you're asking about. And my priorities may be drastically altered in about a month.
 
Work resumed on this a few weeks ago after a hiatus of a couple of months. A dictionary, if you will, of GMT material shader data is now part of the script. This allows for the correct loading of textures based on the material of the mesh-- well, correct as far as my understanding goes. The same dictionary will be a basis for the export script also-- as well as any in-Blender functions that may be added. Work on the exporter will start shortly.
 
Traveller, You are my hero!!!! I've just learned to use Blender to do some stuff in Auran's Trainz 2010 Simulator but have been a racer all my life and have a huge list of things to do in rFactor. This will be awesome!!!!

Thanks for all your efforts!
 
Wow,

native GMT support for Blender, that's the feature I've been waiting for since ages.
Can't wait to have some beta version at hands, Any progress with this project?
Thanks you so much for your efforts!

cheers,
Uwe
 
Thanks for the update! I've tried to keep with this thread, but haven't seen it for a while. I had oftened wondered what this could mean for me myself, but now that rFactor2 beta is amoung us, will it just be compatible with rF1, or is there a future look into rF2?
 
Great to see good work being done to use Blender as a modelling tool!

All the best, Uwe
 
Blender is a great product. I'm very glad someone might finally develop a GMT plugin for it. Here's rootin' for you Traveller.
 
Hey Traveller, been wondering how things have been going for you. I noticed I mentioned something about rFactor2 in my last reply on this thread, and boy, I soon realized lately that I was asking a lot of you. So, no worries about rFactor2, rFactor has a lot more life left in it. And as Prairie said, I'm rootin for you too.

Scott
 
Status:

-Import (inluding .SCN's and .GEN's): Check.
-Export: Check.
-Add base rFactor object with base material mesh to scene: Check.
-Add base material mesh to rFactor object: Check.
-Handle Flags at object, mesh, material and texture levels: Check.
-Set LOD values: Check.
-Set Origin: Check. Manual for now, some automation possible.
-Set Pivot: Check. Manual for now, some automation possible.
-Mesh export normal options-- Vertex, Face, and Up: Check.
-Vertex Color and Alpha: Check.
-Individual UV layers for each texture slot: Check.
-Materials/ Shaders "Library": Check.
-Change materials/ shaders via library: Check.
-Handle material diffuse and specular colors (Blender material values): Check.
-Handle material ambient and emissive colors: Check.
-Handle material blend information: Check.
-Handle various texture settings: Check.
-Handle texture animation sequencer: Check. Some improvement needed.
-Tangent and Bi-tangent calculations for bump/normal maps: Check.
-Overall I'd say about 95% or so complete.

To-do's in the near future:

-Improve texture animation sequencer.
-Change new texture types from procedural to file.

To-do's at some point in the future:

-Make scripts compatible with BMesh: a feature in Blender 2.63, and beyond. Blender 2.63 is due for release in April.
-Add some automation to the setting of origin and pivot points.
-Clean up my UI panels.
-Whatever else may occur to me for editing purposes.
-Documentation.
-Somehow incorporate rendering/ coupling materials to BI and/or Cycles rendering engines. Probably Cycles nodes. This is to support renders. Material nodes seem to not use custom properties, though. However, I will say that these are something I haven't delved into too deeply, i.e. something in Blender I've little experience in.

Fourteen plus months ago, I started with:

1. Having never programmed in Python before.
2. By logical extension, no experience with Blender Python API, and fairly limited knowledge of Blender.
3. Only a rough outline of the GMT format as found in the ZModeler forums.
4. Had no idea if it could be done.

Since then:

1. Learned enough of Python to be dangerous. Which seems to be my level of education in most everything.
2. Programming the Blender API, as well as digging into the Blender UI coding--which really opened things up. Also learned more about Blender itself.
3. Came across a gem of a script elsewhere in these forums, which helped to flesh out the GMT format. Though I'm not 100% sure of everything.
4. Found out it can indeed be done.
5. Had many bouts of irritation, aggravation and frustration along the way.

These scripts meet my original desire to have a Blender-only editing work-flow. They make heavy use of the Blender 2.5+ custom properties. An added benefit is that these custom properties are saved in .blend files. I've been doing some practical tests on some tracks and cars. I guess I should release those as a mod called "The Guinea Pig Cup". If I can find the files, I have some heavy duty movement of earth and asphalt for one track.

Anyway, any release will be for Blender 2.63 and beyond, as those versions will have the BMesh mesh handling system. It should be a good base for the deuce, also.

Attached is a test of a base rFactor object attached to the scene (large cube on track), and a base material mesh attached to an rFactor object (cube [scaled down] on car), with face normals exported with the cubes.
 
That's GREAT!! I cannot wait to see what all I can do! I guess now I should take the time to brush up on my Blender skills to be somewhat ready for your release. Thanks for the update!

Scott
 
I´m working on Blender to finish my works, glad to see that proyect... Thank you for your work, that's going to be superb... from blender to Rfactor... I can provide you some projects if you want to test things made by other people.

In the forum where we develop our projects one partner has taught us to use data from actual height of the national mapping to generate scenary with several square miles away in no time and with acceptable accuracy.

The process uses soft BTB and other software such as Octave, GMHS, meshlab .... and ends in Blender in my case .... I have 3DSimed and BTB so I am very interested in your work, we are many "moders" in the forum which we use Blender and this is very good news for us.

thanks
 
Hi Traveller,

since years the im-/export issue between 3dSimEd and Blender drives me nuts.
So I'm desperately waiting for an interface between Blender and SimEd without loosing the additional texture channels like with .3ds.

So pllllllleeeeaaaaaassssseee continue in your quest of creating the python script for blender.
I would be happy to do some beta testing for you in case in case you would like to have some feedback.
Pls. contact me via mail "dumeklemmer AT altbierbude.de" if you're interested to have a "busy as a bee" betatester. ;-)

cheers from Germany,
Uwe


BTW: I'm also familiar with pascal/delphi and the vcl so I can imagine how hard it is to come from delphi's perfect IDE to a script language like python.
 
This is still in work. I'm trying to incorporate the new BMesh API to speed up the export. I've run into some problems, but I'm slowly solving them.

My biggest issue coming from Pascal and its rigid types is coming to grips with the less rigid Python way of doing things. I spent over a week early in the project-- February of last year-- working through a fundamental differences between the two. Four plus nights on one, and about three nights on another. I thought "this code has to work, it should work" and it would have-- in Pascal. Anyway, live and learn and apply the knowledge when the next issue arises.

One good thing about Python being interpreted and Blender loading so fast is the short time between test runs. Especially when one is trying to find out at just what point the data disappeared. Load up the script with print statements at various spots, run Blender and look at the results. Figuring out how to keep the data from disappearing is another story. See the previous paragraph.
 
Thanks for the update, I'm looking forward to what you will come up with!

All the best,

Uwe
 
It's been a while since I checked these forums. It's very nice to see what progress you've made.
 
Nice work traveller. I have been a long time fan of Blender. I can model a car in about half the time in Blender but then have to use other programmes to skin them and export to rFactor.

Looking forward to the "finished" product!

Have you had any help from the Blender community?
 
I haven't needed help from the Blender community. I did ask about one problem I had, but I found the cause on my own and moved on.
 
Hi Traveller,

any chance to find your great efforts under my x-mas tree this year ? ;-)

cheers,
Uwe
 
I seriously doubt it. Two reasons: 1) I had a crazy idea in September to expand the scope of the job, and 2) my real life work is taking most of my energy. I've yet to get enough code written to see if my scope expansion works. Real life work will hopefully ease off by the mid-December.
 
Thanks for your ambition and all your hard work Traveller!

I've been following this thread since your first post and am quite excited to eventually see your progress on my desktop ;)

I've been a Blender user on and off for several years now and have just started dabbling in python myself. I always suspected such a thing was possible (Blender2rFactor) but knew I didn't have the technical abilities (or time) to make it happen myself. Nice to see you haven't abandoned it! Like others have said RF1 still has LOTS of life left in it! I don't think your efforts will be in vain :)
 
Here's an idea for you Jon - a very basic AIW generator. To test a track in rFactor you need a working AIW file, which has to be created using the ISI AIW editor. A while ago I did some testing and found that the bare minimum required is the centerline, pit path and the corridors. The player's garage location might help too of course.

It would compliment Traveller's efforts if we had a python script that could do that. If the track and pitlane are generated by a splines, copies of those could be converted to meshes, and then each vertices coordinates could be written to a file. That's about as far as I got when I looked into it. If you could figure out the meaning of all the values in the AIW file, you might be able to get further than that, and it would good Python practice.
 
R Soul said:
Here's an idea for you Jon - a very basic AIW generator. To test a track in rFactor you need a working AIW file, which has to be created using the ISI AIW editor. A while ago I did some testing and found that the bare minimum required is the centerline, pit path and the corridors. The player's garage location might help too of course.

It would compliment Traveller's efforts if we had a python script that could do that. If the track and pitlane are generated by a splines, copies of those could be converted to meshes, and then each vertices coordinates could be written to a file. That's about as far as I got when I looked into it. If you could figure out the meaning of all the values in the AIW file, you might be able to get further than that, and it would good Python practice.
Click to expand...

GREAT idea! I've been swamped with work between the holidays (six days a week and my day "off" is the busiest!) but would like to devote some real time in this direction maybe after the first of the year.

It's funny you mention AIW. I'm a big rally fan and having been thinking about a way to write a pacenotes generator in python... basically something that can examine a rally stage in rfactor (the AIW file?) and with the data found there place some points for pacenotes (as used by the pacenote reader plugins)... so a long story made short I'm *already* looking at the AIW files and trying to decipher the information so it may be used in a python project. Maybe kill two birds with one stone, so to speak?
 
The pace notes thing sounds like a better one to start with because I don't think there's any other tool that will do the job (whereas ISI have already made the AIW generator). You could get each waypoint and use the coordinates to generate a mesh. I can think of a semi-automatic way to continue - select a group of vertices (or the first and last), and the script uses the X difference and the Y difference to work out the radius and hence the appropriate pace note. With a group selected, it could see how the Z value changes to work out if there's a hump.

For full automation maybe it could select 10 or 20 vertices and do the same as above. It might miss things or generate two corner notes for a long turn, but it would be a start...
 
I started this mostly-off sometimes on-project two years ago today. Let's see, now...

Last Summer was the start of the beta that is not a beta. This was for rFactor 1. As a result, a few features beyond just import/export are in place. These being adding a rF1 object to the scene, adding an rF1 mesh to an existing object and adding a rF1 material to an existing mesh.

I started work on rF2 in the spring of last year. Early September saw both sets of scripts at about the same level of functionality. At that point I decided to merge both scripts into one. For various reasons, I did not work on that until Christmas/ New Year's break. The merged scripts are where I am at now. rF1 is slightly better off than rF2, though both are lacking in some areas.

The future will hopefully result in those areas no longer lacking. Also, Blender 2.66 or 2.67 may bring custom properties to the nodes-- the pynode project. If I don't misunderstand things, this will allow the complete use of the Cycles rendering engine-- currently the custom properties for textures are not accessible in Cycles.

The stuff I'm lacking involves flags, material settings and texture settings. I'm probably 90% on rF1 and 60% on rF2. Oh, yeah, and a good script to hunt for the files in a typical rF1 or rF2 directory structure-- right now everything has to be in one folder. In addition to bugs.
 
THANKS for the update, Traveller! And, HAPPY 2nd Year anniversary to you and the project! I've been getting my feet wet in another program, but still waiting to see your outcome when it gets ready to be released. I'm not sure if it's been mentioned, but do you plan on releasing it as Freeware or Payware at this point in time, if you don't mind my asking? Just wanting a heads up for when it's released so I can plan saving now if it goes payware.

Scott
 
Last edited:
You must log in or register to reply here.

Back
Top