Some questions relating to content creation for OpenRails Some anwers and advice needed..
#1
Posted 27 November 2019 - 11:02 PM
1. Does using a freight anim results in a draw call .... ?? Even if it uses the same material and texture as parent shape ... ??
2. For my next project, I am contemplating on using DDS format for my textures and reading various articles regarding DDS compression ... , However I am still confused regarding it.
For e.g. a 2048 DDS file is compressed 500kb on storage .., When it gets loaded in game and is PROCESSED by CPU and GPU ..., Is it still 500kb..?? Also finally when it gets LOADED on GPU VRAM what size would be it..?? Still 500kb ..?? Or it would be loaded uncompressed .., say at 2MB .. ??
3. Assume there are bunch of locos ..., All of which use SAME 4*4096 res textures ( DDS or ACE). However, In game all locos MAY or MAY NOT be their in same time in the scene. How does this sound from performance efficiency point ... ??
Any advice on above questions would be helpful ... :sweatingbullets: Also apologies if some of this question sounds naive... :o
#2
Posted 28 November 2019 - 04:52 AM
Hamza97, on 27 November 2019 - 11:02 PM, said:
1. Does using a freight anim results in a draw call .... ?? Even if it uses the same material and texture as parent shape ... ??
2. For my next project, I am contemplating on using DDS format for my textures and reading various articles regarding DDS compression ... , However I am still confused regarding it.
For e.g. a 2048 DDS file is compressed 500kb on storage .., When it gets loaded in game and is PROCESSED by CPU and GPU ..., Is it still 500kb..?? Also finally when it gets LOADED on GPU VRAM what size would be it..?? Still 500kb ..?? Or it would be loaded uncompressed .., say at 2MB .. ??
3. Assume there are bunch of locos ..., All of which use SAME 4*4096 res textures ( DDS or ACE). However, In game all locos MAY or MAY NOT be their in same time in the scene. How does this sound from performance efficiency point ... ??
Any advice on above questions would be helpful ... :sweatingbullets: Also apologies if some of this question sounds naive... :o
Hi Hamza,
I can only handle one - I can almost guarantee that each freight animation will spawn a new draw call...
In my software - I'm plagued with a legacy MSTS exporter - which tried to handle the issue with large parts in MSTS - so every 2800 Poly's I'm generating a new Draw Call on the same model... Fortunately - my freight cars which are the most numerous in any given scene don't usually exceed this limit on a single part... My locomotives make many unnecessary Draw Calls because of this... I wish I could figure out how to fix this - as efficiency is my thing... Shape Fixer will break down large parts into smaller if needed - but it won't assemble small parts into larger...
Regards,
Scott
#3
Posted 28 November 2019 - 08:13 PM
scottb613, on 28 November 2019 - 04:52 AM, said:
Scott,
I ask you, if not beg you to start using Blender. I am using it as an intermediate, and its uses are growing daily. Wayne has provided several exporters for MSTS from Blender. We can complain and hope as much as we want, but a new(er) shape file format for Open Rails is not going to happen anytime soon. The things that I do are complex and NDAs/Eulas get in the way. But I can say that the .obj format is your friend and loads nicely in Blender.
The Monogame version of Open Rails seems to be immune to "excessive" drawcalls. So if you have a decent/recent Intel/AMD desktop with the latest GPU, I would not worry about drawcalls, for the moment. If you intend to design a model with millions of polygons, well I have not tried that yet in Open Rails, but I can say your FPS will slow to a crawl because of it. Of course what I just wrote means, umm, you will use the 3DCanvas exporter, oh well I tried!
Steve
#4
Posted 28 November 2019 - 08:17 PM
Hamza97, on 27 November 2019 - 11:02 PM, said:
Really this is a question that James should (be able) to answer. Alas between Christmas and Brexit..who knows if he will. You can get some idea what you are doing with the full F5 debugger, once your model is built. It will tell you how much memory is being gobbled up, as well as how many "primitives" are being displayed. I would create a very bare and SMALL test route to find out what the impact of your model/textures is going to be. Are you using Blender and Wayne's exporter?
#5
Posted 29 November 2019 - 05:21 AM
Quote
Ok Thanks.... :sweatingbullets:
Quote
Blender 2.8 and Wayne`s exporter...
Quote
No of course not that much for a single loco... :blink: Around 200k max ... ^_^
Quote
I tried that but couldn't really infer from debugger any useful info.. :(
#6
Posted 29 November 2019 - 07:41 AM
Hamza97, on 27 November 2019 - 11:02 PM, said:
For e.g. a 2048 DDS file is compressed 500kb on storage ..,
When it gets loaded in game and is PROCESSED by CPU and GPU ..., Is it still 500kb..??
Yes, assuming they are DXT compressed, vs GZIPPED or some other compression.
Quote
Yes, still 500kb. GPU's know and understand the DXT compression format and can use these images directly without uncompressing first.
Quote
Sharing the same texture over multiple locomotives reduces GPU memory consumption , load times and tile load stutter, but such sharing doesn't necessarily improve frame rates.
If you plan to use large 4096 res textures, DXT1 compression will minimize the above mentioned impacts.
#7
Posted 29 November 2019 - 08:26 AM
Eldorado.Railroad, on 28 November 2019 - 08:13 PM, said:
I ask you, if not beg you to start using Blender. I am using it as an intermediate, and its uses are growing daily. Wayne has provided several exporters for MSTS from Blender. We can complain and hope as much as we want, but a new(er) shape file format for Open Rails is not going to happen anytime soon. The things that I do are complex and NDAs/Eulas get in the way. But I can say that the .obj format is your friend and loads nicely in Blender.
The Monogame version of Open Rails seems to be immune to "excessive" drawcalls. So if you have a decent/recent Intel/AMD desktop with the latest GPU, I would not worry about drawcalls, for the moment. If you intend to design a model with millions of polygons, well I have not tried that yet in Open Rails, but I can say your FPS will slow to a crawl because of it. Of course what I just wrote means, umm, you will use the 3DCanvas exporter, oh well I tried!
Steve
Hi Steve,
Hah - yeah - seems all roads lead to Blender... It's on my list - truly - it's just tough to give up "knowing what I'm doing" - to go back to a complete "newb" fumbling in the dark...
That said - out of all the North American content I've looked at over the years - I am one of the only ones that seem to be concerned with "draw calls" in their models - as it's pretty obvious when you look... I did a great deal of of performance testing and there are considerable performance gains to be had when you have a large number of optimized models in any given scene...
I have looked at the shape file in a text editor - seeing if I could figure out how to reassemble the pieces/parts manually - if I could - I could "Shell Script" a solution using Awk - - - but not much hope there - I couldn't find the definitive logical groupings...
I - must - download - Blender - - - again...
:p
Regards,
Scott
#8
Posted 29 November 2019 - 08:12 PM
Quote
I actually slightly modified Wayne`s exporter so that a new subobject is generated at 10,666 poly instead of normal limit as above ... :D The result is that even my locos have high polycount .., there Draw Call counts are roughly same as older low poly locos ... B)
Quote
Okie great ... ^_^
#9
Posted 10 December 2019 - 12:23 PM
Hamza97, on 27 November 2019 - 11:02 PM, said:
Yes, as it is a separate instance of the model to place into the scene.
Hamza97, on 27 November 2019 - 11:02 PM, said:
For e.g. a 2048 DDS file is compressed 500kb on storage .., When it gets loaded in game and is PROCESSED by CPU and GPU ..., Is it still 500kb..?? Also finally when it gets LOADED on GPU VRAM what size would be it..?? Still 500kb ..?? Or it would be loaded uncompressed .., say at 2MB .. ??
For all DDS files (and all DXT or uncompressed ACE files) the on-disk size is the same as the consumed GPU VRAM (and CPU RAM for XNA/DirectX 9).
The odd one out is ACE Zlib compression, which has to be uncompressed during loading, so it will consume the uncompressed size in GPU VRAM (and CPU RAM).
Hamza97, on 27 November 2019 - 11:02 PM, said:
As long as the texture is only one file (i.e. not duplicated on-disk), it will only be loaded into GPU VRAM (and CPU RAM) once.
#10
Posted 10 December 2019 - 12:46 PM
James Ross, on 10 December 2019 - 12:23 PM, said:
As long as the texture is only one file (i.e. not duplicated on-disk), it will only be loaded into GPU VRAM (and CPU RAM) once.
Rephrased: a texture file on a given path is loaded to VRAM just once. Put copies on n different paths and it will be loaded to VRAM n times.
On learning this (from James, of course) I have taken to moving instances of the same model skinned slightly differently tot he same folder. For example, I had 5 or 6 SFRD reefers that varied only by one texture (the one holding the car numbers) that were in individual folder5s. They're all in one folder now (\RS_SFRD_Rr30). I had to open each .s file and rename the unique texture as well as rename the actual texture (e.g., carside.ace to SFRD_32452.ace). The gain is now 5 or 6 other textures are loaded in VRAM just once where as before each one had been loaded many times.