Floating scenery

[sniper297]

Hmm. Well, it's taking me a while to set up a test route, been 2 1/2 years since I tinkered with the MSTS (pronounced "messed" ) route editor. Here's what I got so far, just forest region trees and weeds;



That's in MSTS, not perfect but follows the ground contours fairly well.



That's the same location in ORTS, what trees are left look okay but several complete regions are missing, and the weed regions float in some places. The regions also have shifted sideways, the one on the right is a lot further from the track. Can't blame that one on shapes, forest regions don't have a "shape" per se, they all use a global parameter so if one works they all should work.

[csantucci]

Also in our Bernina Pass route at a first glance I notice that the area of the forests in OR is quite less than defined in the RE (this is sure), and that many forests seem to be missing (or maybe they are only sharply reduced in area).

Carlo

[mestevet]

Yes, Route Editor and the simulator both discount the vertical offset in the matrix element of the first matrix. Changing the vertical offset of the matrix did not affect the placement of the shape.

This discounting of the matrix also explains the difference I noted between Shape Viewer and the simulator in regards to a freight animation, see post https://www.trainsim.com/vbts/showthread.php?t=275998

Q.E.D. then, I did not know that, it's interesting. The question I have for one of the OR "reps", Should OR compensate for MSTS Shape Files that are built (what I would consider) wrong just because MSTS does?

As far as the Forest Regions are concerned, it seems from what I'm reading, that in OR, Forest Regions get: A. Shifted, possibly both vertically and horizontally B. Reduced in number (perhaps there's a limit to how many it's able to display currently)

I could theorize a reason why they get shifted horizontally - all those types of regions have "handles" for dragging the size of the box bigger, in addition to the center handle. Is it possible that the World files are defining the location of one of those "handles" instead of the center of the box, or vice versa, and OR is reading that differently?

Also, has anyone from the OR team said that the current version is supposed to handle Forest Regions properly at the present time? It would seem to be futile (or perhaps even problematic) to spend too much time discussing something they already know about, know is an issue, and are potentially working on.

As for all of this being "guessing"... MSTS is so random in the way it does certain things, I would think that figuring out how certain things are done would require trial and error methods - that's distinctly different than random guessing as a scientific method. At any rate, why do you care? I expect the OR team will do what they feel is necessary to get the reults they want.

Steve

[csantucci]

Should OR compensate for MSTS Shape Files that are built (what I would consider) wrong just because MSTS does?

OR is not supposed to be a syntax verifier, in my view it is supposed to be a Train Simulator with great new functionalities to be developed together with compatibility with MSTS features wherever reasonably possible and wherever there is considerable MSTS legacy (especially objects of any tipe, routes, sounds) using such features.

It would seem to be futile (or perhaps even problematic) to spend too much time discussing something they already know about, know is an issue, and are potentially working on.?

Until we do not get a clear statement about this from the OR people, any comment about features not working well is supposed to be an useful OR beta (or alpha) testing help.

I would think that figuring out how certain things are done would require trial and error methods - that's distinctly different than random guessing as a scientific method..?

Guessing and experimenting if the guess was correct is the basis of a scientific method. And by finding out MSTS features (or oddities) maybe we partially relieve the OR people from doing it, so that they have more time for development.

I expect the OR team will do what they feel is necessary to get the reults they want.

Me too, but this is not in contradiction with signalling issues and making guesses unless OR people will say "That does not interest us".

Carlo

[kraus]

In this case of a non-zero matrix offset, I would like to see OpenRails issue a warning in the log. This would allow the shape objects to be identified and corrected. The corrected shapes would continue to work in Train Simulator unchanged and then would work as expected in OpenRails and Shape Viewer.

Another difference with how the matrix element is processed is the first nine attributes which can be used for scaling. Shape Viewer will show a shape scaled while Train Simulator will freeze and quit if a non-identity scaling is used on a shape.

For forests, while it may appear that the items are placed randomly in Train Simulator, they are in fact placed in the same location for each forest. The current code in OpenRails places the items randomly since the method used by Train Simulator is not yet known.

The current method used by OpenRails is to loop for each item in the forest and pick a random location within the forest region.

[OTTODAD]

Not being a C++ programmer but a PowerBasic32 one, nor being familiar with creating graphics objects, I can not understand how programmers creating a new train simulator which is supposed to use MSTS shapes and functions make A) shapes created for DX-7 display better in DX-9/10 and B) not being able to read the source code of MSTS know what all it's functions do and then apply them to the new train simulator who has to use them to do the same, forests being one example.

Yes, these trees on the track are part of a forest and in many places where forest edges run parallel with the tracks they have shifted on to the tracks.

