[WIP] rFactor2 export scripts for Blender 2.80+

Big thank at you and at your work!

 

I have been using this export script for months without issue, until now. My problem is I am trying to export a mesh with the compatibility for a normal map. I have switched the object to the "Legacy Special Shader, L2BUMPCMAPSPECMAPT0" pre-set so it populates the correct attributes to the object. This has worked for some of my meshes but not all. When I try to export, I get the following error message,

Python: Traceback (most recent call last):
File "D:\Blender Foundation\blender-2.93.0-windows64\2.93\scripts\addons\io_rf2_gmt_Source\rF2_Menu_Stuff.py", line 528, in execute
File "D:\Blender Foundation\blender-2.93.0-windows64\2.93\scripts\addons\io_rfactor2_gmt_WIP\rF2_GMT_Export.py", line 1805, in save_gmt_override
File "D:\Blender Foundation\blender-2.93.0-windows64\2.93\scripts\addons\io_rfactor2_gmt_WIP\rF2_GMT_Export.py", line 1753, in save_gmt
File "D:\Blender Foundation\blender-2.93.0-windows64\2.93\scripts\addons\io_rfactor2_gmt_WIP\rF2_GMT_Export.py", line 1735, in PutrF2GMT
File "D:\Blender Foundation\blender-2.93.0-windows64\2.93\scripts\addons\io_rfactor2_gmt_WIP\rF2_GMT_Export.py", line 1510, in PutMeshes_rF2
File "D:\Blender Foundation\blender-2.93.0-windows64\2.93\scripts\addons\io_rfactor2_gmt_WIP\rF2_GMT_Export.py", line 1387, in PutVertexData
File "D:\Blender Foundation\blender-2.93.0-windows64\2.93\scripts\addons\io_rfactor2_gmt_WIP\rF2_GMT_Export.py", line 58, in CalcBumpMapTangents
KeyError: 307

location: <unknown location>:-1

Sometimes it's a KeyError: 1753

If I change the Output Normals to Face or Up the object will export. What is strange is that some of the objects under the same parent will export fine with normals working in rF2 but some refuse to export out of blender. I have tried creating a new object using the "Add rFactor2 Object" tool and that will export with a material that has normals but not if I merge a troublesome mesh with it, that just throws the 1753 error.

If I change the material type back to "Legacy Diffuse Shaders, L2DIFFUSET0" or any of the other presets without normals it will export fine again.

Is this a known issue?

 

Just to clarify, I normally use just the diffuse pre-set and then add a json override material. But this doesn't allow a normal map to work in rF2. When you add the normal map in rF2's material editor it doesn't do anything unless the GMT has the correct material assigned. There doesn't seem to be an issue with the other maps, Ambient Occlusion or Metal/Roughness. They work with the basic material assigned in blender and the relevant json shader entries. Once you manage to get the mesh exported with "L2BUMPCMAPSPECMAPT0" assigned the normal maps work as they should.

 

Is the mesh in question all triangles or all quadrangles?

 

The mesh is in triangles as I always apply a "triangulate" modifier before exporting. I managed to sort the issue out for this model by exporting to FBX format then re-importing the FBX and merging it with the starting rF2 object from the menu. This technique didn't work with other models that I was having issues with, although I have stumbled on another fix for these that has worked so far. The issue as far as I can tell is with meshes that make use of modifiers that once applied alter the geometry in a way that also alters their UV mapping. I have found that exporting a mesh with the ability for a normal map requires a few more rules that need to be abided to for the export to be successful.
All faces that are joined by a sharp edge must be separate in the UV map as in their shared vertices must not be overlapping. For example, if the mesh was just a cube, you would normally unwrap it and end up with a UV map shaped like a cruciform, six squares all connected on at least one side with another square. But for rF2 it appears these squares should be completely separate, even a small gap is enough for it to work. This is not only a must it seems for normal maps to work but also for reflections to work correctly without weird glitches.

I must point out that this issue with the meshes not exporting with an active normal map only affects models with the "edge split" modifier applied, or any similar modifiers that adjust the UV mapping or in the case of "edge split" with angled based setting, adjust what edges are considered sharp. The best approach I have found is to mark the sharp edges then use the "edge split" modifier set to only sharp edges, followed by the "triangulate" modifier. Make sure all edges marked sharp are split up on the UV map. Then obviously after saving apply the modifiers, then export to GMT and it should work. The problem occurs if you want to use things like "decimate" modifiers or the "Subdivision surface" modifier in a non-destructive workflow, as you wouldn't be able to mark sharp edges until after the modifiers are applied as some of those edges wouldn't yet exist or there would be less of them depending on which modifier was used. For this you would ideally use the angle setting for the "edge split" modifier as no marking sharp edges would be required, but then you wouldn't know which edges to separate in the UV map. Although a little cheat I found is that if you apply all your modifiers including the "edges split" you can then in the UV editor, scale the whole UV mapping using "individual origins" by 0.99%. That will move all overlapping vertices that shouldn't be sharing UV coordinates away from each other. This is a technique that works well on the lower LOD versions of the model as the non-destructive workflow is beneficial.

