[WIP] rFactor Import/Export Scripts for Blender

I am wondering why for example with real road shader two diff maps SEVEN UV channels are added ? In rF2_tracktechnology.pdf which I use it is showed that seven stages of textures are sharing three channels.

Then similar thing is with multi layer grass shader, six UV channels are added, but in rF2_terrain_shader.pdf it is showed that shader is using four UV channels.

@Traveller Why there is UV channel made for each texture stage ? Also in Blender _rfactor_IO.pdf in page 33 it is written that there will be from one to four UV layers, which seems not to be so. Also it is written not to rename or delete the layers.
 
Why are there four? The scripts originally were for rF1, which had up to four textures. rF2 has expanded and changed that. rF2 keeps changing. I haven't updated the documentation in years.

Why not rename, delete, etc.? The scripts are designed to be self-contained, with no outside program. You change things within Blender, you run the risk of breaking the scripts. I found that out myself. I then expanded the scripts to handle additional functions.

Why additional UV channels? The latter are just copies of previous channels, based on my interpretation of the ISI/S397 documents. I could be wrong. See below. I add them for display purposes. I change the earlier ones. Those earlier UV's are copied to the latter on export and import.

My scripts are based on my understanding of Python, Blender and its API, and rFx GMT's. I'm learning Python, the inner workings of Blender, Blender itself, and GMT's as I go. rF2 is changing. Blender and its API are as well, if I move to 2.80 (which is the plan). I've asked for help before, and have received very little, in the the grand scheme of things, in the almost eight years they've been around. Though I am thankful for the help I did receive. Some folks on Discord have expressed interest to help. I'll probably hit them up before the end of the year because...

My work comes first. It provides me what I need to allow play. In addition to it being what I am paid to do. A three to four month stretch of heavy work that started in March 2016 has stretched into almost three years. I have to take off from work here at the end of this year because of work rules. However, it will pick right back up in January when I go back. I'm hoping it will finally calm down around June of next year. Work on the scripts has been extremely light during this period, as my work is mentally draining. I'm hoping for some progress with them during the rest of this year.
 
Good luck to you, Traveller. I think that rF2 might pick up soon, and become more popular as it deserves, and more modders might get attracted so perhaps more capable people will come to help you. I think that add-on is decent already and I think it will get used a lot.

So far I am continuously having better and better results with model and last time I launched my track in Dev Mode I was happy, for now at least I am only using your add-on to create .fbx to open with gJed. I have yet to try what dxp_rlong has suggested, to export .gmt instead of .fbx to open with gJed, then skipping gJed completely seems a bit much to me at the moment.

At this stage which I am, only UV's seems to be a problem, but I can have compromises with them for a while. I can already see that rF2 tracks can be made to be really nice. For example I love how much control there is over colors with ambient, diffuse, specular and emissive colors... and so much more things to name which I should do.

I understand that it is hard when rF2 is changing a lot, for example I understand that there might be problems with gJed too, as it is not included into rF2 at the moment (I suppose not supporting DX11 is not the only problem), also new materials are announced so yeah... changes, changes. But I think it is very worth the work because there are many blender artists, and rF2 is getting very attractive.
 
Traveller said:
Why are there four? The scripts originally were for rF1, which had up to four textures. rF2 has expanded and changed that. rF2 keeps changing. I haven't updated the documentation in years.

Why additional UV channels? The latter are just copies of previous channels, based on my interpretation of the ISI/S397 documents. I could be wrong. See below. I add them for display purposes. I change the earlier ones. Those earlier UV's are copied to the latter on export and import.
Click to expand...

Wow, I really thought that they were originally for rF2, it makes sense now about whats written in documentation there.

I would like to understand better how it is about UV's.

First of all, I wonder which are early Uv's, and which are latter ? Also do I understand correctly that latter UV channels mustn't be edited, because they will get overwritten anyway ?

8lEhjY8.jpg

sTmYo0u.jpg


