[WIP] rFactor2 export scripts for Blender 2.80+

Thanks, I usually have dozens of collections per scene depending on how many different types of objects I have, I´ll see what happens when only using four as you suggest.
 
Hi,

sorry, but I'm stupid, or blind, or both... how can I import a .GMT?

EDIT: okay, I'm stupid, sorry... :confused:
 
Last edited:
Hi

Created a track for Assetto Corsa in Blender and now I'm trying to create it for rFactor2. Using 2.91.
Installed the export script and created the xPlanes; xfinish, xsector1 and xsector2 just to try how it works.
Located in collection GMTs. (Should they be parented to the object rF2_Object_Parent?? Or not?)
Changed material to diffused (rFactor2_PBR) via rFactor2 menu

Solved!
Went back to 2.79 and learnt a lot from Jasonville track :)
 
Last edited:
The documentation for the earlier scripts is somewhat valid. rFactor data for the rF Parent (GMT container) and meshes are still good. Materials and textures can be handled through the S397 materials editor. Here is an image from Blender of a car that graphically works in the game. It will load in the spinner/ garage. Hope this helps with those questioning structures and parenting. Two GMTs are expanded-- one with a single material and the other with multiple materials.

Please note: The file name for the GMT is contained in the File Name field of the rFactor2 Object settings panel. See lower right corner of image.
upload_2021-6-6_0-39-2.png
 
Mitch9 said:
So it´s my first time trying out the script and I get this error:

View attachment 38250

I tried clicking a few things in the rf2 material/mesh options but no luck, any help? Tried exporting a few meshes, all the same.
Click to expand...

I had the same problem as you. Did you manage to fix it?

What worked for me was to select the object then in materials activate "use nodes".

The problem I'm getting now is when I try to export a mesh that contains Ngons I get an the following error message,

NameError: name 'BMnSG' is not defined

If I select the NGons and triangulate them it will export fine.

I have been using the previous scripts with Blender 2.79 but I wanted to upgrade to the latest Blender version so I thought I would give it a go. Will these scripts support import in the future? Also does anybody know why the older scripts would fail to import some GMT's while others would work fine?

Mark
 
There are no plans for import.

There is no support for encrypted GMTs in the 2.79 scripts. The scripts should note that a GMT is such in the console output. Otherwise, an examination of the GMT is needed to determine the cause of failure.
 
Traveller said:
There are no plans for import.

There is no support for encrypted GMTs in the 2.79 scripts. The scripts should note that a GMT is such in the console output. Otherwise, an examination of the GMT is needed to determine the cause of failure.
Click to expand...

Thank you for clearing that up. I thought some may be encrypted.

This is the error message I get when I try to import an affected GMT using the 2.79 scripts. Is this telling me its encrypted or is it a different issue?

NewStyleGMT= False
Traceback (most recent call last):
File "F:\Blender Foundation\blender-2.79-windows64\2.79\scripts\addons\io_rfactor_gmt\rF_Menu_Stuff.py", line 293, in execute
File "F:\Blender Foundation\blender-2.79-windows64\2.79\scripts\addons\io_rfactor_gmt\rF_GMT_Import.py", line 3204, in load_rf
File "F:\Blender Foundation\blender-2.79-windows64\2.79\scripts\addons\io_rfactor_gmt\rF_GMT_Import.py", line 2504, in load_gmt
File "F:\Blender Foundation\blender-2.79-windows64\2.79\scripts\addons\io_rfactor_gmt\rF_GMT_Import.py", line 2183, in Get_GMT
File "F:\Blender Foundation\blender-2.79-windows64\2.79\scripts\addons\io_rfactor_gmt\rF_GMT_Import.py", line 1963, in GetVertices
File "F:\Blender Foundation\blender-2.79-windows64\2.79\scripts\addons\io_rfactor_gmt\rF_GMT_Stuff.py", line 1603, in ReadXZY
File "F:\Blender Foundation\blender-2.79-windows64\2.79\scripts\addons\io_rfactor_gmt\rF_GMT_Stuff.py", line 1599, in ReadSingle
struct.error: unpack requires a bytes object of length 4

location: <unknown location>:-1

In regards to Ngons not exporting I don't think there was an issue with the 2.79 scripts so I presumed it is a bug.

Could you please explain how your script handles normals and how the show/hide smoothing groups works and how it relates to what is displayed in game.

