Floating scenery

[sniper297]

Figured I'd start a new thread on this, since the discussion in the other thread is really off topic.

https://www.trainsim.com/vbts/showpost.php?p=1596683&postcount=35

From what I see, it looks like the objects are actually being raised above the terrain;



Those are treeblocks with the bottoms sunk well into the hillside, Sierra Junction on Port Ogden & Northern version 9.



Same route same location in ORTS, the terrain contour looks about the same, but the tree blocks have been elevated considerably. Seems to affect only vegetation, I haven't seen any floating buildings so far. As for the weeds in the pics from the other thread;



I wouldn't swear to it, but those look like some of the "weed block" objects I made after discovering that excessively dense forest regions caused MSTS to crash, so it's probably a group object rather than a forest region. Which of course leads us back to the mad scientist laboratory, how dense can I make a forest region before ORTS chokes on it? Back later.

[csantucci]

It's not an issue of forests, it's probably an issue of location offsets in the shape. Also single objects float, e.g. MSforestline80C.s and MSforestline80B.s that are included in file FLine80.zip, that can be downloaded from the file library.

[longiron]

Which of course leads us back to the mad scientist laboratory, how dense can I make a forest region before ORTS chokes on it? Back later.

Jim,
Update an existing route and have a go.

[kraus]

The reason that the objects are floating above the terrain is due to the difference between how Open Rails and Shape Viewer interpret the matrix elements compared to Train Simulator.

The last three elements of the matrix element are the x-, y-, and z-coordinate offsets for the points that belong to the matrix. In the example below, the points are offset by 17.46 in the y-coordinate.

matrix MAIN ( 1 0 0 0 1 0 0 0 1 0 17.46 0 )

As show in the first picture this results in the trees placed above the terrain. The points for this shape are

points ( 8
point ( -33.0895 -0.54 5.8346 )
point ( -33.0895 35.46 5.8346 )
point ( 33.0895 35.46 -5.8346 )
point ( 33.0895 -0.54 -5.8346 )
point ( -31.5737 -0.54 -11.4919 )
point ( -31.5737 35.46 -11.4919 )
point ( 31.5737 35.46 11.4919 )
point ( 31.5737 -0.54 11.4919 )
)

Train Simulator would place this shape at ground level since the lower points have a y-coordinate of -0.54.

To correct the shape for Open Rails, replace the matrix element as below. This results in the shape on the terrain as show in the second picture.

matrix MAIN ( 1 0 0 0 1 0 0 0 1 0 0 0 )

This change to the shape does not affect Train Simulator as it was already ignoring this vertical offset in the matrix element.

Shifting the shape in Shape File Manager will not fix this problem as it will adjust the points and not the matrix which results in the trees placed partly below the terrain.

[OTTODAD]

To correct the shape for Open Rails, replace the matrix element as below. This results in the shape on the terrain as show in the second picture.

matrix MAIN ( 1 0 0 0 1 0 0 0 1 0 0 0 )

Are you saying that we will have to edit every shape file of objects which are flying ?

The flying weeds I have shown are "Forests". Will correcting their matrix place them on to the sloping terrain in ORTS but leave them where they are in MSTS ?

What value will have to be used to put them on to the terrain, it only having this one Matrix parameter shown below ?

O t t o

[kraus]

Since forests do not have shape files in the SHAPES directory, if forests are shown above terrain in Open Rails, then this will need to be corrected in the program.

The shape that you show should be on terrain since the y-coordinate is zero. If it is above the terrain then that is for some other reason than the matrix element. Could you attach the shape file or show the points element?

[csantucci]

Thanks to krausyao for the thorough analysis.

Are you saying that we will have to edit every shape file of objects which are flying ?

Well, I hope that the excellent OR people will modify their code to achieve compatibility to MSTS in this matter. Else a high amount of routes would need adjustment of some of its objects.

Carlo

[OTTODAD]

Since forests do not have shape files in the SHAPES directory, if forests are shown above terrain in Open Rails, then this will need to be corrected in the program.

This weeds5.s is in the route's Shapes folder but the Forest.dat is using it's ACE file:
Forest ( "WEEDS 5" "weeds5.ace" 5.0f 6.0f 0.9f 1.1f ) it seems to know where to find.

The shape that you show should be on terrain since the y-coordinate is zero. If it is above the terrain then that is for some other reason than the matrix element. Could you attach the shape file or show the points element?

Yes, all these weeds are on the sloping terrain in MSTS, one of my screenshots shows, but fly in ORTS.

Attached are all the weeds5 files.

I think that it is the "display forests code" in ORTS which needs looking at ?

O t t o

[OTTODAD]

Having nothing much else to do with train simming at the moment I tested other add-on routes, like my modification of the Shorty route and noticed these trees on the tracks.

There are also some misplaced objects in other routes, you may already be aware of.

O t t o

[mestevet]

The reason that the objects are floating above the terrain is due to the difference between how Open Rails and Shape Viewer interpret the matrix elements compared to Train Simulator.

The last three elements of the matrix element are the x-, y-, and z-coordinate offsets for the points that belong to the matrix. In the example below, the points are offset by 17.46 in the y-coordinate.

matrix MAIN ( 1 0 0 0 1 0 0 0 1 0 17.46 0 )

As show in the first picture this results in the trees placed above the terrain. The points for this shape are