So UV maps list nicely matches textures stage sequence. But Map channels are only meant to be three in the shader and their sequence is very mixed. Am I right to guess that early UV's are Diffuse #1; #2; #3 UV Layers ? It still doesn't make sense because I have problems with 2nd UV channel be taken as 1st. So my multimap, specular map, marbles seems to be actually using 1st channel. Hard to tell about racegroove map, but it also seems to be using first channel. As for reflection map, I read that it doesn't matter what UV and texture it uses as it is live mapped.

Then Multilayer shader.
g0yNCi2.jpg

h8BePJ5.jpg


It seems that 1st and 4th channels are working alright. And my guess is that second channel gets using first and 3rd gets to use 4th. But I am not entirelly sure.

For this shader I suppose UV layers for Normal maps are "latter" ones for display ?
 
As for UV channels in Traveller's scripts, what I do is create UV map 1 in the first channel that uses UV map 1 and then copy and paste the UVs into the other UV channels that are using UV map 1. Same for UV map 2: build UV map 2 in the first channel using UV map 2, then copy/paste into any other UV channels that are using UV map 2. Same for UV map 3, and UV map 4 (if it is present).

To me it is a way to visually see what UV map is assigned to a given texture slot. As Traveller mentioned, the map assignments are then correctly assoicated on GMT export.

The use of the scripts' rF_Object with FBX export has always been a problem for me. It may stem from the way I build my meshes, not sure. But when I built rF2 objects using the scripts and then wanted to export to FBX, I found I had to duplicate the rF_Object and restructure the copy into a more FBX friendly structure. It has been a long time since attempting to export FBX, so I can't remember exactly what the issues were. These are the type of issues that drove me to abandon the FBX to gJED workflow and go with the GMT to gJED sequence.

Once you feel like you know how to deal with the UVs, you will want to start using the more recent Real Road Shader. It is very much like the one you are working with now, but there are enhancements that resolve some limits the original Realroad shader has. The differences are noted in this forum thread:

https://forum.studio-397.com/index.php?threads/rf2-track-design-changes-to-real-road-shader.38905/
 
Thank you :)

Looks like I am inevitably going to use your blender>gmt>gjed approach. I have already transferred majority of my track model, and now it is turn for technical things.

Getting normals right, getting alpha test working well, getting UV's working well, getting shadows working right. Then things like reflections, night lights, animated objects and so on....

Speaking of normals I don't know if I do something not right, or it also doesn't work well with export to FBX, hopefully I'll find out when I'll try gmt blender export. So far I have most of my trees and bushes, wheat field, vertical aka 3D grass and flowers all in rF2 already, but normals are obviously wrong. I have set normals UP for those objects with Travellers settings, furthermore all 3D grass, flowers and wheats already has their normals pointing up anyway, but for some reason they aren't when in gJed. By the way, do I open .scn file with gJed when launching .gmt files ?

Thanks for the link to "Real Road Shader", I never thought that it could be advanced shader, because of it's shorter name :D
 
Hi, im getting problems with rF1 and this puglin. I wanted to edit a GMT from an old rF MOD. I Edit it on Blender and then export as GMT overriding directories, after this I do upload the .mas file, and finally when I go to the game it crashes. Maybe I could get some help here because I'm newbie in this modding stuffs and don't know what I'm missing in.
 
By 'loose' he means try it in dev mode where you don't package GMTs into MAS files. Dev mode can read the GMT files without being packaged in a MAS file.

Also, it isn't clear whether you are working on a track or on a car. Another point of info is when it crashes. If it is a track it will crash before 3/4 of the loading sequence is finished. If it is a car that is causing the issue, it will likely be late (last 1/4) in the loading sequence. Are there any error dialogs that appear? The dialogs may appear behind the rFactor window if you are in fullscreen mode. Try a windowed mode so you can see if there are any error dialogs. The error may still be behind the main rFactor window, but in windowed mode, you can bring any error window to the front. If there is a dialog, what is the error in the dialog?
 