There are some MSTS shapes creators who have managed to convert them from TSM / 3DCanvas / Photoshop, etc, to the RW graphics format, but in the case of trees they still have limited planes and are not really 3D.

In any case there is nothing we can but wait for the next beta.

O t t o

[longiron]

Not being a C++ programmer but a PowerBasic32 one, nor being familiar with creating graphics objects, I can not understand how programmers creating a new train simulator which is supposed to use MSTS shapes and functions make A) shapes created for DX-7 display better in DX-9/10

First, there is more color depth in some ACE files than MSTS actually displays that OR does, plus the Dx9 pixel shader in DX9 is more sophisticated regarding interpolation and other functions resulting in smoother colors using the same base graphics.

B) not being able to read the source code of MSTS know what all it's functions do and then apply them to the new train simulator who has to use them to do the same, forests being one example.

OR uses a totally new, independant way of placing objects within a forest object as krausyao's previous post indicates. At the present time, OR randomly places objects with a fixed density within the defined object boundaries. Because MSTS doesn't, route builders could have defined forest objects that include track areas without having trees on the tracks. Since OR does it differently, OR may randomly drop a tree shape on the tracks. Eventually, OR will be able to define object density in forest objects, and mix object types.

[OTTODAD]

Thanks, Chris !

I find all this very interesting, learning a lot about what it takes, but would not like to be in the shoes of any of the ORTS team's members who are trying to make it all work the way it should.

Take care, O t t o.

[mestevet]

Guessing and experimenting if the guess was correct is the basis of a scientific method. And by finding out MSTS features (or oddities) maybe we partially relieve the OR people from doing it, so that they have more time for development.

Carlo

My comments were not directed at you sir.

"basis of a scientific method" - the method is "Trial and Error" as I asserted. "Guessing" may play part in that, but in and of itself is not considered a scientific method any more than "wishing on a star".

I'm really not sure what the point of your post is other than to provoke me into an argument, therefore I've reported the post as such.

Steve

[sniper297]

Lighten up, guys, no point in getting pedantic about semantics, aside from minor details you're saying the same thing. Einstein and Voltaire were both quoted with variations of "If we knew what we were doing we wouldn't call it research". As for the forest regions;

https://www.trainsim.com/vbts/showpost.php?p=1597441&postcount=2

Guess to theory to proven fact, ORTS (at least on flat ground) keeps the same coordinates for the center of a forest region, the problem is that it somehow reduces the size in all three dimensions.

[muskokaandtahoe]

Lots of questions... a couple of answers:

First, because Open Rails is a volunteer team and not hired staff, it is sometimes difficult to prioritize and act quickly upon this or that need. Things like family, job, hobbies, interest level, etc., all bear upon what and when things happen in ways that just don't come up with employees. And for those on the team in the northern hemisphere... it's summer and so there are plenty of other things to do. So please, bear with us. Some of thee issues will get resolved soon. Some not.
========
========


That said... lets see... forests. As mentioned forests are not objects per se but procedural elements whose size and placement location are computed.

To obtain the location of each tree, we have to first calculate the rectangular area specified in the .w file, including its horizontal rotation, generate random horizontal locations within that area for trees, and then "plant" them. The random horizontal locations are going to be different than MSTS because, well, they're random and that naturally means they'll go in places that are not the same as in MSTS, but still are within the defined area the route builder specified.

"Planting" them is a bit trickier and it looks like we've got a bit of work to do refining that step. Essentially what is supposed to happen is you take the xyz data of the three points that bound each terrain face, the xyz data of any tree that falls within that face area, and figure out a correct altitude for the tree given the slope present. Obviously something isn't as expected and we'll just have to look into it (n.b., for those of you who observe the floating tree phenomena, or -- especially -- floating objects that are not forests, if you'd make note of the route, and the tile, and some approximation of where within that tile you are, well have a better chance of figuring out how to fix this.
=========
=========


Next one: should Open Rails fix MSTS files that "are wrong?". "Wrong" is often subjective....

At any rate, the honest answer is, IMO, "Right now it depends on how much work it is, whether or not it even gets noticed, and whether the team believes we should deal with it".

Something simple, like an omitted parameter, might get "fixed" by Open Rails plugging in a default value. Or not -- does anybody know what ESD_Software_DLev does? We don't. But maybe somewhere, in some circumstances, it actually does do something. Odds are we're not going to be doing anything with it.

OTOH, there are lots and lots of .sd files that have removed the bounding box info, or left the line in with no value (e.g., just this: "()"), with the full omission being defaulted but the null value causing an error. We probably should change our code to deal with the empty value so those objects display as they should.

