Audi R18 2012 - Wip (no release)

Discussion in 'Vehicles' started by tommy86, May 11, 2012.

Thread Status:
Not open for further replies.
  1. Vince Klortho

    Vince Klortho Registered

    Joined:
    Oct 5, 2010
    Messages:
    91
    Likes Received:
    1
    No it is not. It is an example of a poorly optimized mod. If one can not race with a realistic grid of 50 cars at practically any course then it can not be considered well optimized. I can't even run it with 40 cars at most courses.

    It's really not even an issue of the poly (or triangle) count either. The main issue is texture memory usage. They used way too many large texture images which could have been smaller. This is a problem I have seen with several mods lately. The cars look great, they really do, but the texture usage is very inefficient.
     
  2. tommy86

    tommy86 Registered

    Joined:
    Jan 10, 2012
    Messages:
    161
    Likes Received:
    4
    You have any suggestion regarding max overall texture size (in MB) to consider it good?

    Thanks
     
  3. ethone

    ethone Registered

    Joined:
    Nov 30, 2011
    Messages:
    1,153
    Likes Received:
    37
    It is hard to put a definite number on it as you'll be modelling for a moving target. But consider what amount of VRAM graphics cards have. 512MB is probably what at least 95% of users have. I'd guess 50-70% have 1GB or more.
    For 512, take 100MB off for the track, another 50 for the sim, objects you haven't accounted for or just a safety buffer. That leaves you with about 360MB to "spend" on cars. To be able to run 50 cars on a 512MB card each car should weigh in at a maximum of 7.2MB.

    With the Enduracers mod I just checked the Peugeot and as a whole single car it would require 27MB just for textures. I can run about 34 cars of that mod at the same time and 27*34 comes out at 918MB, which is surprisingly close to the 1024MB of VRAM my card has. I'm not sure if they actually assigned all the basic textures (lights, underbody, cockpit, ...) to each and every iteration of the car but it would appear so from my first glance. From car to car keep the material name the same for non-entry-specific textures (like the underbody, that should be the same for all cars and drawn from a single .dds, not a separate one for each entry).

    When talking about efficiency we should look at different stuff than "just" the total memory print of a car. I believe many cars use textures wildly inappropriate for the area they're used on. The Enduracers mod uses a 1024x1024 texture for the driver. Now when exactly will the camera be close enough to to the driver (who is inside the car, obscured for the most part anyway) that it fills at least half your vertical resolution? The upper body part of the texture stretches 512 pixels vertically.
    At a screen resolution of 1920x1080 for that texture to make sense, the upper body would have to fill half your screen for anyone to make use of the resolution of the supplied texture. Great for the 1 out of 5000 races when it happens, but still a memory hog for all the remaining time.
    So perhaps as a guideline - only use textures to the size that they're likely to be on the screen. 4048x4048 body textures aren't providing any benefit until the car fills the screen vertically and you zoom in 4x.


    Perhaps KS would like to write something up as there's a fair bit I'm not sure about and I'm sure he is. ;)
    How do cards handle e.g. DX1 and DX5 .dds files, is there a difference in memory usage or is that only on the hard disk? I did a small experiment on that and didn't gain any FPS, but then my test case wasn't really VRAM limited.
    How big is the impact of the geometry to VRAM, is it a 1:1 ratio of .gmt size to VRAM usage?
     
  4. Johannes Rojola

    Johannes Rojola Registered

    Joined:
    Sep 8, 2011
    Messages:
    1,038
    Likes Received:
    38
    Are you calculating those usages from DDS file sizes or uncompressed RGB sizes?
     
  5. ethone

    ethone Registered

    Joined:
    Nov 30, 2011
    Messages:
    1,153
    Likes Received:
    37
    I calculated those from the DDS file sizes but as I noted in my last paragraph I'm no expert on how graphics cards handle the dds files. If you've got more info on that please share.
     
  6. Johannes Rojola

    Johannes Rojola Registered

    Joined:
    Sep 8, 2011
    Messages:
    1,038
    Likes Received:
    38
    I've *heard* that textures are calculated in uncompressed RGB, but that can't be true because we would get bottlenecks quite fast. Of course mipmaps decrease the usage of memory, but still... sounds suspicious. For example single 2048x2048 texture would be 12mb.
     
  7. tommy86

    tommy86 Registered

    Joined:
    Jan 10, 2012
    Messages:
    161
    Likes Received:
    4
    Many thanks for deep explanation ethone. i tried to keep all DDS files as low as possible, and no one of them is bigger than 512*512px and lots of small textures at 256px.

    One more question about textures...is it better to have xx small textures or less but bigger? e.g. 3dsmax works better with 1mil polys object comparing to 1000 objects with a total 1mil polys. Is there something similar on rf?

    Thanks
     
  8. Johannes Rojola

    Johannes Rojola Registered

    Joined:
    Sep 8, 2011
    Messages:
    1,038
    Likes Received:
    38
    Again I've heard multiple times that it is better to use fewer large textures than a large bunch of small. And then again in practice I see everything made out of little shattered mess - including ISI cars. So I don't know to be honest, to hell with this :D
     
  9. Luc Van Camp

    Luc Van Camp Track Team Staff Member

    Joined:
    Oct 4, 2010
    Messages:
    1,030
    Likes Received:
    14
    It is seriously recommended to keep the material count as low as possible. If you have some UV space left on a texture that is using the same shader as the piece you're working on, don't create a new texture for it, just for the sake of having an extra texture :) .
    The gMotor processes triangles using the same material in one single trilist (if you're using gMotor normals that is). This is MUCH faster to process than multiple trilists. In essence, by keeping the material count optimized, you limit the overhead when the engine has to process the trilists. Using Max normals is also not recommended for the very same reason.
     
  10. ethone

    ethone Registered

    Joined:
    Nov 30, 2011
    Messages:
    1,153
    Likes Received:
    37
    Also, you can get 3ds max down to its knees quickly if you use too many materials, but that's mostly a track modders problem. If you're getting close to that threshold on cars you'd be doing something majorly wrong. ;)

    As Luc said, keep as many textures/UVW mapping areas that use the same shader and material settings within a single texture map.
     
  11. K Szczech

    K Szczech Registered

    Joined:
    Oct 5, 2010
    Messages:
    1,720
    Likes Received:
    45
    Sometimes it's nice to have details on driver - so we can make screenshots like this one:

    [​IMG]

    As for performance - this is where mipmapping helps. If model is further away, then largest mipmaps won't even be accessed by GPU. Smaller mipmaps will be used and this means performance will be exactly as if you used smaller texture.

    So your only concern is memory consumption on GPU.

    It could be a good idea to use low-res driver suit textures to give suits some general appearance, with high-res add/mult maps to add details like stitchers or zippers on top of it. This way you will hav multiple low res textures and only one or two high res textures for all drivers.
    You could also map these base low-res textures more densly on the chest so painters would be able to put some decent sponsor logos there.

    .dds files are pretty much in format they're stored in GPU memory. That's why this file format is also called "DDS fastload image".
    When you load some popular file, like .TGA, it needs to be uncompressed first, then you send it do driver, which compresses it to DXT format and generates mipmaps. With .dds file you simply send it to GPU and no compression needs to be done.

    Except for some bytes that go for header, dds files are pretty much 1:1 when comes to memory consumption.

    As for geometry - vertex arrays are stored on GPU, but GMT file contains more than vertex arrays. There are materials and some other stuff there (for collision detection).
    So if you make a box with 6 materials (one for each side) you may end up with much bigger .GMT file than for a 1k poly mesh with just one material, but box will definitely occupy less space in GPU memory.

    The best way of estimating memory needed to store geometry is to multiply number of triangles and vertices by given factors.
    Each triangle takes 6 bytes in memory
    Each vertex takes from 32 to 80 bytes (32 when you only have one uv set and no normalmap, 80 when you have a normalmap and 4 uv sets).


    Keep in mind that deformable objects (car body) cannot share one vertex array. So non-deformable parts of car may share the same vertex array with other cars (although I'm not sure if they do in rFactor - I'm only saying they can), but deformable parts cannot.
     
    Last edited by a moderator: May 16, 2012
  12. ethone

    ethone Registered

    Joined:
    Nov 30, 2011
    Messages:
    1,153
    Likes Received:
    37
    Thanks for that K.

    Some follow up questions: When you say GPU, do you mean load on the GPU, bandwidth within the GPU system (processing and reading from memory) or do you mean VRAM usage?
    When I use a 1024x1024 dds file that has to be loaded into VRAM with all its mipmaps, correct? Doesn't any performance gain from mipmaps stem from the GPU having to process a smaller file (and less bandwidth usage on the way from the VRAM to the GPU?), but not from there being a smaller memory footprint?


    As for details on the driver - sure there can be a "use" of it for taking screenshots with a camera half a meter from the driver. To me that's unnecessary bling that's beside the point in a sim. In the case of the Enduracers mod it keeps me from running more cars. For what benefit? For being able to take nice screenshots in replays that have no effect whatsoever on actually driving the mod?
     
  13. Johannes Rojola

    Johannes Rojola Registered

    Joined:
    Sep 8, 2011
    Messages:
    1,038
    Likes Received:
    38
    I agree, this is just stupid. I didn't know that Endurances was so badly optimized, then again I usually ran only like 10 cars max. Guess I thought that because it was big, successful mod from established mod team such fundamental stuff like optimization was done like should. Apparently not :rolleyes:
     
  14. ethone

    ethone Registered

    Joined:
    Nov 30, 2011
    Messages:
    1,153
    Likes Received:
    37
    As a practical example: I just reduced the driversuit textures of the cars I enabled for my Enduracer's mod and could go up to 37 AI cars from the previous 33. After adjusting some of the maps (including a 1024x1024 map for the pedals!) inside the .mas files I managed to eke out another 3 cars to go as high as 40 AI cars.

    And as a final note on the mod: I love the Enduracer's mod. It's the one mod I'm still using for testing rF1 tracks.
     
  15. Marek Lesniak

    Marek Lesniak Car Team Staff Member

    Joined:
    Oct 6, 2010
    Messages:
    1,583
    Likes Received:
    101
    So, you still think it's mod related issue and not your PCand/or rfactor? Oh, well... :rolleyes:
     
  16. Johannes Rojola

    Johannes Rojola Registered

    Joined:
    Sep 8, 2011
    Messages:
    1,038
    Likes Received:
    38
    If pedal textures are 1024 like he suggested, that is a mod issue.
     
  17. ethone

    ethone Registered

    Joined:
    Nov 30, 2011
    Messages:
    1,153
    Likes Received:
    37
    Meh, let him believe I run a 486 with a 3dfx card and create mods nobody but him can use. I'll survive. ;)

    If you're bored and forum trolling isn't your choice of the day, look at the mod with your own eyes LesiU.
     
  18. tommy86

    tommy86 Registered

    Joined:
    Jan 10, 2012
    Messages:
    161
    Likes Received:
    4
    1024px texture for pedals is such an epic fail :D
     
  19. K Szczech

    K Szczech Registered

    Joined:
    Oct 5, 2010
    Messages:
    1,720
    Likes Received:
    45
    When I say GPU i mean graphics card :) What precisely I mean in each case shuld be obvious from context. When I talk about performance, then of course I mean bandwidth, when I say about storing something in memory, then I mean memory amount.

    Smaller textures will improve loading times and decrease amout of memory needed on GPU. But as for bandwidth (and therefore rendering performance) it makes no difference unless you get close to an object and high-res mipmap is actually used.

    Of course if textures exceed memory you have onboard your GPU you will suffer further performance drop, but that's a different story.

    Optimizing a model for computer game requires some knowledge on how game engines and GPU's work. Unfortunately that's not the kind of knowledge you'll find in 3DS MAX tutorials.

    Many modders still think that polycount is the key to performance and object and material count doesn't matter at all.



    I've done a quick test once. I had a track running 180-190 FPS.

    Now I've made a mesh - 1000 cubes covered with some simple material. This means 6000 quads = 12000 triangles.
    I've put that mesh on my track - and it was still running 180-190 FPS when I looked at these cubes. Yup, 12k polys eaten up by my modest 450GTS like it was nothing.

    Now I've put each one of these cubes in separate GMT file. So now I had 1000 GMT files with one cube each. All of them had the same material, but when I looked at these cubes my framerate dropped to 110 FPS.
     
  20. ethone

    ethone Registered

    Joined:
    Nov 30, 2011
    Messages:
    1,153
    Likes Received:
    37
    It's not the kind of knowledge you'll find in rF tutorials either. And it's fairly technical. All the better that people like you share their knowledge. Thanks again! :)
     
Thread Status:
Not open for further replies.

Share This Page