Results 1 to 9 of 9

Thread: Question About Removing Objects

  1. #1
    Driverman2008 Guest

    Default Question About Removing Objects

    If you remove a significant amount of scenery objects on a route (vegetation, automobiles, etc) in Railworks, will this make the framerate smoother and save space on your hard drive?

  2. #2
    Join Date
    Nov 1999
    Location
    Stevens Point, Wisconsin, USA.
    Posts
    14,705

    Default Nope.

    Even if you delete a bunch of stuff from an MSTS route on your system, how would that save space on MY hard drive? Actually it won't save any space on yours either, unlike MSTS this aliases all objects from the \Assets folders, so the scenery files in the routes themselves are really small. As for improving framerates, yeah, depending on what you delete you may see some increase. Constant challenge for route developers is to try and pack in as much eye candy as possible without tanking the framerates on low end machines.

  3. #3
    Driverman2008 Guest

    Default

    So even if I have a million objects in view (OK, maybe I'm exagerating), it won't make a difference as to having none? That's odd. I thought every tree, every hill, and every train take up space on your hard drive no matter where they are located.

  4. #4
    Join Date
    Nov 1999
    Location
    Stevens Point, Wisconsin, USA.
    Posts
    14,705

    Default Sort of



    Open one of the scenery folder bin files that's what a datablock for an object looks like, if you delete the object from the route that datablock would be removed from the bin file, making it maybe 3 bytes smaller. The object itself is still in the \Assets\Kuju\railsimulator\scenery\buildings folder, it don't delete that which is good since the same object is used multiple times in multiple routes. Only thing I can suggest is copy whatever route you want to hack to a backup folder, then try deleting 782 zillion (give or take a trillion) trees, then compare the sizes. Probably a couple hundred kilobytes or so, IIRC the testing I did when I first got railsim showed that the terrain (hills and valleys) and mixmap (terrain textures) folders were the largest space hogs. If you're hurting for disk space you could zip up some of the routes you don't use and stash them on a CD-RW or something, you're not gonna gain much by committing scorched earth warfare on any of the routes. Framerates, yeah, but disk space not a significant change.
    Attached Images Attached Images
    • File Type: jpg 0.jpg (83.8 KB, 99 views)

  5. #5
    Join Date
    Aug 2007
    Location
    Delmont, PA USA
    Posts
    2,113

    Default

    The hard-drive has a master copy of this stuff under the various ASSETS. Thus each scenario/route that uses the data only gets an address pointing to the ASSET copy. The problem arises when your poor little home PC has to show you all those trees, building, etc.

    I may be wrong on this, but I think that even the grouped trees are actually individual elements probably with links, pointers, aliases to each individual tree. Thus more disk activity to get a group of trees. Making the group a new single object may prevent fancy movement by the gizmo so they had no choice but to just reference each tree in the group back to the original.
    Regards - Dick
    i5 2500K$ 4.2ghz, GTX 750 2gb, 8gb of SkillFULL memory, A 700 watt power thingy, lots of cables
    Program to take screenie weenys from da puter. Bro, Dude, Man operator Murysville,Pa.



  6. #6
    Join Date
    Nov 1999
    Location
    Stevens Point, Wisconsin, USA.
    Posts
    14,705

    Thumbs up You're right!

    You're right about being wrong, that is. Way to find out stuff like that is to try it and see, holler

    FIRE IN THE HOLE!!

    And see what happens. Make a new route, place a tree clump, save and exit, got a 2 kilobyte scenery bin file with only one reference in it to the tree clump object. Make another new route, place 30 or 40 trees (too lazy to count the actual number in the clump so I guesstimated) and you get a 12 kilobyte scenery bin file with that (30 or 40) number of repetitions of the same reference datablock. On my 64k TRS80 with 360 kilobytes of storage, 8 or 10 k would have been a major factor, but on a 120 gigabyte disk I don't think it's a factor. Might make a difference in loading speeds and/or framerates with a clump since it only needs to load one object instead of 36 (or whatever), but polygons is polygons so it probably wouldn't make much difference even on this old Dell clunker.


    "If we knew what it was we were doing, it would not be called research, would it?"
    Albert Einstein



  7. #7
    Join Date
    Aug 2007
    Location
    Delmont, PA USA
    Posts
    2,113

    Default

    If the entire group of hickeys was converted to a single polygon then the loads needed drops. The processor time is reduced as well. As you gizmo the group it also becomes a bit slower, but not painful. Just my guess is that groups are just that, referenced things each with its own x,y,z positioning. They are not a single entity. Guess you could say that a group of things is virtual.

    Once again that is my guess. Humble pie is in the oven.

    Now half-way toward the 3rd day of being Steamed - no service.

    Downloaded some photoscenery for Alaska/X-Plane but it did not look good. Back to haunting ISP and Steam forums.
    Regards - Dick
    i5 2500K$ 4.2ghz, GTX 750 2gb, 8gb of SkillFULL memory, A 700 watt power thingy, lots of cables
    Program to take screenie weenys from da puter. Bro, Dude, Man operator Murysville,Pa.



  8. #8
    Join Date
    Nov 1999
    Location
    Stevens Point, Wisconsin, USA.
    Posts
    14,705

    Lightbulb Yes no maybe sometimes it depends

    Actually you haven't been STEAMed, you've been COMCASTed! But don't get me started on them, I had Comcast the last 10 years I lived in Chicago, which is why I had Ameritech DSL instead of cable.

    Well, let's stick a fork in that humble pie, see if it's done yet.

    In that scenery bin file on the test route I only have one reference datablock pointing at \Kuju\RailSimulator\scenery\Vegetation

    Says it's looking for Tree_Beech_01_Mid.xml, but it's really looking for Tree_Beech_01_Mid.bin. Open that, says the geometry is

    <GeometryID d:type="cDeltaString">Kuju\RailSimulator\Scenery\V egetation\[00]Tree_Beech_01_Mid</GeometryID>

    Same folder, and if it's geometry it must be Tree_Beech_01_Mid.GeoPcDx. Inside that;

    <TextureByName>
    <e d:type="cDeltaString">textures\[0d]tree_beech_01</e>
    </TextureByName>


    Okay, so look in the textures folder for tree_beech_01, being a texture the actual filename would be tree_beech_01.TgPcDx.



    That's what that looks like, only one texture file, how do they paint all the parts on? My guess would be this;

    <FloatParam>
    <cHcEffectMaterialDx-cFloatParam d:id="286847448">
    <Name d:type="cDeltaString">SPECULARPOWER</Name>
    <Value d:type="sFloat32" d:alt_encoding="0000000000000000" d: precision="string">0.0000</Value>
    </cHcEffectMaterialDx-cFloatParam>
    <cHcEffectMaterialDx-cFloatParam d:id="286847460">
    <Name d:type="cDeltaString">CUSTOMPARAM0</Name>
    <Value d:type="sFloat32" d:alt_encoding="0000000000000000" d: precision=string">0.0000</Value>
    </cHcEffectMaterialDx-cFloatParam>
    <cHcEffectMaterialDx-cFloatParam d:id="286847472">
    <Name d:type="cDeltaString">CUSTOMPARAM1</Name>
    <Value d:type="sFloat32" d:alt_encoding="0000000000000000" d: precision="string">0.0000</Value>
    </cHcEffectMaterialDx-cFloatParam>
    <cHcEffectMaterialDx-cFloatParam d:id="286847484">
    <Name d:type="cDeltaString">CUSTOMPARAM2</Name>
    <Value d:type="sFloat32" d:alt_encoding="0000000000000000" d: precision="string">0.0000</Value>
    </cHcEffectMaterialDx-cFloatParam>
    <cHcEffectMaterialDx-cFloatParam d:id="286847496">
    <Name d:type="cDeltaString">CUSTOMPARAM3</Name>
    <Value d:type="sFloat32" d:alt_encoding="0000000000000000" d: precision="string">0.0000</Value>
    </cHcEffectMaterialDx-cFloatParam>
    <cHcEffectMaterialDx-cFloatParam d:id="286847508">
    <Name d:type="cDeltaString">CUSTOMPARAM4</Name>
    <Value d:type="sFloat32" d:alt_encoding="0000000000000000" d: precision="string">0.0000</Value>
    </cHcEffectMaterialDx-cFloatParam>
    <cHcEffectMaterialDx-cFloatParam d:id="286847520">
    <Name d:type="cDeltaString">CUSTOMPARAM5</Name>
    <Value d:type="sFloat32" d:alt_encoding="0000000000000000" d: precision="string">0.0000</Value>
    </cHcEffectMaterialDx-cFloatParam>
    </FloatParam>


    Dunno what all that means, but it looks like the kind of code that would be used to paint different parts of the same object. So what's it look like if I move the textures folder out?



    Looks like a single object to me, got one bin file, one shape file, one texture file, altho like several objects it also aliases an invisible texture from elsewhere.

    As for performance, that's really difficult to say - back in the '80s I tried twice making a train simulator (weren't any available), once in GWBASIC and again a few years later in Visual Basic for Windows 3.1. The Visual Basic version was merely a series of bitmap images that the program flipped thru like one of them cartoon drawing books, on a Tandy 1000TX 16mhz with a 20 megabyte hard drive it took up a lot of space and didn't run very smoothly. In 2001 I bought MSTS, had an AMD K6-2 450mhz, and while cleaning out old files to give the system to my son so he could play trainsim (I built an AMD Tbird 800mhz for myself, Daddy gets a new toy Mikey gets the old toy), I ran across that unfinished VB trainsim I had made 15 years earlier. Wow. Clumsy program, but running on a 450mhz PII class instead of a 16mhz 80286, it sure LOOKED smooth! Of course at that time it was way outdated and I had MSTS, so I deleted it. So that's the trouble with trying to analyze this type of thing, is a single tree clump better for framerates than 3 dozen individual trees? If you got a Screamer 3000 nuclear powered turbocharged octo cored system, how would you be able to tell the difference?
    Attached Images Attached Images

  9. #9
    Join Date
    Aug 2009
    Location
    Florida
    Posts
    180

    Default

    Whats the issue here though?.

    Disk space?
    Or Frame rate??.

    So far, its correct to say that all the routes use pointers / referances to assets.
    In stead of there being a tree model in the route folder, there is a "1".
    that "1" refers to a tree model in the Assets folder.
    the upshot of this is.. you only need one Tree model for XXX number of routes.
    This means the amount of disk space used to store the route is very small indeed. It can be loaded very quickly, or even buffered. Since its only throwing referance flags into the system.
    Now, once the render engine gets hold of it, it has to take those referances and load the model in its stead.
    (since it takes x bytes to store a "1" and xxxx KiloBytes to store a tree.)

    So the "1" is read from the route file, its passed to the game engine, and the game engine says 'ah, a "1", thats a tree... ' and loads the tree model from the assets.

    There is one issue here.
    If you dont have that tree model in your assets.. then your going to get those fun missing texture signs.
    Which means... if your making a route for the public, you have to be careful not to use any Addon material.... Or make it understood that you need the Expantion to use the route.

Posting Permissions

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