Procedural track shapes Get rid of GLOBAL
#21
Posted 13 June 2017 - 01:00 PM
#22
Posted 13 June 2017 - 01:37 PM
longiron, on 13 June 2017 - 12:24 PM, said:
If you move forward on procedural track shape generation, can you fix the problem with MSTS curve shapes laid on a gradient. The result is misalignment between successive curved track sections (especially 3/4 track sections) for the inner or outer rail. The net result is very uneven and jumpy track. If you need to understand the problem in more detail, WaltN can explain the issue and resolution. I can certainly illustrate the problem on a route.
Thanks in advance
chris
This should not be an issue, the displayed track shape is generated a small length at a time (Note 1) from the centre line of the track as specfied in the track data base and from the file containing the tracks description (gauge, rail weight sleeper and ballast type etc), so everything should line up.
TDB issues SHOULD not crop up as I assume what Goku's is doing is to generate the required TDB data when one lays out the track in the route editor, so the ONLY thing changing is the way the track is displayed.
Note 1: I have done the track (and embankments) this way in my own train sim, although I do the switching using normal shape files, as this simplified the coding no end Note I do not know how its is done in other parts of the world but in Victoria (Australia) almost all new swiching (and all old switching) is done with standard components almost exaclty like a trainset, so using track shapes for switching is not a real issue
Lindsay
#23
Posted 13 June 2017 - 01:57 PM
Earlier in this thread an OR developer said there were few active route developers, this does appear to be true. The reason's are..............
(Lindsay gets on soap box..................) :)
MSTS is seen is old hat
MSTS's editor and and tools do not run well on latte versions of Windows.
MSTS's editor and tools are diffciult to use as is.
OR itself does NOT at this stage have a route editor.
OR REALLY requires a route editor now, the justification that we will not work on a route editor as few are using it is SELF DEFEATING and is a sure way to destroy OR on the long run.
Lindsay
#24
Posted 14 June 2017 - 12:48 PM
Goku, on 13 June 2017 - 11:15 AM, said:
http://imgur.com/CzKPKZc
Loading similar complex .S shape file from SSD is > 20 ms. And TSRE loading time is fast - you see how fast routes are loaded into TSRE.
I think it is because files on disk are compressed and ZLIB decompression takes some time. Also .S files have lots of unnecessary things for simple shapes you need to load.
No, I don't see fast loading is TSRE. I wait 15-20+ seconds to see some scenes load.
As I said before, the OR loader thread is different from the game loop / rendering. The loader thread bears the burden of slow disk access, not the game loop. Your whole premise is based on the wrong idea.
Don't get me wrong tho, I support procedural track for route builders (tho not at all what you have in mind). But I strongly suspect the only way there can be a performance gain in-game is if it substantially reduces the draw calls relative to what one sees with instancing turned on. Logically speaking it should reduce the draw calls... but will it be enough to make a difference? Hopefully so. But the disk stuff is (IMO) a non-issue.
How do you intend to apply UV mapping to your procedural track?
#25
Posted 14 June 2017 - 01:28 PM
Genma Saotome, on 14 June 2017 - 12:48 PM, said:
Is it from HDD? If yes, then you have to change multithreading options, because TSRE is configured for SSD by default. But default options kills HDD :)
Genma Saotome, on 14 June 2017 - 12:48 PM, said:
Loader can't use many threads because of disk limitations. Procedural generator can use any number of threads. What is wrong with my idea?
Genma Saotome, on 14 June 2017 - 12:48 PM, said:
It is very big issue. All game engines use one blob file by default. But many engines support "unpacked" files (for content developers) like MSTS/OR and in this case there is massive performance drop when loading assets. SSD is not a perfect solution, because SSDs have bad performance with small files (like msts .s, .sd files).
Genma Saotome, on 14 June 2017 - 12:48 PM, said:
My procedural objects are based on 3d shapes. You configure UV in blender or 3dsmax like for other 3d objects. "Stretchable shapes" like rails or ballast should be made 1 m length. Next UV coords are calculated based on actual length and coords from 3d shape.
#26
Posted 14 June 2017 - 07:55 PM
Genma Saotome, on 14 June 2017 - 12:48 PM, said:
..........................................SNIP...........................................
Hi Dave,
It's 4.5 seconds to load the PRR-East route from my systems SSHD (E drive)
Date/time = 6/14/2017 2:43:41 PM (2017-06-14 21:43:41Z) BIOS = V1.11 (American Megatrends Inc.) Processor = Intel(R) Core(TM) i5-4430 CPU @ 3.00GHz (4 threads, 4 cores, 3.0 GHz) (CPU Internal L2 1024 KB) (CPU Internal L1 256 KB) (CPU Internal L3 6144 KB) Memory = 7.9 GB Video = NVIDIA GeForce GTX 650 (1.0 GB RAM) (nvlddmkm 21.21.13.7653) Display = \\.\DISPLAY1 (1920 x 1080, 32-bit, primary, 0 x 0) Display = \\.\DISPLAY2 (2400 x 1350, 32-bit, 2400 x 0) Sound = Realtek High Definition Audio (rtkvhd64 6.0.1.7111) Sound = NVIDIA High Definition Audio (nvhda64v 1.3.34.17) Disk = C: (Local Fixed Disk, NTFS, 118.6 GB, 23.6 GB free) Disk = D: (CD-ROM Disc, UDF, 4.4 GB, 2.7 GB free) Disk = E: (Local Fixed Disk, NTFS, 238.5 GB, 59.6 GB free) Disk = F: (Local Fixed Disk, NTFS, 931.5 GB, 618.7 GB free) Disk = G: (Local Fixed Disk, NTFS, 1862.4 GB, 935.4 GB free) OS = Microsoft Windows 10 Pro 64-bit (10.0.10586) Runtimes = 2.0.50727 SP2 3.0 SP2 3.5 SP1 4 Client 4 Full 4.0 Client Runtime = 2.0.50727.8689 (32bit)
regards,
vince
PHILLY NORTH PORTAL (Custom).jpg (211K)
Number of downloads: 4
re PRR=East: First through track NB NEC Main Philly to North Philly completed this afternoon.
v
#27
Posted 17 June 2017 - 02:45 PM
Genma Saotome, on 12 June 2017 - 07:50 PM, said:
This is currently not even an OR project - it is just TSRE5 doing its own thing. Chris, myself and Goku tried to have a private conversation back in December 2016, to get a feel for procedural generation in OR/TSRE5, where I shared a lot of details on how I'd been thinking we should describe lofted paths (the route through 3D space), but it didn't turn into a useful discussion in the end.
What I can do now is start a new thread covering all of what I said in private, and we can go from there in public instead.
#28
Posted 17 June 2017 - 07:26 PM
Goku, on 14 June 2017 - 01:28 PM, said:
"Stretchable shapes" like rails or ballast should be made 1 m length. Next UV coords are calculated based on actual length and coords from 3d shape.
So here is a great example of what drives me nuts: Programmer, w/o input from any content creator, decides something important, usually choosing the option that is is easier to do.
Please DO NOT make such decisions w/o running past the people who will be affected.
Goku, rail can probably be done very well with a UV scaling of 1m. Unfortunately ballast and roadbed are highly unlikely to come out as well. 1m of something as visually obvious as ballast will very likely descend into obvious tiling patterns, if for no other reason that the art is hard to do in the first place. Ditto dirt and green stuff on the subroadbed. For myself, I would love to see ballast and subroadbed merge multiple textures upon the polys (e.g., one rock rock, scaled at X and a different one scaled at, oh, 5X, that is semi-transparent dirt.
Further, things like what's between multiple tracks might be another issue -- is ballasted or not, if it is ballasted is it flat or is there a depression? That too must be addressed.
What's needed is for the profile data to define all of the UV scaling. In the ideal the template should actually be a finished .s shape. The .s file itself no doubt contains a bunch of stuff that could be considered unnecessary, but I'm not going to assert that is so but it seems plausibly the case. At any rate, if the actual .s file contents are part of the performance problem then perhaps the application should take the .s file template and convert what is wanted to the desired format (not when the game is running but beforehand). When converted the rest of the processing is whatever the programmers can agree upon.
WRT James Ross' reply, I would tend to support the official OR position on all such matters... except that's really hard to do as so far there has been no effort whatsoever to produce an editor.
#29
Posted 17 June 2017 - 07:38 PM
#30
Posted 17 June 2017 - 08:39 PM
Robert