But here's where it gets tough: there are some sections of files that include a lot of optionality -- lights for instance -- where we're finding the full range of implementations to be exceedingly difficult to sort out. Are some of those "wrong"? Try to write that code and after pulling out a fair bit of your hair in frustration you'll likely answer "yes, that file is WRONG". But if you are the one person who runs that locomotive all the time because it is your favorite and you've tuned the heck out of ever parameter... you'll answer "no, that file is PERFECTLY CORRECT". And everyone else has "no opinion". Repeat the exercise with the next file... and the one after that.

In short, we cannot replicate MSTS, nor can we "fix" every odd MSTS file because (1) we do not have the source code for MSTS, (2) we do not have infinite resources to bring to bear on each problem, and (3) we have to evaluate every problem against ever possible new feature and choose which will be more welcome: fixing things so one locomotive works as its user intends, or, say, figuring out how a stopped train continues to influence signals, or one better, designing and building a new route editor.

Speaking for myself only, I want to see as much compatibility in OR as we can create because I want to carry/drag as much MSTS content and play behavior into the future as possible. But I don't want to make a fetish of it. When the source code is opened up to the public it'll be possible for someone else to tweek this or that function to address this or that issue.
============
============


On keeping the public informed... it's not that easy actually. We do have the beginning of a wiki and that could be used to note any and all "We know about this problem already" as well as "This isn't complete".

There isn't any one person right now dedicated to updating the wiki... something I'll bring up w/ the team.
============

If I've not responded to a topic of interest, let me know. I'll also be glad to clarify / extend upon my comments, above, as needed.

Oh, and as for my relationship w/ Open Rails, for some time now Wayne's employer has major demands upon his time and so I'm acting team lead in his absence.
============

[sniper297]

Thanks, Dave. As you know I'm not a big fan of backwards compatibility to begin with. If the choice is (1) keep backwards compatibility at all costs, including the limits, bugs, quirks, and tedious methods of the original, or (2) start over from scratch with a brand new program that's less buggy and faster/easier to create with, I personally would rather start over. So to me that's what this boils down to is decisions, best compromise would be to bring along as much as possible without crippling the new program with old flaws. Forest regions are one of those irritating buggy tedious subroutines that I would rather see replaced with something better, even if that means we have to re-vegetate every MSTS route in the future. Just my opinion, I could be wrong!

[OTTODAD]

Thanks, Dave. As you know I'm not a big fan of backwards compatibility to begin with. If the choice is (1) keep backwards compatibility at all costs, including the limits, bugs, quirks, and tedious methods of the original, or (2) start over from scratch with a brand new program that's less buggy and faster/easier to create with, I personally would rather start over. So to me that's what this boils down to is decisions, best compromise would be to bring along as much as possible without crippling the new program with old flaws. Forest regions are one of those irritating buggy tedious subroutines that I would rather see replaced with something better, even if that means we have to re-vegetate every MSTS route in the future. Just my opinion, I could be wrong!

We have been saying the same about the Rail Simulator, but Kuju having failed to come up with the goods their new owners pulled the plug on it, forcing RSDL to take it over.

We do not want to travel the same route all over again !

O t t o

[sniper297]

That's what I'm talking about, they SHOULD have dumped that idiotic scenario editor and retarded AI traffic two years ago, started over with something that actually worked. Instead for the sake of backward compatibility of a few dozen lame and flawed scenarios they kept trying to "further enhance" a broken system. They're still trying, but when you kludge around a kludge it never ends.

[muskokaandtahoe]

If the choice is (1) keep backwards compatibility at all costs, including the limits, bugs, quirks, and tedious methods of the original, or (2) start over from scratch with a brand new program that's less buggy and faster/easier to create with, I personally would rather start over. So to me that's what this boils down to is decisions, best compromise would be to bring along as much as possible without crippling the new program with old flaws.

What I underlined pretty much suns up my point of view and (I think) I've got some notion of what features that means. But take any other person who feels the generally the same, their list of specific features is likely going to be different. Multiple times x where x is voiced opinions. Reconciling those lists is inherently a challenge, moreso with volunteers. After all, nobody has to do this.

So it takes time to sort thru and there's going to be some lurching to and fro as interests captivate this or that programmer, be those interests contributory to the project or reductive when personal time goes elsewhere.

We're trying to get good things done and I hope our demo gives some indication of what is possible. Think about it for a sec: the Open Rails program is not a professional, commercial product. But look at what some skilled hobbyists have been able to do. Not bad, huh? We should be able to do more and with time, I expect we will.