[Lindsayts]

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.

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

[Lindsayts]

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

[rdamurphy]

Squared? Um, no. Cubed. It's a 3 dimensional world...

Robert

[ChrisD]

nyc01, on 30 March 2013 - 03:26 PM, said:

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.

Why should it fail?

Haven´t You noticed that OR is modular?

Display code is a separate program section from the simulation engine. This means that the display engine can be completely replaced without destroying the simulation engine.

As I see it, the OR team, right now, concentrates on developing a good Train Simulator, where the trains feel and functions like real trains.

Yes, Your eagle eye has not fooled You, it is 1999 graphics. MSTS originates from that period and OR initially uses MSTS routes and assets and the result looks just like You said.

However, I prefer this over anything else.

Other commercial, so called train sims, looks better, but they tend to be more a Game than a Simulator.

Having tried most of the other available Train "sim" Games, I return to OR every time, because the driving experience is so much better. :sign_thanks:

My imagination can deal with assets with low res. textures, as long as the driving feels right.

OR is Beta, if You haven´t noticed, so what You see now is no way close to the intended result.

Speculating in other display engines is way too early, so just hold Your horses and wait for the OR Team to decide this matter in good time.

The shown implementation of Distant Mountains is the FIRST BETA, so I think Your harsh negative commentary is a little premature, sorry, but this is my sincere opinion.

OR has chosen to keep the beta testing open, contrary to other companies that keep their beta testing under lock and key.

User´s wishes and demands are Years ahead of actual development.

Even then, the OR Team take some time off from the serious coding, in order to attend to my petty wishes.

I think we owe then the slack they deserve. :)

Please remember this, thank You.

ChrisD

A satisfied "betatester".

[disc]

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?

Not so inefficiently... It can't be done other was, in any game engines, which are using high level API-s hogy graphics, like direct3d, or opengl... and all of the games use one of these.

[Lindsayts]

rdamurphy, on 31 March 2013 - 01:00 AM, said:

Squared? Um, no. Cubed. It's a 3 dimensional world...

Robert

Technicly thats correct, but the world on the scale displayed in a train sim does not extend vertically as much as as it does in the horizontal plain, so say doubling the viewing distance does not seriously increase the number of objects in the vertical axis. Hence the amount of detail that is needed to describe a scene does not increase as much as one would expect. If one is increasing the viewing distance from say 6 to 12 metres of a 3D scene then the data required will be cubed.

Lindsay

[Lindsayts]

Any way a couple of screen shots from OR V 1527 showing the new distant terrain..........
I may say the screens shots below are a excellent example, not all "distant mountains" come out this good, but still __WELL__DONE__, OR.

Note the second screen shot is actual slightly further away so the detail should be less not more.

V1515 no distant terrain,




V1527, Note the improvement in detail by I assume the removal of the fog, also the quite seamless way the distant "mountains" has been intergrated with the foreground.

[Lindsayts]

ChrisD, on 31 March 2013 - 01:17 AM, said:

Why should it fail?

.................. A lot cut...................

Please remember this, thank You.

ChrisD

A satisfied "betatester".

The post was not a go at OR or the developers, the original post was making a point about a game engine and the quality of the graphics produced. I was making the point that if the sim itself is ignored for graphics as it is in both recent train sims we really are "dead in the water". The developers of OR themselves are striking a good balance between the sim and the graphics.

You made an __EXCELLENT__ point as long as the simulation itself is realistic enough one can easily supply your own "detail" from your own imagination. I whole heartedly go with this and I am quite happy with the level of detail MSTS has produced. If one likes high detail there is of course nothing wrong with this as long as one keeps in mind this detail needs more time and dedication to produce the content itself and it does require more "steam" in the sim to display and therefore there will be limitations.

Lindsay