points ( 8
point ( -33.0895 -0.54 5.8346 )
point ( -33.0895 35.46 5.8346 )
point ( 33.0895 35.46 -5.8346 )
point ( 33.0895 -0.54 -5.8346 )
point ( -31.5737 -0.54 -11.4919 )
point ( -31.5737 35.46 -11.4919 )
point ( 31.5737 35.46 11.4919 )
point ( 31.5737 -0.54 11.4919 )
)

Train Simulator would place this shape at ground level since the lower points have a y-coordinate of -0.54.

To correct the shape for Open Rails, replace the matrix element as below. This results in the shape on the terrain as show in the second picture.

matrix MAIN ( 1 0 0 0 1 0 0 0 1 0 0 0 )

This change to the shape does not affect Train Simulator as it was already ignoring this vertical offset in the matrix element.

Shifting the shape in Shape File Manager will not fix this problem as it will adjust the points and not the matrix which results in the trees placed partly below the terrain.

Are you saying that we will have to edit every shape file of objects which are flying ? O t t o

To me, this seems like it's the result of poor modeling practice with the shape files in question. I can't speak with authority for anything other than TSM, but proper modeling practice is to have the "Axis" for the "Main" shape in a TSM model at 0,0,0. It seems to me that in the case that Jeffrey outlines above, in TSM terms, the Axis for Main would be at 0, 17.46, 0 - and that is NOT recommended practice. The shape Jeffrey is showing looks like the part's Axis was centered on the model, because it appears to be exactly midway between the max and min values of the points listed. I understand that GMax, and perhaps 3DC handle axes/origins a bit differently, so I don't know if that means parts built with those tools are immune to this or not.

The thing the confuses me about this, though, is that I thought this would result in a vertical offset when placing the object in the RE, meaning the shape would've had to be shifted vertically when it was placed in the route originally, when it was built. Jeffrey, are you saying that MSTS is discounting that vertical offset, whereas OR is not?

Steve

{by the way, in a much earlier OR discussion, I mentioned that I'd be happy to help out with OR if modeling things would be of any help. One thing that might be of use to the OR team to "test" the program, is a set of really screwed up shapes. I have been slowly building a catalog of screwed up shapes, as a result of helping folks resolve problems with models they've built in TSM. While it might require permission from some of the original model builders, I could probably provide some shapes guaranteed to cause errors, if that would help them test error handling and/or issues with "odd/interesting" modeling practices, such as these offset shape Axes}

[sniper297]

Permission granted, I think you'll find most of the problem shapes came from me tinkering with Shape File Manager. ponver9.zip in the file library is the last PO&N version compatible with ORTS, you should find all my oddball custom weeds and treeblocks in there. Most stuff I deliberately offset down 1 meter or more to avoid floating trees and bushes.

[OTTODAD]

Permission granted, I think you'll find most of the problem shapes came from me tinkering with Shape File Manager. ponver9.zip in the file library is the last PO&N version compatible with ORTS, you should find all my oddball custom weeds and treeblocks in there. Most stuff I deliberately offset down 1 meter or more to avoid floating trees and bushes.

That does not explain why these trees I have shown are on the tracks, having been moved sideways by ORTS, nor why forests using ACE files do not put their objects on to the terrain in ORTS.

Perhaps ORTS has no function to deal with forests yet ?

O t t o

[kraus]

The thing the confuses me about this, though, is that I thought this would result in a vertical offset when placing the object in the RE, meaning the shape would've had to be shifted vertically when it was placed in the route originally, when it was built. Jeffrey, are you saying that MSTS is discounting that vertical offset, whereas OR is not?

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

The y-coordinate in the matrix of shape coalload.s was 3.51587 and changing it to 0 results in both Shape Viewer and the simulator showing the same with the load now in the car as shown by the attached picture.

One possiblity was the Route Editor was compensating for the vertical offset by alterting the position of the object in the world file, but that was not the case because both shapes had the same vertical position.

Static (
UiD ( 62 )
FileName ( MSForestline80A.s )
StaticFlags ( 00002000 )
Position ( -583.328 1 -162.938 )
QDirection ( 0 0 0 1 )
VDbId ( 0 )
StaticDetailLevel ( 4 )
)

Static (
UiD ( 63 )
FileName ( MSForestlineExtra80A.s )
StaticFlags ( 00002000 )
Position ( -440.853 1 -236.003 )
QDirection ( 0 0 0 1 )
VDbId ( 0 )
StaticDetailLevel ( 5 )
)

The shapes I used for this test were identified by Carlo in a post http://forums.uktrainsim.com/viewtop...rt=15#p1293499

[sniper297]

"That does not explain why these trees I have shown are on the tracks"

YOU haven't explained it, are those individual trees, tree clumps, or forest regions? Gotta check those in the editor, it's possible that they're misplaced due to shape file mistakes that MSTS ignored. As everyone has been saying, all them tree clump objects I hacked in SFM have screwball numbers in them.

[jovet]

Gotta check those in the editor, it's possible that they're misplaced due to shape file mistakes that MSTS ignored.

I'm guessing they're Forest trees. And those could be completely whack in Open Rails because MSTS uses a particular algorithm for "randomly" determining where Forest region trees are placed.

If someone places a Forest region across the track, it may luck out and be okay in MSTS, but in OR the trees could be in completely different places...such as on the track.