Odd RealRoad race groove problem (rF1 conversion)

Discussion in 'Track Modding' started by Jorgen, Dec 19, 2012.

  1. Jorgen

    Jorgen Registered

    Joined:
    Oct 5, 2010
    Messages:
    558
    Likes Received:
    3
    I started off with another rF1 track conversion yesterday, and after extracting the road material geometry into separate GMT objects and assigning the RSTDM shader to the material, everything looks good. However, the race groove only forms properly on 2 of the 21 RaceSurface instances. What could possibly cause this? Bad U/V mappings on individual GMT objects, or something else?
    (The instances are all named RaceSurface_<xx> and have Deformable=True in the scene file)

    EDIT: After further inspections, the race groove was not forming on those two GMT's, so RealRoad is not working.
     
    Last edited by a moderator: Dec 21, 2012
  2. Jka

    Jka Member Staff Member

    Joined:
    Jan 31, 2011
    Messages:
    954
    Likes Received:
    213
    I would first check out channel 2 (marbles, spec and multiply maps) and channel 3 (racegroove and reflection maps) mapping.

    In most cases, original rF1 track mesh do not have enough polys to create racegroove correctly. Racesurface "grid" must be way more dense than rF1. Straight 3d model conversion from rF1 to rF2 probably wont give you wanted result.

    Cheers!
     
  3. Jorgen

    Jorgen Registered

    Joined:
    Oct 5, 2010
    Messages:
    558
    Likes Received:
    3
    The mesh is surprisingly good in this case, it has six rows of tri's throughout, so that is likely not the problem here. I'll have a look at the mappings then, thanks for the tip!
     
  4. Jorgen

    Jorgen Registered

    Joined:
    Oct 5, 2010
    Messages:
    558
    Likes Received:
    3
    No luck I'm afraid. Not sure what the problem can be in this case, but I did notice that the .rrbin file stays at 2kb in size, so the race groove is definitely not working.

    This is what the road surface mesh looks like. Is there an apparent problem with it?

    [​IMG]
     
  5. Hazi

    Hazi Registered

    Joined:
    Jan 15, 2012
    Messages:
    917
    Likes Received:
    146
    Maybe that should be quads and not tris? Experts?
     
  6. ethone

    ethone Registered

    Joined:
    Nov 30, 2011
    Messages:
    1,153
    Likes Received:
    37
    Tri's are not an issue, RealRoad works on a per-vertex basis so as long as the vertices are there you're fine. Alignment of tri's can make a difference for interpolation of the groove but if you're not getting anything the issue is somewhere else.
     
  7. Luc Van Camp

    Luc Van Camp Track Team Staff Member

    Joined:
    Oct 4, 2010
    Messages:
    1,030
    Likes Received:
    15
    No, that mesh looks fine. In the end a quad doesn't exist in game engines. Everything gets triangulated. Quads are only preferred because they make the editing process less cumbersome.

    Edit: :)
     
  8. Jorgen

    Jorgen Registered

    Joined:
    Oct 5, 2010
    Messages:
    558
    Likes Received:
    3
    Thanks for the input! I'll continue looking, because at the moment it doesn't even feel like I'm driving on the road surface. It's probably something silly I overlooked somewhere.

    Is there any sort of log file you can enable by a command line option, which can show you RealRoad-related errors? (That would make tracking these things down a lot easier)
     
  9. Jorgen

    Jorgen Registered

    Joined:
    Oct 5, 2010
    Messages:
    558
    Likes Received:
    3
    Hooray, problem solved! Unfortunately I changed three things at the same time, so I don't know which of the three that helped:

    1) Renamed the realroad GMT files from racesurfacexx.gmt to roadxx.gmt
    2) Changed Deformable=True to Deform=True and added an extra space at the end of the line
    3) Moved the RaceSurface_xx instances higher up in the scene file

    I don't think #3 should make a difference since I gave the material a unique name that did not exist before. That leaves #1 and #2. The track technology PDF mentions Deform=True while some stock tracks have Deformable=True, so I suspect both work. Can it really be as silly as the actual GMT file names?
     
  10. ethone

    ethone Registered

    Joined:
    Nov 30, 2011
    Messages:
    1,153
    Likes Received:
    37
    - The actual GMT filename does not matter, the instance name however does matter and needs to be RaceSurface*.
    - An extra space at the end does nothing, deform=true and deformable=true seem to be identical in their effect. deformable works fine on my current track
    - All you need for a material change to not take effect is a single poly in an old .gmt that is listed higher in the scn file than the .gmt that you're exporting with the new material. Generally speaking (and unless you're always exporting all the .gmts when you only changed a few of them): If you run into an issue with a material not updating when it should, moving the gmt you last worked on with that material to the top is among the first things you should do just to make sure the latest version is being loaded first. If you keep doing that you'll eventually have some form of manual bubble sort in your .scn with the oldest unchanged gmts at the bottom and newer ones at the top, reducing the likelihood of old material settings being applied instead of newer ones. Before moving to single player a complete export is the safe thing to do anyway though.
     
  11. SPASKIS

    SPASKIS Registered

    Joined:
    Sep 7, 2011
    Messages:
    3,155
    Likes Received:
    1,426
    I solved one problem once by reviewing the scn file. I replaced a "myself typed space character" for the original "space" character and worked. Try copy/pasting the tags from a working scn file into yours. I would say it is the "extra space" what solved your problem.
     
  12. Jorgen

    Jorgen Registered

    Joined:
    Oct 5, 2010
    Messages:
    558
    Likes Received:
    3
    I have noticed that quite often there are all sorts of weird objects that make use of the "road" material, so I have now started to give the material which I use for the race surface a new and unique name. This helps in situations where material names would otherwise collide. For instance, the X-objects (xpitin, xpitout etc) often use the same material as the road surface in rFactor1 tracks, and since they are quite often defined early in the scene file, they are easy to miss.
     
  13. DmitryRUS

    DmitryRUS Registered

    Joined:
    Apr 17, 2011
    Messages:
    439
    Likes Received:
    47
    I want to ask by the principle of work of RealRoad on the gmotor engine.
    The principle same, as well as drawing on a surface, in 3Ds Max - VertexPaint?

    To draw tires on the road, will be?

     
  14. Luc Van Camp

    Luc Van Camp Track Team Staff Member

    Joined:
    Oct 4, 2010
    Messages:
    1,030
    Likes Received:
    15
    Yes, that's basically the principle, except that the Vertex Colour modulates the RaceGroove texture rather than just painting the vertex (interpolated to each of the connecting faces) black. When a tyre touches a RealRoad node (a vertex), it will change the Vertex Colour accordingly to the tyre load (under braking or cornering should produce dramatically different results than driving in a straight line).

    So the road mesh density plays a big factor in how accurate and detailed RealRoad will look. Increasing the mesh density means that each car will 'tag' more nodes in a given time, which results in extra calculations. When racing online, each node also needs to be sent to all clients. This is currently a hardware limitation, so imagine how dense the surfaces could become in the future when everyone has 1Gbps internet connections and extremely powerful processors to handle such a dense mesh :) ...
     
  15. DmitryRUS

    DmitryRUS Registered

    Joined:
    Apr 17, 2011
    Messages:
    439
    Likes Received:
    47
    And it is impossible to find alternative mode of work? More simply and more exact?
    I don't want to give an example, but in KartPRO it works much more simply, more precisely and more functionally. And is visually more esthetic.


    It seems to me it is Gmotor=VertexPainter strongly loads graphics and not beautifully looks.
     
  16. DmitryRUS

    DmitryRUS Registered

    Joined:
    Apr 17, 2011
    Messages:
    439
    Likes Received:
    47
    You strongly don't become angry about me. I simply want to help something, somehow idea to find more pleasant result. Жыль I am not a programmer, and only the artist therefore Aesthetically a look on живоё the track is important that he would live, different life, in each race. Different series.
     
  17. Luc Van Camp

    Luc Van Camp Track Team Staff Member

    Joined:
    Oct 4, 2010
    Messages:
    1,030
    Likes Received:
    15
    I suppose one alternative would be to have a texture stage using a huge 8192x8192 map on which RealRoad is drawn. In this texture you could have rubber (red channel), oil (green channel), wetness (blue channel) and dirt (alpha channel). That's a possibility, yes. For a small 1km² kart track, this would be the way to go. For a track the size of an international circuit like Silverstone, 1 pixel may still produce slightly better results. For a 22km track, 1 pixel would be larger than the track width though.

    So in terms of flexibility and future scaling, RealRoad is probably the most efficient way :) . I wouldn't mind having an unlimited texture size and infinitely high poly tracks, but then the car guys won't be happy, and a lot of people seem to think that racing simulations are all about the cars rather than the tracks :( .
    Keep in mind that some of the rF2 tracks already have a road mesh that consists of more polys than an entire high detail rF1 track.
     
  18. DmitryRUS

    DmitryRUS Registered

    Joined:
    Apr 17, 2011
    Messages:
    439
    Likes Received:
    47
    And if each of brake traces, has coupling property, and it is simple to extend according to the card location of these traces, as separate generating model of a trace which changes over time coupling property.
     
  19. Luc Van Camp

    Luc Van Camp Track Team Staff Member

    Joined:
    Oct 4, 2010
    Messages:
    1,030
    Likes Received:
    15
    I can't see any way of making something like that work without either taking up most of the memory. It would be easier if RealRoad was just a visual output, but underneath, it also serves as an input at the same time to determine how much grip a tyre will find when it hits the RealRoad node. Any other system would have a physical model and faked visuals, so what you see wouldn't necessarily be the same as what the tyre feels. I'm confident that in time, when PC and network hardware makes another few steps forward, we can have RealRoad meshes that allow a lot more detail, whilst keeping the 1:1 correlation with the physics.
     
  20. DmitryRUS

    DmitryRUS Registered

    Joined:
    Apr 17, 2011
    Messages:
    439
    Likes Received:
    47
    And separately, visual and not it is possible to make visual RealRoad? Visually that would look more beautifully, and at other level works as is.
    I am afflicted that the exit isn't present.
    In any case thanks for an explanation.
     

Share This Page