What dxp_rlong with regard to loose GMT's. Work on copies, too. Backup often. I'm telling you from experience, and not just with regard to this GMT work. In other words, everything. I get in a groove sometimes and forget. Then I get bit.

The first check I do is import the GMT just exported back into Blender. Load it into 3DSimEd if you have that program. Finally load into rF2 developer mode as a loose GMT. That's one thing that rF1 has over rF2-- rF1 could handle loose GMT's, DDS's, etc. from the program itself.

Concerning your error, I'd have to have the original GMT to see what happened. The error you have is the script hit the end of the GMT file unexpectedly based on data read.
 
Last couple days i have tried some modification of the shape of the tyres for one mod in Automobilista and unfortunatelly i couldnt bring the new shape into the game. Always there is some problems with shaders. Unfortunatelly this script obviously doesnt know the AMS shaders so i tried only change the mesh and uv maps and assigning the material from original gmt onto the new gmt in 3d simed. But always even when in 3d simed all looks good in the game the surfaces which should have specularity they have only diffuse without any spec. Also i tried in 3dsimed to copy paste materials from original gmt to the new one. Also looks good but when the game started to load the car in the car selection menu AMS drops into windows.
Also i tried only to import the original gmts and imediatelly export them, assigning materials in 3dsimed because blender didnt keeps the materials and opening them in the game. Always without specularity or drps into win.
Do you have any ideas what can be corupted or where is a mistake? Thanks
 
Please note: Blender 2.80 is now in the beta stage of development and is being prepared for a final release. Add-on authors can now work on updating their code to run on 2.80. The Python API should be considered mostly stable, but there may be some minor chages related to bug fixing and user feedback. Breaking changes may still happen, but will be kept to a minimum.
 
I'm having some problems exporting GMT with the "Car paint with damage LEGACY" shader, basically this is what I do:
rFactor menu->Change Target rFactor version (to rF1), then Change rFactor objects version
Import GMT
Select all with CTRL+A
SHIFT+Q to merge duplicate materials
Change Target rFactor version (to rF2, so the rF2 shaders are unlocked)
Change WCCARBODY shaders to "Car paint with damage LEGACY"
Assign proper spec, bump and cube map textures (generally I use a pure silver/gray texture as spec, light violet blue as bump and CAR_CUBE_DX9 as cube, unless they has own maps)
Change rFactor objects version
Export
Then I get this traceback error:
MdyOJws.jpg
 
SmashingPant67

The scripts' default target is to rF2. No need to change it if that is what you want to export to.
Do not handle materials outside the scripts' functions in the menu (referencing the Shift-Q step you listed).

1. Import GMT {scripts will detect rF version on import)}
2. Change rFactor Object's Version {this will change the rF objects' materials to the target rF version if needed. You will notice the material number change, if you are in that panel.}
3. Change WCCARBODY shaders to "Car paint with damage LEGACY"
4. Assign proper spec, bump and cube map textures (generally I use a pure silver/gray texture as spec, light violet blue as bump and CAR_CUBE_DX9 as cube, unless they has own maps){In my case I had to change the texture used for the second Diffuse entry}
5. Export

I did the above with a rF1 car body I have. I exported and imported with the scripts with no issues.
 
A 'index out of range' may indicate that you don't have a texture assigned to the "with damage" slot (aka the second Diffuse entry).
 
I'm successfully working on porting my other track to rF2, developed quite well flowing workflow. However still not using the addon to the fullest, as still exporting with fbx and then editing with gjed, I figured out to step up with individual .gmt exporting once I get more advanced.

By the way, I just read an interview with Marcel in racedepartment, and he mentions that they think about plugin for Blender too, which I thought is great. @Traveller maybe you could work together, as there is already a lot of job that you have done, maybe you already talked with S397 ?
 
You must log in or register to reply here.
Back
Top