Results 1 to 9 of 9

Thread: PolyCount in GeoPcDx

  1. #1
    sumitsingh Guest

    Default PolyCount in GeoPcDx

    Hi,

    I would like to ask that how can I see that any particular model is made up of how much polycount if it is possible?

    I have tried reading GeoPcDx of Class 40 40145 Steam Edition by RailRights, this locomotive eats up all my fps.

    I also have designed a 80,000 polycount locomotive and used LOD 1, 2 and 3 properly and it never cause any drop in fps.

    I have i5 7th gen and 940M Nvidia card 4GB.

    Thanks
    Last edited by sumitsingh; 01-18-2018 at 06:30 PM.

  2. #2
    Join Date
    Nov 1999
    Location
    Another Planet
    Posts
    8,618

    Default

    Quote Originally Posted by sumitsingh View Post
    I would like to ask that how can I see that any particular model is made up of how much polycount if it is possible?
    For this, you’ll need to contact the author(s).
    3DTrains - Home of the Feather River and Sherman Hill routes for MSTS

    Signature

  3. #3
    Join Date
    Apr 2007
    Location
    Swindon, England
    Posts
    4,731

    Default

    ISTR the Class 40 (which is an excellent model) relies heavily on custom scripting for all the features. This may be putting the load on system resources, more than the poly count.
    Vern.

  4. #4
    sumitsingh Guest

    Default

    Quote Originally Posted by Hack View Post
    For this, you’ll need to contact the author(s).
    Ok, I will contact them.

  5. #5
    sumitsingh Guest

    Default

    Quote Originally Posted by NorthernWarrior View Post
    ISTR the Class 40 (which is an excellent model) relies heavily on custom scripting for all the features. This may be putting the load on system resources, more than the poly count.
    The DTG document on How to script an locomotives also says Scripting much is not resource friendly.

    Will contact developers regarding it.

  6. #6
    Join Date
    Apr 2007
    Location
    Swindon, England
    Posts
    4,731

    Default

    Quote Originally Posted by sumitsingh View Post
    The DTG document on How to script an locomotives also says Scripting much is not resource friendly.

    Will contact developers regarding it.
    Not being funny though, what do you hope to achieve by that? These models are specifically aimed at a particular end user who is prepared to take the performance trade off that advanced scripting requires. They're not likely to issue a cut down version of the add-on nor are they likely to be willing to share trade secrets (such as the ploy count) either...
    Vern.

  7. #7
    sumitsingh Guest

    Default

    I thought that only heavy polycount might eats the FPS, I had no idea earlier that heavy scripting is also a major reason for the loss of resource.
    There is no way they are going to make a cut down version.
    I need to increase my RAM.

    When I had closely examined the Locomotive, I thought earlier about LOD being the culprit, as I am developing a loco which have reached 80,000 polycount so I was a little worried about performance.

  8. #8
    Join Date
    Jun 2004
    Location
    Hastings, MN, 55033
    Posts
    3,604

    Default

    About triangle counts and performance... they matter, but not the way you'd think they do. It's not a direct relationship. Triangle counts matter in that more triangles means more vertices. Your big enemies when building a model are vertices and drawcalls. The problem is that it's easy to end up with a lot of both, and most developers prefer not to do any work that doesn't directly contribute to a render of the model that looks impressive on the product's website.

    The way you get rid of excess vertices is by welding UV coordinates, smoothing parts with hard edges that don't necessarily need to be hard (sometimes, you can hide the lack of a hard edge with a texture, generally only in dark areas, though), and mapping the model to use the fewest UV coordinates in the first place (i.e. use a small number of big maps so parts don't have to be split up as much). The way you decrease drawcalls is by using a minimum number of materials (a small number of large maps instead of the converse) and minimizing the final number of parts to the absolute bare minimum required for animations. This final process is called drawcall batching, and some exporters do it automatically (MSFS), while others do not (MSTS). I don't know if the RW exporters do or not.

    Combining parts that have different materials, of course, does nothing to reduce the drawcall count... which is yet another reason why a small number of big textures is a good idea. It can get a bit more complex than that depending on how the simulation handles those drawcalls, of course (i.e. does each drawcall equal a separate instance of a texture file loaded, in which case animated parts might best be grouped in smaller textures, since you're loading a separate instance anyway, and smaller images eat up less memory). And every time you add another map to a material (such as a specular map, normal map, reflection map, Fresnel map), you've added another drawcall... to be multiplied by the number of discrete parts that use that material.

    Honestly... vertex count is the bigger one, but drawcalls are still not insignificant. The best example I can give of vertex counts is not a train sim one, so bear with me, but, as an example, I've purchased both the MilViz and CaptainSim examples of the 737-200 for FSX. The CS 737 has 490 drawcalls, 180,626 triangles, and 177,332 texture vertices. The MilViz 737, by weight of comparison, has 425 drawcalls, 276,908 triangles, and 278,683 texture vertices. Both models have a similar number of texture files, taking up a similar amount of memory. Which model runs significantly slower? The latter. Which model has fewer drawcalls? The latter. Which has more texture vertices? The latter. But I have run models with similar triangle counts where one has a whole lot of tiny textures and the other has a small number of big textures, and there was a clear performance difference with the latter model running much faster.

    That said, scripting is a whole 'nother ball of wax... but if you want more than a superficial simulation, you've got to write custom scripts. It's the developer's particular problem of the compromises between performance and accuracy. Sometimes, you don't want to compromise on accuracy, and that means you need a more powerful system. But, of course, optimization is still an important part of the process...

  9. #9
    sumitsingh Guest

    Default

    Thanks.
    Last edited by sumitsingh; 02-08-2018 at 07:36 PM.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •