[WIP] rFactor2 export scripts for Blender 2.80+

Figured out a fairly easy way to UV map groove in Blender.
Anyone interested in a tutorial?
download.jpeg
 
You can set it up in the <2.80 scripts. I haven't tried in 2.80+. You may have to do the bulk of the set up in the S397 material editor. Properties for individual textures in nodes is problematic. I'm working on nodes right now, so I'll take another look-- after I finish what I've planned.
 
I am sorry for having to keep on mentioning this, but here is the problem for real that I was trying to simulate with my experiment previously.

This is an end plate which I have for testing purposes made a lot thicker because I originally thought it may be an issue with how thick it was. As you can see it doesn't make a difference. If you imagine it as a cube, all sides are marked sharp and separated and it is using vertex output normals.
Could someone please explain what's going on. If I move the faces apart by as little as 0.00001 the problem is solved. Its as if when exported the faces are re-joined if their vertex share the same location. I really what to understand this because I want to avoid adding bevels if I can help it.

51314653002_4e194f698d_b.jpg
 
Traveller said:
Thanks for tagging me.

Scripts for 2.93 linked to in first post. NGONS bug referenced earlier in the thread fixed. Also includes more robust add material code.
Click to expand...
"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 1804, in save_gmt_override
AttributeError: 'NoneType' object has no attribute 'type'

location: <unknown location>:-1"

ahh.. now i know why i became that error. forgot the rf2 material settings for the object.
Maybe u can make a "if-loop", if the object hasn't the rf2 material, a popup is showing a text like "you forget the rfactor 2 material settings" ?
 
With the July 11th release of Travller's rFactor 2 export scripts, there are two options in the rFactor Menu for creating an object for eventual GMT export:

- Add rFactor Object
and
- Add rFactor Material

When do you use one or the other?

Selecting Add rFactor Object gives a cube mesh. This a good place to start for those that model with the box-model technique. The added cube object has all the basic rFactor metadata assigned.

If you are collaborating with someone using (FBX, OBJ, xxx) to exchange files, or you use a non-box model building technique (I use splines), the model will not have the rFactor metadata. This is where the Add rFactor Material is used.

Basic usage:

If you model using the box technique, select the rFactor Menu item Add Object and use the resulting cube to edit into a final object. Once your edits are finished, export to rFactor via the Export GMTs menu item in the rFactor Menu.

However, if you are exchanging files with someone, or building models with a non-box technique, once the mesh in the project, select the object and Add Material. Edits can be applied before or after Add Material. Finally, Export GMTs via the rFactor menu.
 
DiggerHawk said:
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.
Click to expand...

I thought I would give an update on a solution I found to the issue I was having in case anyone else was having similar issues. In the end I managed to get the results I was hoping for without adding a bevel. The issue was I had unwrapped the UV's using the project from view method. This caused the short side faces to share the same UV map location as the vertices from the front and back faces, which apparently interferes with the reflections in rF2. Once the sides were moved outwards or inwards on the UV map so they didn't overlap their shared vertices from the front and back faces the issue was gone.

Another trick I have stumbled over is if you use a mesh that has been imported previously as a GMT (like using the older scripts) you can get faces which for some reason refuse to have the correct normals when viewed in rF2, even though they are split from the rest of the mesh. This issue can be solved by selecting the complete UV map (or even just the affected island) then scale by 0.999 using the Individual origins mode. This shouldn't adjust the look of the mapping too much but it seems to fix the problem but I don't know how.

The final piece of the solution is to use the "show smoothing groups" in the scripts blender menu. To do this I first set the mesh to vertex output normals then define the faces that should be flat by defining the sharp edges in conjunction with the split edge modifier using the sharp edges and angle settings. I also add a triangulate modifier to the stack. Once I am ready to export I save the blend file then apply the modifiers in the stack. This splits the mesh up into separate faces along edges that change from smooth to flat shading. Now the important bit I enable the "show smoothing groups" option which temporarily assigns a different coloured material to each of the faces mentioned previously. Now in edit mode I separate by material (P) which creates a new object for each of the colours. I then select all of the newly created objects and merge than back together using Ctrl + J and click "hide smoothing groups". This seems to really break the temptation for rF2 to shade between faces that should be flat, I don't know why but it does. Then its just a case of setting the objects material back to what it should be. Then export.

