Open Rails development priorities

[csantucci]

I have read in the OR site the page about the OR development priorities. While I appreciate the roadmap main goals, I am concerned by the fact that Distant Mountains are no more mentioned. I hope they will also be part of the "Realism releases"

Carlo

[boleyd]

I agree on the mountains but perhaps there should be a distance/detail slider to limit FPS hit.

I would also vote for an improvement in ground texture. The things that set on the texture (objects) look ok despite being lower resolution than other similar programs. But the very blurred ground detracts from the objects. Of course, that may currently be available (??) but only needs new textures from those with the skills.

[twpol]

I have read in the OR site the page about the OR development priorities. While I appreciate the roadmap main goals, I am concerned by the fact that Distant Mountains are no more mentioned. I hope they will also be part of the "Realism releases"

They're certainly on my list of things we should do, although there's no guarantees on how or when we will do them yet.

I would also vote for an improvement in ground texture. The things that set on the texture (objects) look ok despite being lower resolution than other similar programs. But the very blurred ground detracts from the objects. Of course, that may currently be available (??) but only needs new textures from those with the skills.

Could you screenshot the ground you're seeing? Is it possible you have overriden the anisotropic filtering setting in your graphics card's options? Open Rails tries to enable anisotropic filtering on the terrain (and other objects) to increase the detail in the distance/when at very small angles to the camera to avoid the very blury mipmapping that would happen in MSTS.

[SAR704]

In MSTS, the DMS appear to be closer to the track than they actually are. I'm not sure exactly what the trick to them is, but their inbuilt LOD settings could start at a modest level, and be reduced as they go further out (consistent with the polygonal detail you can physically see from the train). They could count as separate items from everything else rendered in the world, therefore exempting them from the viewing distance limitations.

This is only a suggestion though. I'm sure the technically minded could come up with some different ideas on how to implement them and make them look reasonable, without overloading the program. Something for a new thread maybe?

By the way, is OR expected to get its own route editor further down track?

[twpol]

By the way, is OR expected to get its own route editor further down track?

Yes, that's the plan. As you can imagine, though, it'll be lots of work so I wouldn't hold you breath waiting for it just yet.

[OTTODAD]

Below are examples of distant mountains in my GOLD-SPIKE-X routes and unless a Train Simulator can display them at least as good as this then it is of no interest to me. The ones in Railworks are the worst !

Distant mountains and overhead wires should be at the top of the ORTS team's list so that we can enjoy running quality MSTS routes in ORTS while we are waiting for the team to develop the rest !

O t t o

[thegrindre]

I'm going to disagree with you, Otto. It's a railroad simulator and the real world physics of rolling stock, track functions and related railroad apparatus is for more important then eye candy, IMHO.
If you want eye candy, get RW or Trainz.
I say let's all work on what a simulator is supposed to be all about.
Once we get the trains simulating as they should then it'll be time to add all the fluff.

[OTTODAD]

It's a railroad simulator and the real world physics of rolling stock, track functions and related railroad apparatus is for more important then eye candy.

To you as a creator of objects perhaps. But what appeals to me and the train simulator masses is foremost realistic visual appearance.

Rolling stock creators should be more concerned with getting visual things like that right:
www.otto-wipfel.co.uk/video/china-steam.wmv
ORTS can do nothing about !

If you want eye candy, get RW or Trainz.

You are joking ?

O t t o

[twpol]

Don't forget that there are a good number of people working on OR in a number of teams; while obviously not completely disjointed, different people work on different things. I work mostly on graphics and partly performance; other people work on signals, physics, sounds and the multitude of other components that make up a good simulation game.

Looking at it another way, when Otto says "Distant mountains and overhead wires should be at the top of the ORTS team's list" it's probably safe to assume "Distant mountains and overhead wires should be at the top of the ORTS 3D & Environment team's list" - and they are near the top.

[thegrindre]

LOLOLOL Come on, Otto. I can find some of the worst of the worst, also. I can show you some of the best, too but not in MSTS.
My point is that you can't possibly want a Shay that will exceed 50mph and not be able to pull itself up a 4% grade with a 54+mph run at it while looking at all the beautiful scenery, do you?
Well, that's what we already have with two other train games. MSTS is the only one that'll give us some pretty good real world physics and that's what I thought OR was doing, or going to do.
So far, after two or three releases, all I'm seeing is pretty. The 'fluff' can come later. What we need is realistic train operations first.
After all, Otto, it's supposed to be a train simulator isn't it?