Mark
 
Hi guys,

I'm having trouble exporting a gmt using the addon for blender... It works fine with the cube but I can't export any other mesh...

I've recorded my screen to show what is happening... Any ideas?

Blender 2.92

Thanks!!


 
Encrypted GMTs will show a message stating it. The error string in the prior post means the internal pointer for data in the GMT has gone beyond the length of the GMT, so something is off somewhere.

Concerning the "BMnSG" error. That is a bug. Fixed. Will release.

Concerning the use of Ngons... I recommend you don't. I can't find the document now, but years ago it was recommended to edit meshes in quadrangles. GMTs support triangles and quadrangles. These scripts break meshes down to triangles. I may one day add or change them to support quads. Anyway, I've converted to and edit all of my meshes in quads. Blender has a tris to quads function. I've found its best to convert a mesh in pieces, so rectangles are formed and not rhombuses. Blender has a polygon selection tool that will highlight polygons in a mesh based on criteria. Once such criteria is the number of sides. So you can easily spot odd ball polys. Ngon support was put in as a last chance catch.

Normals in the scripts are added to each vertex. Up normals are 0,0,1. Face normals are copied to each vertex of the triangle of the mesh. Smooth normals use the Blender API calc_normals() function and the normals are applied to the appropriate vertices.

Concerning smooth groups... there is an integer value in the face data of GMT. I'm using it for smooth groups experimentally. The API function calc_smooth_groups() is used to calculate the groups in a mesh. The number of a group for a polygon is stored in the face data for the polygon. The 2.79 scripts have a menu function to show and hide the smooth groups. That will create color-coded materials based on that number in the face data. That visualization is not available in the 2.80 scripts. The smooth groups are based on angles between polygons (adjustable), edges marked as sharp, and sections of a mesh detached from the rest.
 
Traveller said:
Encrypted GMTs will show a message stating it. The error string in the prior post means the internal pointer for data in the GMT has gone beyond the length of the GMT, so something is off somewhere.

Concerning the "BMnSG" error. That is a bug. Fixed. Will release.

Concerning the use of Ngons... I recommend you don't. I can't find the document now, but years ago it was recommended to edit meshes in quadrangles. GMTs support triangles and quadrangles. These scripts break meshes down to triangles. I may one day add or change them to support quads. Anyway, I've converted to and edit all of my meshes in quads. Blender has a tris to quads function. I've found its best to convert a mesh in pieces, so rectangles are formed and not rhombuses. Blender has a polygon selection tool that will highlight polygons in a mesh based on criteria. Once such criteria is the number of sides. So you can easily spot odd ball polys. Ngon support was put in as a last chance catch.

Normals in the scripts are added to each vertex. Up normals are 0,0,1. Face normals are copied to each vertex of the triangle of the mesh. Smooth normals use the Blender API calc_normals() function and the normals are applied to the appropriate vertices.

Concerning smooth groups... there is an integer value in the face data of GMT. I'm using it for smooth groups experimentally. The API function calc_smooth_groups() is used to calculate the groups in a mesh. The number of a group for a polygon is stored in the face data for the polygon. The 2.79 scripts have a menu function to show and hide the smooth groups. That will create color-coded materials based on that number in the face data. That visualization is not available in the 2.80 scripts. The smooth groups are based on angles between polygons (adjustable), edges marked as sharp, and sections of a mesh detached from the rest.
Click to expand...

Thank you for the information Traveller.
When I import a mesh or when working from scratch I use quads buts sometimes those Ngons can creep in after applying modifiers. I found the tool you mentioned that selects faces based on the criteria selected the other day, very useful.

The issue with faces I keep on facing is with weird normals in rF2 that are fine in blender. For instance imagine the endplate of a front wing. Its a large flat surface with 90 degree adjacent faces, like a plank of wood. I mark the edges as sharp and apply a "edge split" modifier so that the faces a separate. When exported and loaded in rF2 the large flat face will have weird shading. The only way I have found to fix it is to add a bevel around the edges then split the edges but that adds more geometry. Its as if the script joins the faces back together on export. In fact I have noticed that if the GMT is re-imported (older script obviously) its as if the edge split never happened, all faces are re-joined. Is this the export or import that does this?

Mark
 