Here is my results using this method you can compare it to the pic I posted earlier in this thread.

51338063454_c605899d80_b.jpg
 
dxp_rlong said:
[...] if you are exchanging files with someone, or building models with a non-box technique, once the mesh in the project, select the object and Add Material. Edits can be applied before or after Add Material. Finally, Export GMTs via the rFactor menu.
Click to expand...

Hmm I think this is meant to be used with cars in mind? beacuse exporting this way I can move my object around as long as the origin is in the center of the scene; if I move the origin to the center of the geometry nad try to export the object, it transports the object to the center of the scene and then exports it.
I could be wrong but I believe LODs pop in and out depending on where the object´s origin is located, not the geometry. If that´s the case then the plugins won´t be usefull for track making/converting yet.
 
Mitch9 said:
Hmm I think this is meant to be used with cars in mind?
Click to expand...

It sounds like you are moving/setting origin only on the mesh, not the parent.
Screen Shot 2021-07-26 at 9.56.59 PM.png

In this Outliner clip, the Sphere is the parent (an Empty), the Sphere_OBJ is the child. If you set only the Sphere_OBJ/child origin, the result you describe will very likely happen because the parent's origin is located where it was spawned (at the 3D cursor) during the Add Material operation. Once the child's origin is set to the parent's origin, the child will follow the parent and export where the parent is located.

If the Relationship Lines are showing between the parent and the child, their origins are not correctly set. Relationship Lines are activated on the Show Overlays panel. I snap the 3D cursor to the selected parent, snap the child to the 3D cursor, and then set the child origin to 3D cursor to get origins placed.

Using the Add Material will add the parent (the Empty) to the selected mesh object. The Add Object includes the parent as a part of that operation.
 
dxp_rlong said:
It sounds like you are moving/setting origin only on the mesh, not the parent.[...]
If you set only the Sphere_OBJ/child origin, the result you describe will very likely happen because the parent's origin is located where it was spawned (at the 3D cursor) during the Add Material operation.
Click to expand...

Hmm no... Im adding objects, each with their origin centered in them...
bm.PNG

when adding the rf2 material, the parent and the object´s origin goes straight to the global origin:
add.PNG

then tried moving the 3d cursor to the object´s origin:
3d.PNG

same thing happened when adding the material:
add2.PNG

also tried adding an object with a parent then moving those away, but I couldn´t add the material cause the object already has a parent.

So it seems as if one is meant to model everything from scratch using only rf2 objects/materials made with this plugins, which means it wouldn´t work for projects that have already started.
This seems too obtuse to be true; I must be missing something here....
 
Yeah, written like I wrote, there is an assumption that you had selected the object and did a Set Origin : Origin to Geometry prior to the first step as written. However that would only get you part way there. Below is a script that makes things work the way I believe you are looking for them to work. Read the comments in the script to understand what takes place. In short, it uses a placeholder to move things around until everything is in the right pace, while calling into the Traveller scripts, at the appropriate time, to do the actual adding of the rf material.

You can copy & paste this into Blender's text editor or download the python file (below) and open it in the text editor. Then select the object that you want to add rFactor material to, and Run Script from the text editor. I've haven't tested fully, but seems stable. The only issues I had related to either me not having the correct item selected prior to running the script, or the Add rFactor Material function in the export scripts caught something that it would not process anyway. I tried all of Blender's basic primitives, only the cone did not work as expected. The cone changed its origin, all the others kept their original origin. I found some random obj & fbx files from the net that misbehaved in a similar way - but they weren't really candidates for rFactor in the first place. But many of the imported obj & fbx files I tried worked without issue. And, yes, no error checking. So, YMMV.

