Elvas Tower: Extraneous Scenery in X1763 - Elvas Tower

Jump to content

  • 2 Pages +
  • 1
  • 2
  • You cannot start a new topic
  • You cannot reply to this topic

Extraneous Scenery in X1763 Rate Topic: -----

#1 User is offline   Sid P. 

  • Conductor
  • Group: Status: Contributing Member
  • Posts: 463
  • Joined: 12-February 13
  • Gender:Male
  • Location:Canada
  • Simulator:Open Rails / MSTS
  • Country:

Posted 17 September 2013 - 03:43 PM

I have attached two screen dumps from the Surfliner 2 route, the activity is "AMTrak 778". The dumps are from X1763 and X1737.
If you look above the local hills, you will see a piece of ground scenery behind the nearest hilltop (just above the green signal lamp) that suddenly appears, only in X1763 - as the train moves forward a few hundred yards, the scenery chunk grows larger at a non-realistic rate and fills the sky behind the foreground, then abruptly vanishes as the train gets closer. I don't see it beyond the curve in the track. A similar effect occurs again in later parts of the route. The pictures are taken just beyond MP 257. The second picture (from X1737) does not show this effect.

Has anyone else seen similar artifacts, or is it just my system ? ( i5-3570 and AMD HD 7770, Win 7 Pro).

Attached thumbnail(s)

  • Attached Image: X1763 MP257.jpg
  • Attached Image: X1737 MP257.jpg


#2 User is offline   Genma Saotome 

  • Owner Emeritus and Admin
  • PipPipPipPipPipPipPipPipPipPipPipPipPip
  • Group: ET Admin
  • Posts: 15,308
  • Joined: 11-January 04
  • Gender:Male
  • Location:United States
  • Simulator:Open Rails
  • Country:

Posted 17 September 2013 - 04:33 PM

James did some work on terrain this past few days, including fixing a few things about distant mountains (which is what that error looks like to me). Perhaps you should get the update this Friday (or use SVN to get it today) and see if this problem has been corrected.

#3 User is offline   Csantucci 

  • Member, Board of Directors
  • Group: Status: Elite Member
  • Posts: 6,986
  • Joined: 31-December 11
  • Gender:Male
  • Country:

Posted 17 September 2013 - 10:50 PM

I have a similar problem on the Bernina route and am happy to discover that I'm not the only one. In my opinion this is due to the fact that DM must not be shown within a circle around the viewing point (whose radius depends also from the maximum viewing distance of standard terrain). In James' version either this feature isn't present or the radius of the circle is too small.

#4 User is offline   James Ross 

  • Open Rails Developer
  • Group: Status: Elite Member
  • Posts: 5,488
  • Joined: 30-June 10
  • Gender:Not Telling
  • Simulator:Open Rails
  • Country:

Posted 18 September 2013 - 06:26 AM

This is quite likely errors in the DM terrain of the route. DM terrain should always be below normal terrain, and for MSTS in-box routes this is true except for very small patches where they are only slightly the wrong way around. In this case, as in the Bernina case, they are a long way out.

While I would like to enforce a "no DM within the normal terrain area" this is in practice really hard to do. For now, DM exists everywhere that is visible but is always drawn behind normal terrain. I may have to add back the hack of a fixed exclusion zone, though, but I'll try and make it more responsive and less crashy than the previous one was. :)

#5 User is offline   Lindsayts 

  • Superintendant
  • Group: Status: Elite Member
  • Posts: 1,849
  • Joined: 25-November 11
  • Gender:Male
  • Country:

Posted 18 September 2013 - 12:27 PM

View PostJames Ross, on 18 September 2013 - 06:26 AM, said:

This is quite likely errors in the DM terrain of the route. DM terrain should always be below normal terrain, and for MSTS in-box routes this is true except for very small patches where they are only slightly the wrong way around. In this case, as in the Bernina case, they are a long way out.

While I would like to enforce a "no DM within the normal terrain area" this is in practice really hard to do. For now, DM exists everywhere that is visible but is always drawn behind normal terrain. I may have to add back the hack of a fixed exclusion zone, though, but I'll try and make it more responsive and less crashy than the previous one was. :oldstry:



Just a thought............

Now programming something as complex as a train sim there will always be a choice of options. In a lot of cases there will be no clear choice or a choice the will satisfy all parties.

In the above case is it worthwhile may be sacrificing the appearance of DM on most routes to try and render the hand full of poorly done routes. OR has certainly taken steps not to cater for some poorly done items in the past.

