Log In
Register Now!
Help
Now that it is possible to remove the fog with the distant mountains option, it appears that it is easier to see the drawing of terrain relatively close to the track, ie probably just over the 2km mark. It is a bit disconcerting to start to see a hill form in front of you. It seems to be more pronounced in hilly routes.
Is it possible to increase the drawing distance of terrain out beyond the 2km mark?
Similarly trees in forest markers seem to appear as they come within the 2km mark. Again it does seem unusual for trees to start to appear.
Is it also possible for trees and other objects to appear further away?
Thanks
Distant Mountains - Fog Removal
Rate Topic:
#1
- Open Rails Developer
-
- Group: Posts: Elite Member
- Posts: 1,980
- Joined: 24-June 11
- Gender:Male
-
Country:
Posted 29 March 2013 - 01:28 PM
#2
- Superintendant
-
- Group: Posts: Elite Member
- Posts: 1,849
- Joined: 25-November 11
- Gender:Male
-
Country:
Posted 29 March 2013 - 01:59 PM
There is a item detailing the drawing distance OR uses in the windows registry which is set to the value 2000, one assumes this is the drawing distance OR uses, one may wish to experiment with this value........
__BUT__
The amount of data that a 3D program uses to describe a scene and sends to the GPU goes up by the __SQUARE__ of the viewing distance. So doubling the viewing distance to say 4000 metres will (at least) quadruple the data sent to the graphics card, and one could easily end up with frame rates well below what one would wish for.
Note, this is one of the more serious problems of doing "distant mountains" or drawing distant terrain in a 3D world, how to get the greatest distance at a reasonable detail level with out sending the frame rate through the floor.
Lindsay
__BUT__
The amount of data that a 3D program uses to describe a scene and sends to the GPU goes up by the __SQUARE__ of the viewing distance. So doubling the viewing distance to say 4000 metres will (at least) quadruple the data sent to the graphics card, and one could easily end up with frame rates well below what one would wish for.
Note, this is one of the more serious problems of doing "distant mountains" or drawing distant terrain in a 3D world, how to get the greatest distance at a reasonable detail level with out sending the frame rate through the floor.
Lindsay
#3 Inactive_nyc01_*
Posted 29 March 2013 - 03:30 PM
Lindsayts, on 29 March 2013 - 01:59 PM, said:
The amount of data that a 3D program uses to describe a scene and sends to the GPU goes up by the __SQUARE__ of the viewing distance. So doubling the viewing distance to say 4000 metres will (at least) quadruple the data sent to the graphics card, and one could easily end up with frame rates well below what one would wish for.
Lindsay
Lindsay
How much of that data is still inefficiently being processed by the CPU because of the way the game engine was written?
Quote
Note, this is one of the more serious problems of doing "distant mountains" or drawing distant terrain in a 3D world, how to get the greatest distance at a reasonable detail level with out sending the frame rate through the floor.
There are game engines out there now that are written with the terrain and associated algorithms running completely on the GPU. They are also able to render unlimited visibility and detail ranging from thousands of kilometers down to centimeters while all along maintaining excellent performance.
Again it all comes down to how well the game engine is written to utilize system resources.
#4
- Owner Emeritus and Admin
-
- Group: ET Admin Group
- Posts: 15,651
- Joined: 11-January 04
- Gender:Male
- Location:United States
- Simulator:Open Rails
-
Country:
Posted 29 March 2013 - 04:56 PM
nyc01, on 29 March 2013 - 03:30 PM, said:
How much of that data is still inefficiently being processed by the CPU because of the way the game engine was written?
Don't know if that is a general statement you are making or one specific to OR. If the later, could you provide an example? Just curious.
#5 Inactive_nyc01_*
Posted 29 March 2013 - 06:16 PM
Genma Saotome, on 29 March 2013 - 04:56 PM, said:
Don't know if that is a general statement you are making or one specific to OR. If the later, could you provide an example? Just curious.
In OR how much of workload do you think involving generating the terrain is put on the CPU and how much on the GPU?
#6
- Hostler
-
- Group: Posts: Active Member
- Posts: 78
- Joined: 19-March 13
- Gender:Male
- Simulator:OR
-
Country:
Posted 30 March 2013 - 07:18 AM
Lindsayts, on 29 March 2013 - 01:59 PM, said:
There is a item detailing the drawing distance OR uses in the windows registry which is set to the value 2000, one assumes this is the drawing distance OR uses, one may wish to experiment with this value........
Lindsay
Lindsay
Sorry, but I can not find this value in my registry. In the logfile left by OR on my desktop, this value is NOT listed as coming from the registry.
Please tell me where to find the value to be changed.
ChrisD
#7
- Executive Vice President
-
- Group: ET Admin Group
- Posts: 4,862
- Joined: 07-February 13
- Gender:Male
- Location:Leoben, Styria, Austria, Europe
- Simulator:ORTS / MSTS
-
Country:
Posted 30 March 2013 - 09:29 AM
I once had the same problem with the "ShadowAllShaes" option.
It´s a simple solution: just note the name of the vaalue you want to change, then go to to the windows-button, type "regedit" (registry editor) and open it: in the tree of keys enlarge HKEY_CURRENT_USER\Software and then find "OpenRails". Open this one again and therein create a new REG_DWORD (rightclick -> new -> REG_DWORD) with the name you noted, if it does not already exist. Doubleclick on it and enter the new value (eg. 3000). You maybe will have to change the input format from hexadecimal to to decimal. Afterward restart OR.
Regards and a happy easter
Markus
It´s a simple solution: just note the name of the vaalue you want to change, then go to to the windows-button, type "regedit" (registry editor) and open it: in the tree of keys enlarge HKEY_CURRENT_USER\Software and then find "OpenRails". Open this one again and therein create a new REG_DWORD (rightclick -> new -> REG_DWORD) with the name you noted, if it does not already exist. Doubleclick on it and enter the new value (eg. 3000). You maybe will have to change the input format from hexadecimal to to decimal. Afterward restart OR.
Regards and a happy easter
Markus
#8
- Superintendant
-
- Group: Posts: Elite Member
- Posts: 1,846
- Joined: 27-October 12
- Gender:Male
- Location:Budapest
- Simulator:OpenRails
-
Country:
Posted 30 March 2013 - 11:10 AM
nyc01, on 29 March 2013 - 06:16 PM, said:
In OR how much of workload do you think involving generating the terrain is put on the CPU and how much on the GPU?
Calculating of 3D position of individual objects is done by CPU, while projecting them to 2D screen space and coloring (sampling the textures) them is done by GPU.
#9
- Hostler
-
- Group: Posts: Active Member
- Posts: 78
- Joined: 19-March 13
- Gender:Male
- Simulator:OR
-
Country:
Posted 30 March 2013 - 12:32 PM
markus1996, on 30 March 2013 - 09:29 AM, said:
I once had the same problem with the "ShadowAllShaes" option.
It´s a simple solution: just note the name of the vaalue you want to change, then go to to the windows-button, type "regedit" (registry editor) and open it: in the tree of keys enlarge HKEY_CURRENT_USER\Software and then find "OpenRails". Open this one again and therein create a new REG_DWORD (rightclick -> new -> REG_DWORD) with the name you noted, if it does not already exist. Doubleclick on it and enter the new value (eg. 3000). You maybe will have to change the input format from hexadecimal to to decimal. Afterward restart OR.
Regards and a happy easter
Markus
It´s a simple solution: just note the name of the vaalue you want to change, then go to to the windows-button, type "regedit" (registry editor) and open it: in the tree of keys enlarge HKEY_CURRENT_USER\Software and then find "OpenRails". Open this one again and therein create a new REG_DWORD (rightclick -> new -> REG_DWORD) with the name you noted, if it does not already exist. Doubleclick on it and enter the new value (eg. 3000). You maybe will have to change the input format from hexadecimal to to decimal. Afterward restart OR.
Regards and a happy easter
Markus
Thank You very much. :)
This time it works.
Now I will try to find the "sweet spot" where I keep a reasonable framerate and where the trees do not grow up in front of me.
Once again, Thank You a thousand times to the OR Development Team for creating this magnificent Train Sim, and for keeping the process open. :)
Happy Easter to all of You.
ChrisD
#10
- Executive Vice President
-
- Group: ET Admin Group
- Posts: 4,862
- Joined: 07-February 13
- Gender:Male
- Location:Leoben, Styria, Austria, Europe
- Simulator:ORTS / MSTS
-
Country:
Posted 30 March 2013 - 01:23 PM
No problem :drinks:
Maybe you could share your finings with us, so if anybody else wants to find that "sweet spot", he/she does not have to play with the values that much.
PS: The procedure I described above should work for all of the entries OR shows during loading. Maybe you will have to take another type of key (e.g. REG_SZ - depending on the amount of data to be stored as a value, just look for similar entries)
Maybe you could share your finings with us, so if anybody else wants to find that "sweet spot", he/she does not have to play with the values that much.
PS: The procedure I described above should work for all of the entries OR shows during loading. Maybe you will have to take another type of key (e.g. REG_SZ - depending on the amount of data to be stored as a value, just look for similar entries)
#11
- Superintendant
-
- Group: Posts: Elite Member
- Posts: 1,849
- Joined: 25-November 11
- Gender:Male
-
Country:
Posted 30 March 2013 - 01:30 PM
nyc01, on 29 March 2013 - 03:30 PM, said:
How much of that data is still inefficiently being processed by the CPU because of the way the game engine was written?
There are game engines out there now that are written with the terrain and associated algorithms running completely on the GPU. They are also able to render unlimited visibility and detail ranging from thousands of kilometers down to centimeters while all along maintaining excellent performance.
Again it all comes down to how well the game engine is written to utilize system resources.
There are game engines out there now that are written with the terrain and associated algorithms running completely on the GPU. They are also able to render unlimited visibility and detail ranging from thousands of kilometers down to centimeters while all along maintaining excellent performance.
Again it all comes down to how well the game engine is written to utilize system resources.
OR uses the XNA toolkit and therefore uses whatever routines come with it. There is little use talking about partucularly commercial tool kits as its VERY likely they would require the developers to sign a non disclousre agreement and therefore we would have an excellent chance of losing OR's "openness". Which would be a major tragedy.
Open source development is usually done by volunteers with lives to lead, that have limited funds to spend on the development and have particular programming knowledge. It may be worthwhile to stress here that a trainsim is one of the most difficult sims to work with as it requires a __GREAT__ deal of detailed knowledge of railways and physics. It appears from experience over the last 10 years or so that its very difficult to get someone with such knowledge AND have top up to the minute 3D programming experience.
Another point is I have yet to see any demos on the net that show that a particular "engine" is __FAR__ better than another. One point about doing as much as possible on the GPU, its not easy to get data back to the CPU. The 5th edition of the OpenGL superbible and also the OPenGL Programmers guide both say this MUST be taken into account. Its little point in handing the processing off to the GPU if one has to calculate a parrameter in parallel with it in the main processor. One has to chose carefully what one can hand off to the stream processors in the GPU.
In my own work I have tried 4 different 3D gamming toolkits and while they are relatively easy to use and some do terrain that looks nice. I have yet to use one that is faster than using "tiled" terrain done using the standard OpenGL library calls. It does take somewhat more effort but once the terrain and object display routines are done
one is free to work on the trainsim proper.
If OR ends up good eye candy with poor/limited train simulation and/or handling it WILL have failed.
THe open rail devs __ARE__ doing a great job.........
Lindsay
#12
- Superintendant
-
- Group: Posts: Elite Member
- Posts: 1,849
- Joined: 25-November 11
- Gender:Male
-
Country:
Posted 30 March 2013 - 01:37 PM
A couple of points............
The parameter in the Registry is called "ViewingDistance"
Second, there's a post on trainsim.com that says the latest SVN version of OR has initial support for "distant mountains" the thread has some screen shots.
Lindsay
The parameter in the Registry is called "ViewingDistance"
Second, there's a post on trainsim.com that says the latest SVN version of OR has initial support for "distant mountains" the thread has some screen shots.
Lindsay
#13 Inactive_nyc01_*
Posted 30 March 2013 - 03:18 PM
gpz, on 30 March 2013 - 11:10 AM, said:
Calculating of 3D position of individual objects is done by CPU, while projecting them to 2D screen space and coloring (sampling the textures) them is done by GPU.
Thanks, that pretty much backs up what I was getting at with my previous comments.
There seems to be somewhat of an assumption in some of the comments in this thread (and in past threads) that eye candy, (whether it's good draw distance, detailed terrain or realistic shadows/lighting) equates to poor performance which from my experience with other up to date game engines is obviously not true.
#14 Inactive_nyc01_*
Posted 30 March 2013 - 03:26 PM
Lindsayts, on 30 March 2013 - 01:30 PM, said:
There is little use talking about partucularly commercial tool kits as its VERY likely they would require the developers to sign a non disclousre agreement and therefore we would have an excellent chance of losing OR's "openness". Which would be a major tragedy.
Probably more than just signing a non-disclosure agreement but then again if the current game engine doesn't allow for future advancements it also a tragedy and your left with something that isn't much better than MSTS.
Quote
It may be worthwhile to stress here that a trainsim is one of the most difficult sims to work with as it requires a __GREAT__ deal of detailed knowledge of railways and physics.
I know, I've seen it first hand with professional training simulators.
Quote
Another point is I have yet to see any demos on the net that show that a particular "engine" is __FAR__ better than another.
Do you actually have any experience with running any of these game engines? If so which ones?
Quote
One point about doing as much as possible on the GPU, its not easy to get data back to the CPU. The 5th edition of the OpenGL superbible and also the OPenGL Programmers guide both say this MUST be taken into account. Its little point in handing the processing off to the GPU if one has to calculate a parrameter in parallel with it in the main processor. One has to chose carefully what one can hand off to the stream processors in the GPU.
It all goes back to the experience and knowledge that the game engine development team has. With one such game engine that I've been following for three years now that's never been an issue. I'll be glad to point you to their forums where they have been very good at answering technical questions about how things are done in the engine.
I've had the engine running on my computers for a couple of years now and as far I can see they've pulled unlimited visibility off very nicely without the performance hit that you'd get if the work was still on the CPU.
Ultimately it comes down to picking the right tool for the job, as an example you don't use a game engine that more suited for a first person shooter and expect it to do a good job at rendering a wide open 300+ mile environment in a
train operation simulation.
Quote
If OR ends up good eye candy with poor/limited train simulation and/or handling it WILL have failed.
and if it ends up with a decent train operation simulation with poor graphics and dismal performance you'll be left with something that's not much better then MSTS, in other words another failure.
#15
- Open Rails Developer
-
- Group: Private - Open Rails Developer
- Posts: 1,199
- Joined: 04-May 06
- Gender:Male
- Location:Thornton, CO
- Simulator:MSTS - OR
-
Country:
Posted 31 March 2013 - 01:00 AM
Squared? Um, no. Cubed. It's a 3 dimensional world...
Robert
Robert