Of course it would be good to have the desired behavior in the add-on itself, in the meantime, this can let things move forward.

There is no indentation in this script so python shouldn't have any of those issues.
-------------------------------------------------------------------------------------------------
import bpy

# the active object must be the selected mesh on which Add rFactor Material will run
selectedObj = bpy.context.active_object

# create a placeholder (an Empty) to return to after Add rFactor Material
mt = bpy.data.objects.new(selectedObj.name+"_temp_EMPTY", None )
bpy.context.scene.collection.objects.link( mt )
mt.location = bpy.context.scene.cursor.location

# and then hide it in the viewport for clarity in viewport
bpy.data.objects[selectedObj.name+"_temp_EMPTY"].hide_viewport = True

# call the rFactor GMT exporter's Add rFactor Material function
bpy.ops.mesh.add_rf2_material()

# Add Material moves the selected object's orgin to 0,0,0
# so we move it back to the original origin
bpy.ops.object.origin_set(type='ORIGIN_GEOMETRY', center='MEDIAN')

# make sure we in the correct context
area = bpy.context.area
old_type = area.type
area.type = 'VIEW_3D'

# move the selected/original object to the parent's origin to sync origins
bpy.ops.view3d.snap_selected_to_cursor(use_offset=False)

# move the 3D Cursor back to the placeholderx
bpy.context.scene.cursor.location = mt.location

# select the newly creatd rFObject's parent and chid
selectedObj.select_set(True)
selectedObj.parent.select_set(True)

# move the new rFObject back to the original mesh position
bpy.ops.view3d.snap_selected_to_cursor(use_offset=False)

# return to the starting context
area.type = old_type

-------------------------------------------------------------------------------------------------

 

Attachments

Last edited:
I have never seen the technique you are describing used for rFactor tracks, so I thought I would explore how it would work. After getting origin points to work like I believe you wanted to them work, I can not see how a track could be built using this approach. But I don't know everything about 3D modeling, so I attempted to help you achieve what I thought you were after.

Hopefully you'll take a few minutes to understand my approach to converting/building tracks for rFactor 2.

In the transition from rF1 to rF2, very few of my favorite tracks were available in rF2. I used older version scripts to convert about 2 dozen rF1 tracks to rF2 for personal use. I also built 2 or 3 tracks from scratch using the scripts.

The one thing all of tracks had in commom was all major track and terrain objects (and usually all TSOs) had their parent and child origins set to 0,0,0 (world center). So I am not sure what you mean the scripts are not built for creating tracks. I find them to do exactly the right thing for tracks, as well as cars.

The only time I experience the 'pop-back' of an object is when I forget to 'Object:Apply' transforms. Which means the first question that comes to mind is : have you used the Apply function on your objects?
 
dxp_rlong said:
Which means the first question that comes to mind is : have you used the Apply function on your objects?
Click to expand...

This could be it; I´ve never had to apply anything beyond scale and rotations so didn´t really bother when moving the position.

dxp_rlong said:
I have never seen the technique you are describing used for rFactor tracks, so I thought I would explore how it would work. After getting origin points to work like I believe you wanted to them work, I can not see how a track could be built using this approach. But I don't know everything about 3D modeling, so I attempted to help you achieve what I thought you were after.
[....]
The one thing all of tracks had in commom was all major track and terrain objects (and usually all TSOs) had their parent and child origins set to 0,0,0 (world center)..
Click to expand...

I guess the technique you´re talking about having the origins centered on each object? I´m not very familiar with gmotor, but pretty sure in assetto corsa the origin point of the objects are used to pop the lods in and out, so having them elsewhere than the center would make them sort of pointless (no pun intended).
When you open up a set of gmts or kn5 files, objects will have the origins at the center of the scene and all meshes will be triangulated, but this doesnt mean they were modeled this way; at least the triangualtion happens when exporting to kn5 and, i´m assuming gmt too.

Thanks for the script, I´ll give it a go and keep digging at this.
 
You must log in or register to reply here.
Back
Top