Posts by Kira

    Marcel Kuhnt

    I've tested a bit more and believe I've found a possible cause. The problem always occurs when a surface spline has been selected for the bedding in the rail properties.

    The whole thing also occurs when using standard content. The example shown makes no sense at all, but the map editor obviously does not like this combination, since it takes an average of 3-5 minutes to calculate a 50m track on a new empty map (without a surface spline for bedding it only takes 10-20 seconds).

    Yes i use spline

    If you want to continue using the PH37a rail and ties, please also replace the splines with polygons (it should be at least -0.195 below the top of the rail).

    I just tested it and was able to reproduce a very similar behavior in the map editor when creating a two lane test track with splines on a blank map. Therefore, it's very likely that the error is caused by the use of the surface splines.

    Now that I know about the problem, I'll take a closer look at it. Apart from that, I would recommend using polygons anyway, as these are usually much more versatile than a spline.

    The model itself is fine, in different modeling editors.

    This is where the 3D programs "lie to you".

    As you've already noticed, the problem is that the normals of several polygons point in the wrong direction. This doesn't matter so much in Blender (or many other 3D programs), because usually the back of a polygon is also displayed with a material / texture.

    But most game engines don't have this strange behaviour. Therefore I recommend to enable "Backface Culling" to see the mesh as it appears in Lotus.

    To solve the problem in Blender, you can try 2 things.

    In edit mode you can run "Recalculate Outside" (CTRL + N) while all polygons of the object are selected (A) and hope that Blender will fix everything (unfortunately this function often fails with very complex objects).

    Or you have to select all affected polygons (Backface Culling helps here too) and rotate them manually with the "Flip Normals" command in the same menu.

    Ok, now that's clear. Did you remove -VRon from the startup parameters? If you still have problems, a new logfile would be helpful:)

    Unfortunately, I forgot to mention that private messages are only available if your account is at least 5 days old (I think it was 5 days, but I'm not totally sure?/).

    Maybe Janine can make an exception for you, if you like.:)

    You can try to use another starting parameter, such as -windowedfullscreen and see if there are any changes.

    You can also tell us your hardware configuration (especially graphics card) and send a log file too. This could help us understand this case better.

    The only thing that came to my mind now is to do the following:

    Open your working directory from the map editor and navigate to the folder of your map and then to the "Export" folder.

    There you can sort the files according to their file size.

    For my testmap it looks like this

    The name of the largest .mtl file is now important because the first two numbers show you which tile it is.

    The first number is the position of the tile at the latitude, the second value is the position at the longitude.

    These values can be read in the map editor in the lower status bar.

    I'd come up with two things you might want to check out.

    First one is the type of material, but you will surely have it right.

    Second is the "Intensity of normal texture" maybe the value is still "0"?

    I hope this will help you, if not please post a screenshot of your material properties.:)

    Edit: Even another idea. There is also a setting on the Graphics tab. This option may not be enabled.

    Also there is one more thing: A Lexicon article mentoined that it is recommended to use smaller textures for the LOD modell. But then there will be 2 different textures stored in the VRAM, won't be? (Original and the smaller LOD texture)

    Therefore I would recommend to use mipmap in dds textures;)