I know previously you have stated that just marking edges sharp should be enough, but I have never found that to work for me. Only with the sharp edges split are satisfactory results achieved. Otherwise, it's as if no edges have been marked sharp.

Anyway, hopefully I have found a way that alloys me to continue the project. I was going to add normal maps to all of my meshes but I think I will just do it for those that require it as I have adjusted far too many of the CART 98 meshes and created plenty from scratch that it would take forever.

 

Glad you got it working.

The scripts are undergoing what has turned into a rewrite. The biggest rewrite so far is in the mesh export routine. It is less than half the size it was, with over a thousand lines removed. It now has quadrangles output taking up less space, so a quad only mesh is advantageous. I'll see if that routine will work with these older scripts for an interim release.

 

Thank you for your work creating the scripts and your continued work reworking them. Without your efforts only those with 3dsmax would be able to create the content for rF2.

 

Problems and resolutions.

As above, I'd planned to back port the current mesh export routine to these scripts. Long story short, it didn't work. While looking into it, an even longer story short, the current scripts don't work for me. The guys testing have reported no issues. So...after a calming down and cooling off period....

Resolution #1: I'll get the current scripts working for me again, and see if they still work for the guys.

Resolution #2: Once working, I'll post the current scripts here in the forums. They run on 3.3.X, so I may make another thread and let this one die. Things are rearranged a bit, so updated docs or perhaps a video will be done to support.

Resolution #3: I'll post the scripts somewhere where they can be maintained in a more structured setting. This will be something new for me as I'm just a hobbyist programmer. However, sometimes an old dog needs to learn new tricks.

 

I thought I had the normal map issue sorted but then I came across this issue. The normal map sometimes only affects some of the mesh, as can be seen in the image below.



The face with the MOMO logo on it should be bumpy like the rest of the part. I thought it may be an issue with planar faces, but the test cube above has the working bumps on all its faces except for the front and top faces and there're all planar, weird.

Is there an object property box that needs ticking or some material setting I'm missing?

 

I managed to copy the affected mesh into an old version of Blender that used the previous scripts (0.78) and set up the material as a L2BUMPT0. This method worked perfectly. I then copied it back to the newer version of Blender and obviously I had to rework the material using the node system. Unfortunately, the missing areas of bumps were back. So, it appears as far as I can tell the issue is with the way the nodes work and the newer scripts.

 

@DiggerHawk , it is in the bump map support values calculation on export. I went with a faster routine with the newer scripts. I'll look into it.

In the meantime, making progress on getting the newer scripts working for me again. Some issues with the scripts, which I've corrected, and some with my models in Blender not brought up to the newer nodes standard. I modified by hand, but will investigate making a utility routine.

Below is a screenshot of my car model GEN in game. The wheels and tires are missing, as still have issues with them, but the car body is in. The car body is notable in that it uses a node setup in Blender for the IBL Standard material in rF2. It looks funky as the textures I currently use are placeholders just to meet requirements. The two spheres are a test export of the marked smooth and marked sharp values. Those work now, under the new export routine.

There is also a screenshot of the the scene in Blender. You can see where some rF2 items have been moved. Items you might access while working in 3D view are on the right edge of the 3D window. Materials are on the right edge of the nodes window. This way you don't have to move the cursor too much out of the way to access options.

 

Thank you Traveller for looking into it. I loaded one of my exported GMT's into 3dsmed3 and exported them, which did fix the issue. While viewing the model in 3dsimed3 without texture loading, I noticed that it looked blotchy, suggesting something was wrong with the GMT. I thought this information may help to diagnose the issue, but you seem to be fully aware of where the issue lies. I really don't want to add 3dsimed3 to my workflow as I don't want to buy it if I don't have to. Although the 20-day trial has been helpful.

It's great to see the progress you have been making with the integration of your scripts into Blender. Will this be for the latest version of Blender?

 

I get this when i try to activate the plug in:

https://i.ibb.co/yqb003v/Untitled.png

I m using 3.1.2 version. Any thoughts?

 

Python version mismatch, 3.9 vs. 3.10. Blender 3.0 will match.

 

Thanks

Will try it

PS problem is that my project is done in 3.1.2 though..

 

I have the new scripts working again with the exception of the bump maps. That doesn't work now. I can understand an issue with the IBL shader (spoiler alert) but not the legacy shaders that have been a part of the scripts from the beginning. Anyway, looking at that. I have 3 days left of a 4 day weekend. Hopefully I'll have it fixed by the end it.

 

Hi Traveller,
IBL shader (spoiler alert) that sound's great.
Good success and thanks in advance (can't wait to use it).

 

Problem found. Well, two problems. Fixing the second should fix the first as they both deal with texture entries for a material.

 

@Traveller can you make this work also for Blender > 3 versions?

Or are we stuck with 2.93 and only?

 

Current development is on 3.3X . There will most likely be a new thread as the appearance of the scripts in Blender has changed.