To speed up the process of exporting tracks from rFactor and Bob's Track Builder to KRP I've written a set of tools that almost entirely automate the process. I'll be sharing these tools here and on GitHub if anybody is interested.
However, for now the tools still have a dependence on 3DS Max being installed on the user's machine. I could get round this requirement (and eventually past the entire 3DS file format entirely) if I had knowledge of the file format / specification for KRPs binary-based track files.
If anybody could supply me with information about the structure of the KRP track files I would hugely appreciate it! Also, if anybody happens to have similar information regarding rFactor's GMT file format that would be helpful too.
Thanks!
Chris
I can't help you with the information on your project, but this is music to my ears I'll be able to create so many tracks it's ridiculous once this happens, I already have 10 waiting on conversion...
i would help you and i think i could but i dont understand your text.. i am running out of my english know-how.
Quote from: LauZzZn on September 12, 2013, 01:25:29 PM
i would help you and i think i could but i dont understand your text.. i am running out of my english know-how.
Sorry! I'll try give more details with an example:
Each track on KRP has its own folder (or .pkz file), which contains the following files:
- mesh (.edf): Skydome files.
- map (.map): Describes track geometry, textures and lighting.
- collision (.trp): Holds collision data for the track.
I'd like to know how each of these file types are encoded (i.e. The first 4 bytes are the name of the object).
okay then i cant help.. sorry :/
This is not the way.
You should make easier the conversion from multimaterial to standard material. Now it has to be done manually and it takes hours (there are 50-200 materials)
But there are problems which I don't think they can be done easily: You have to select track parts and rename them. But how are you going to do? Is your program able to know what is asphalt, what is ground, what is a tyre, etc?
Quote from: Aritz on September 12, 2013, 07:34:39 PM
This is not the way.
You should make easier the conversion from multimaterial to standard material. Now it has to be done manually and it takes hours (there are 50-200 materials)
But there are problems which I don't think they can be done easily: You have to select track parts and rename them. But how are you going to do? Is your program able to know what is asphalt, what is ground, what is a tyre, etc?
if you use 3ds to convert then i think the only problem for me are the textures. renaming is easy and only takes half hour and for finetung one more half hour. guess thats not the problem
Quote from: Aritz on September 12, 2013, 07:34:39 PM
This is not the way.
You should make easier the conversion from multimaterial to standard material. Now it has to be done manually and it takes hours (there are 50-200 materials)
But there are problems which I don't think they can be done easily: You have to select track parts and rename them. But how are you going to do? Is your program able to know what is asphalt, what is ground, what is a tyre, etc?
Well, usually your track parts follow a naming convention in rFactor; failing that you can use a simple neural network or bayesian classifier to discern between texture groups also. The plan is on having the program present each texture to you (along with its name) and you select which group it belongs to from a set of options below (with the ability to have the computer predict the majority of the textures and make use of user input to correct and retrain the classifier).
I am not an rFactor track builder but I saw a few and they are not using the same format as KRP needs. Track is divided by parts, which have the different surfaces mixed (at least the names). So you have 20 pieces of the track and each part has 3 different surfaces BUT they are called road19 and they are 1 object, no asphalt19 + kerb19 + grass19. As you say, the only way to divide those roadXX objects in smaller pieces is using their texture.
If you solve this, your converter program should be a good program :)
Quote from: ChrisTimps on September 12, 2013, 12:16:24 PM
To speed up the process of exporting tracks from rFactor and Bob's Track Builder to KRP I've written a set of tools that almost entirely automate the process. I'll be sharing these tools here and on GitHub if anybody is interested.
However, for now the tools still have a dependence on 3DS Max being installed on the user's machine. I could get round this requirement (and eventually past the entire 3DS file format entirely) if I had knowledge of the file format / specification for KRPs binary-based track files.
If anybody could supply me with information about the structure of the KRP track files I would hugely appreciate it! Also, if anybody happens to have similar information regarding rFactor's GMT file format that would be helpful too.
Thanks!
Chris
A command line FBX exporter is in progress.
If you can save to FBX format, that should help the conversion process.
Quote from: PiBoSo on September 16, 2013, 06:41:48 PM
A command line FBX exporter is in progress.
If you can save to FBX format, that should help the conversion process.
Awesome! That shouldn't be a problem :)
Any progress on this? A BTB straight to KRP exporter would be amazing!
Quote from: DjFIL on October 21, 2013, 06:20:48 AM
Any progress on this? A BTB straight to KRP exporter would be amazing!
+1
Quote from: DjFIL on October 21, 2013, 06:20:48 AM
Any progress on this? A BTB straight to KRP exporter would be amazing!
:o Yea and 1 out of every 50 tracks released would be worth having then, like Rfactor.
Quote from: mattrix_6996 on October 22, 2013, 12:21:16 AM
Quote from: DjFIL on October 21, 2013, 06:20:48 AM
Any progress on this? A BTB straight to KRP exporter would be amazing!
:o Yea and 1 out of every 50 tracks released would be worth having then, like Rfactor.
Lol... yes this is always a problem. If we had a good database of tracks, where users could vote for their favorites (like rFactor central) that would help filter the good and bad creations. But anything to make it easier for the average guy to create/convert tracks to KRP, that's good news... and less "will you make\convert that track for me".
Quote from: DjFIL on October 22, 2013, 02:22:39 AM
Quote from: mattrix_6996 on October 22, 2013, 12:21:16 AM
Quote from: DjFIL on October 21, 2013, 06:20:48 AM
Any progress on this? A BTB straight to KRP exporter would be amazing!
:o Yea and 1 out of every 50 tracks released would be worth having then, like Rfactor.
Lol... yes this is always a problem. If we had a good database of tracks, where users could vote for their favorites (like rFactor central) that would help filter the good and bad creations. But anything to make it easier for the average guy to create/convert tracks to KRP, that's good news... and less "will you make\convert that track for me".
But it is the Converting boundary keeping only worth having tracks in KRP.
that may be true in a lot of cases, but I on the other hand have a lot of very good tracks that need conversion but no one has the time to convert them, and I don't know how the process confuses me...
some news on this? that would really help me
Any news on this?
Quote from: DjFIL on October 21, 2013, 06:20:48 AM
Any progress on this? A BTB straight to KRP exporter would be amazing!
+1
Hey guys, been really busy starting my PhD these past few weeks. Should have a chunk of spare time next weekend to get this finished! Sorry for the delay :(