OR & Polygon limits.

[Shortliner]

I know the original stock MSTS had a polygon limit, but I'm wondering if Open Rails have the same limit, or can it accept higher res. models?

[eric]

I've yet to find an upper a limit, and I have built several scenery objects well over 12,000 polys....

[superheatedsteam]

As a test, I created a loco with 330,000 triangles. OR loaded 2 of these locomotives at the head of a train and ran with no problems.

[pwillard]

I did not skimp on details for my recent Tank Car upload, I don't see why I need to adhere to MSTS limitations if ORTS isn't making me do so.

[jmicheel19]

Well, I know TSRE5 can get a bit glitchy with high quality textures, (example: 2048 textures) but I haven't heard of a railcar limit yet. It would appear that its kinda just based on what your computer can handle.

[scottb613]

Hi Folks,

Yeah - initially MSTS would start throwing artifacts on models around 10,000 or 11,000 polys. I never really noticed if BIN improved that - as I was an early adopter of ORTS.

Derek Millers steam locomotives exceed 70,000 or 80,000 without issue - with long trains - on detailed routes - with multiple locomotives.

Multiple 2048 textures on steam locomotives are now the norm for me - without issue - I use 1024 on freight cars.

As someone who's tested ORTS performance extensively - the biggest frame savers are using model LOD's (especially on freight cars) (yes you can make the transitions seamless) and minimizing Draw Calls. It's better to use a single larger texture in place of many smaller textures.

Regards,
Scott

[muskokaandtahoe]

Scott is right about the draw calls. At a minimum there is going to be one draw call for every texture file. A draw call is a hardware interrupt so by definition each one is going to slow things down. If your texture has an alpha that'll add another draw call. If you assign a material type (e.g., loshine) that'll add another. If you use a texture in multiple named parts add 1 for each part. In the later case things can really add up quickly.

Don't export more named parts then are required. That may mean keeping a "construction version" on hand and a simplified export version where the optional named parts have been exploded. You might be able reduce the draw call count by making a texture specific for the named parts from the several textures you thought you'd use. In this case because there is going to be a draw call for the named part the "extra" texture file goes for free.

You can check your draw call count in Shapeviewer. Go to the view hierarchy and count the yellow and brown boxes. The sum is your draw calls.

[scottb613]

Hi Folks,

Just to provide a piece I remembered - MSTS got around the 10,000 or 11,000 poly limit with the use of “sub-objects” - breaking the model down into manageable bites for MSTS. The exporter in 3DC handled this automatically for us while I think the others needed that PolyMaster program to do it.

Regards,
Scott


Sent from my iPad using Tapatalk

[EldoradoRailroad]

As a matter of experience, the 3DC exporter breaks things down in sub, subobjects that are about 3000 polygons, BUT....be aware that the top most subonject in your hierarchy should have no more that 32000 polygons (for OR) and in my experience that should be less than 32000 per subobject.

Wayne Campbell's Blender exporter does not break things down into sub, subojects like 3DC. But the 32000 polygons per subobject limit is still there and his exporter automagically creates a NEW sub, subobject as needed with far fewer draw calls. If you are so inclined you can modify the Blender exporter python script so that the subobject creation "trip" points are different.

In english, I do not recall how many subobjects are permitted in OR per shape file, but doing simple arithmetic 10 subobjects X 32000 is a lot of polygons! By all means, create a test shape with many subobjects and 32000 per subobject. Enjoy OR crawling with your million(s) plus polygon shape file!

Steve

[pwillard]

Enjoy OR crawling with your million(s) plus polygon shape file!

Just adding here that there is no need to be snarky. OR is way better than MSTS about polycounts... let's celebrate that fact and not be ugly about it.