While it is a pain to put up with items not done correctly its likely one can put up with some items, for the time being anyway, given the amount that has to be done to the number of people actually working on OR.

Lindsay

#6 User is offline   Sid P. 

  • Conductor
  • Group: Status: Contributing Member
  • Posts: 463
  • Joined: 12-February 13
  • Gender:Male
  • Location:Canada
  • Simulator:Open Rails / MSTS
  • Country:

Posted 18 September 2013 - 01:08 PM

re Lindsayts: "Just a thought... " Yes, there must be some decisions as to to what extent the visual problems are caused by artifacts in the route, and how much the OR designers must accommodate them. In this case, ORTS does not crash, there are just strange displays, so it is not a critical problem. But how easy will it be to correct the problems in the individual routes? Is it possible to describe precisely what corrections have to be made to the route ?

James - the problem that I described above first appeared after X1755 ( I believe that it is OK), and continues up to and including X1763. I was more concerned that it was an artifact of my display system, since no one else had reported it yet.

#7 User is offline   James Ross 

  • Open Rails Developer
  • Group: Status: Elite Member
  • Posts: 5,488
  • Joined: 30-June 10
  • Gender:Not Telling
  • Simulator:Open Rails
  • Country:

Posted 19 September 2013 - 08:57 AM

View PostLindsayts, on 18 September 2013 - 12:27 PM, said:

While it is a pain to put up with items not done correctly its likely one can put up with some items, for the time being anyway, given the amount that has to be done to the number of people actually working on OR.


In this case, it's easy to put the hack back in - it's simply setting the near plane of the DM projection matrix. Though I need to spend a little time checking out different ways to set it so that it has the least impact on working routes.

#8 User is offline   Lindsayts 

  • Superintendant
  • Group: Status: Elite Member
  • Posts: 1,849
  • Joined: 25-November 11
  • Gender:Male
  • Country:

Posted 19 September 2013 - 01:04 PM

View PostSid P., on 18 September 2013 - 01:08 PM, said:

re Lindsayts: "Just a thought... " Yes, there must be some decisions as to to what extent the visual problems are caused by artifacts in the route, and how much the OR designers must accommodate them. In this case, ORTS does not crash, there are just strange displays, so it is not a critical problem. But how easy will it be to correct the problems in the individual routes? Is it possible to describe precisely what corrections have to be made to the route ?



This is of course a good point although I was just trying to keep in all readers minds that the OR devs are not supermen and have lives to lead. As users we need to keep this in mind so as not to put to much pressure on.

but, to James,

OR currently displays the current tile and the position of the view point within that tile how difficult would it be to include the same info for the distant terrain tiles, OR must have this info somewhere, such a display would help to pinpoint errors.

Lindsay

#9 User is offline   James Ross 

  • Open Rails Developer
  • Group: Status: Elite Member
  • Posts: 5,488
  • Joined: 30-June 10
  • Gender:Not Telling
  • Simulator:Open Rails
  • Country:

Posted 19 September 2013 - 01:14 PM

View PostLindsayts, on 19 September 2013 - 01:04 PM, said:

OR currently displays the current tile and the position of the view point within that tile how difficult would it be to include the same info for the distant terrain tiles, OR must have this info somewhere, such a display would help to pinpoint errors.


Well, technically they're both the same coordinate space, it's how they're divided up that's different. I should note that there is no fundamental difference between DM terrain and normal terrain, it just happens to be in larger chunks - just like how a quad tile is simply a different size of normal tile.

Also, OR does not currently display the normal terrain tile coordinates, it displays the world coordinates - these are always divided up in 2048x2048 chunks.

As such, although OR could additionally display the tile and DM tile coordinates, I don't really see that it would be useful in identifying the problem location (all it would tell you is the physical file on disk that happens to contain the current world coordinates).

#10 User is offline   James Ross 

  • Open Rails Developer
  • Group: Status: Elite Member
  • Posts: 5,488
  • Joined: 30-June 10
  • Gender:Not Telling
  • Simulator:Open Rails
  • Country:

Posted 20 September 2013 - 11:36 AM

Put a hack in to X.1765 - a 500m exclusion zone for DM.

  • 2 Pages +
  • 1
  • 2
  • You cannot start a new topic
  • You cannot reply to this topic

1 User(s) are reading this topic
0 members, 1 guests, 0 anonymous users