[mnjrr]

Both Otto and Rick raise very good salient points outlining their expectations for Open Rails. As pointed out by James, who is a member of the team, the Open Rails team believes that both realistic physics and distant mountains should be prorities for the project. In due time, the Open Rails team will efficiently address these areas of concern and thereby raise the bar of train simulation greatly moving beyond MSTS. The reason why we haven't made as much progress, as we would like, is because we are short of personel. Therefore, we can not address everything right now. In other words, it will take multiple releases before we can effectively make Open Rails into a real world train simulator. As we discuss Open Rails, the Open Rails team has implemented a basic signal system in place in the developers version of the software, but the signaling needs further testing. If any programmer would like to join the Open Rails team and work on some of the aforementioned topics of interest, please fill out an application at http://openrails.org/coders.html. Thank you.

[thegrindre]

That is great news about the signaling, Walter. I wish I could help but I never went beyond the BASIC language back in my DOS days and have forgotten most all of that.

To the OR team, keep up the great work! (I really am behind all of you.)

[OTTODAD]

My point is that you can't possibly want a Shay that will exceed 50mph and not be able to pull itself up a 4% grade with a 54+mph run at it while looking at all the beautiful scenery, do you?
Well, that's what we already have with two other train games. MSTS is the only one that'll give us some pretty good real world physics and that's what I thought OR was doing, or going to do.

You being a rolling stock creator I meant to ask you this:

Are locos creators not determining the physics for their locos in their *.ENG files, each one having different characteristics and performance, the ORTS programmers can not possibly foresee and code into the program ?

O t t o

[muskokaandtahoe]

WRT: distant mountains... one thing you may not have noticed in Open Rails is that it displays more tiles than does MSTS -- 9 in all... the one your camera is in plus the surrounding 8. I think that adds up to 4500 polys, with whichever falling into a 2000m circle centered on the camera being displayed. If memory serves, MSTS displays only 4 tiles... the one your camera is in and the three nearest the quadrant of the camera. That's 2000 polys (far less actually as most are converted to 16m pairs), of which some subset is displayed due to the lesser of the 2000m circle and the furthest boundaries of the 4 tiles. IOW, odds are good that it's almost always far fewer polys and less terrain than what OR shows you.

At any rate, the 2000m visibility limits how far away from the camera you can place those distant mountains.

Now if you consider the design choices for handling distant mountains there are a couple of obvious choices -- one is simply increasing the number of displayed tiles and then increasing the visibility distance to match. Increasing the current 9 to include the next tile out adds another 16 tiles... that's another 8000 polys. The visibility distance could be increased to 4000-4500m. Add another enlargement so it's your camera tile plus 3 more in every direction, that's another 24 tiles and visibility could be increased to 6000-6500m. Everything adds up really fast -- the number of terrain polys plus the modeled objects on these other tiles. And this doesn't fully address distant mountains... it's actually only near mountains.

So to do distant mountains, we either have to treat more and more of those tiles pretty much as you you do near tiles... or we have to figure out how to take all the terrain data for DM and flatten it into a 2d image that can be applied to the inside of a very large cylinder (n.b., flattening 3d data into a 2d image for display is what GPU's do, not CPU's). And we're still left with trying to figure out how far away from the camera that cylinder should be, both in terms of actual distance and content.

What will look great on my PC -- a brand new Intel i930 quad core CPU -- would be a lot of tiles displayed and that would probably kill frame rates on my old PC -- an AMD 4800+ dual core PC.

So what's right? Replicating the MSTS 2000m solution or pushing things further out? And if the later, how far? No easy answers there folks.

[conrail1]

So what's right? Replicating the MSTS 2000m solution or pushing things further out? And if the later, how far? No easy answers there folks.

Possibly looking at how other game engines handle this might help -

http://outerra.com/wgallery.html

http://outerra.com/wfeatures.html

I've been following the development of this game engine since late last year and it is very impressive to say the least.