A remove_doubles() is applied at the end of every import. Otherwise, you'd have X number of triangles to deal with. Once you have a blend you should not have import anymore.

Marking a sharp edge should be enough. One variant to the normals I described above is sharp edges. In that case, the vertices of the sharp edge have face normals applied instead of the smooth normals. Vertices not on that edge have smooth normals applied. Edge splits are not accounted for in the scripts.
 
Traveller said:
A remove_doubles() is applied at the end of every import. Otherwise, you'd have X number of triangles to deal with. Once you have a blend you should not have import anymore.

Marking a sharp edge should be enough. One variant to the normals I described above is sharp edges. In that case, the vertices of the sharp edge have face normals applied instead of the smooth normals. Vertices not on that edge have smooth normals applied. Edge splits are not accounted for in the scripts.
Click to expand...

The only reason I was re-importing the mesh was to check to see what your export script was doing. Now I understand that the mesh was re-joined on import (remove doubles) not on export I can rule out that being the issue.
I get that the scripts don't support the edge split modifier but once its applied it just splits the mesh based on the angle of the faces and/or marked sharp edges. From that point the mesh is no different to any other as far as the scripts are concerned.

Just to confirm what you are saying. If I take my quadrangle mesh and mark the edges as sharp, set it to "vertex output normals" then export it, the shading of connected faces separated by a sharp edge will not be smoothed together. To put it another way, if I was to mark all edges as sharp that would be the similar as setting the mesh to "face output normals"?

Would you recommend turning on "auto smooth" and setting its angle to 180deg? That way the viewport will display similar to rF2 in terms of only edges marked as sharp will be sharp with "vertex output normals". Without "auto smooth" on or an "edge split" modifier active, marked sharp edges do nothing in the Blender viewport as far as I know.
 
I have completed a simple experiment showing what affect various techniques have on the mesh in rF2.

The mesh is set in Blender 2.92 with "vertex output normals" and exported using Travellers export scripts 2.80.

51267880342_27c4c8039d_b.jpg


TOP LEFT shows the default cube reduced in thickness on the Y axis to make a slim plate. One corner edge has been bevelled in edit mode and the blue lines show the edges marked as sharp.

TOP RIGHT image shows the mesh exported to rF2 with just the edges marked sharp. As can be seen rF2 tries to shade it as a single smooth surface.

BOTTOM LEFT image shows the same mesh but with the "Edge Split" modifier set to use sharp edges and applied. You can see it is better than before but it still exhibits some normal issues, worst of which is on the rear side that can't be seen here.

BOTTOM RIGHT image shows the mesh as before but with a "Bevel" modifier added before the "Edge Split". This looks the best with no normal artefacts but has more geometry.

Interestingly before the corner was rounded-off the mesh exported fine with just the edges marked sharp.
 
DiggerHawk said:
I had the same problem as you. Did you manage to fix it?

What worked for me was to select the object then in materials activate "use nodes".
Click to expand...

Hi, thanks for the tip. I tried traveller´s suggestion of only using the 4 main collections (scn, lights, camera, gmts) and it did "fix" the issue, but I got another error about not having a texture or something, so your fix will probably take care of that
 
Hi
Creating starting grid for my track and some of the lines are more... tranperant??? than others.
I can change the color from white to any other color with vertex paint, but when I'm painting white it got that faint bluish color.
The white (correct!) line and the bluish is the same mesh.

Could someone point me in how to get them all white?
 

Attachments

  • stripes.png
    stripes.png
    651.4 KB · Views: 252
Last edited:
Bjørn Lund said:
Hi
Creating starting grid for my track and some of the lines are more... tranperant??? than others.
I can change the color from white to any other color with vertex paint, but when I'm painting white it got that faint bluish color.
The white (correct!) line and the bluish is the same mesh.

Could someone point me in how to get them all white?
Click to expand...
It was due to wrong UV mapping. Not vertex painting as I was chasing...
 
haunetal1990 said:
can't install the plugin under blender 2.93
Click to expand...
I get this error too.

I notice the zip file contains .pyc files (except for __init__.py). Was it a deliberate choice to omit the .py files for the whole plugin or was than an error? I've written a few Blender addons, and although I have little knowledge of file formats, and it takes me a while to get into gear before doing my own code, I tend to get there in the end and might be able to make useful suggestions for bug fixing.
 
Last edited:
You must log in or register to reply here.
Back
Top