Placement of road shapes in error

Use this forum if you found a bug.
Dave Nelson
Posts: 19
Joined: 24 Dec 2019, 03:38
When the tsection.dat specification puts the path above the shape you cannot place shapes so they snap together in a smooth line. Instead the new shape's origin point is placed where the path is located which produces a stair step like assembly. The use of snap to selected does not appear to make any difference in this situation.
TSRE Bug.jpg
TSRE Bug.jpg (126.69 KiB) Viewed 10922 times
Here is the tsection spec:

TrackShape ( 25524
FileName ( gR_All_2Lb_21f_010m.s )
NumPaths ( 2 )
Sectionidx ( 1 -1.6764 0.2 0 0 0 )
Sectionidx ( 1 1.6764 0.2 0 0 0 )
RoadShape ( )
)

The path is supposed to be 0.2m above the origin point because the shape itself is located 0.2m above the origin point. The reason for the lift is the road is arched using a 2% slope outside of the two center lines (not shown in the image above).

These shapes are being built as a modular system -- center lanes in one shape, outer lanes in their own shape. That allows for mix and match of appearances, such as center lanes for a streetcar, outer lanes on one street in concrete and in another asphalt. This approach minimizes the number of tsection entries as well as helping to get the total number of models to make down to 1/3 as compared to doing things the traditional way.

The specification for the outer lanes (in their own shape) will put their paths a bit lower (they're on a slope away from the center) and they include the 2% tip so cars will run slightly tipped -- as they do on real roads.

As things are right now I cannot correctly place any of these road shapes.

User avatar
Goku
Site Admin
Posts: 363
Joined: 15 Jan 2019, 18:10
Location: Poland
Contact:
I don't understand the reason for such shape definition. Don't expect fix in near future.

Dave Nelson
Posts: 19
Joined: 24 Dec 2019, 03:38
Because the shape of the road is an arch there is a different height for the path in each lane.

I concluded lifting the faces of the center lanes by 0.2m combined with a 2 degree slope outside of the slow lanes will put the gutter of a 6L road on the ground. That means the paths for the slow lanes will be lower than the fast lanes in the center of the road.

I considered simply elevating the center lanes by 0.2m after placement. That would work for the paths in the center but it means the paths in the slower lanes to the outside will be above the surface of the street. IOW the cars will be floating.

Here is the road and it shows the locations of the paths for each lane.
road profile.jpg
road profile.jpg (126.97 KiB) Viewed 10910 times
As you can see the elevation of each lane is different. W/O dealing with the differences in path height the cars in the slow lane will be floating 11cm above the road. AFAIK the only way to properly define the location of the paths is within the tsection data and to do so exactly as I have done. If the road shapes were placed per their .s file origin points it would all work.

Anyway, the tsection spec I wrote appears to be correct but the editor will not correctly place the objects at their origin point.

If there is a procedural solution I can use I'll give it a try.

User avatar
Goku
Site Admin
Posts: 363
Joined: 15 Jan 2019, 18:10
Location: Poland
Contact:
Did you try to have one "main" path at y=0?

Dave Nelson
Posts: 19
Joined: 24 Dec 2019, 03:38
The shapes were originally built as these sort of things have always been built -- road surface at 0,0,0 and a tsection definition to match. They placed normally. I could lift the first one as needed and all of the rest would snap to the correct location.

I then went back to the shapes and raised the faces 0.2, exported them, and edited the tsection data. I don't recall now whether I deleted the original placements before trying to use these or later. What I observed is the placement of the first section in any new location was as expected -- the origin point was on the ground, the faces were elevated. Happy with this I then started to add additional sections. Each additional section was 0,2m higher than the one that was placed before. Place 5 and then next one would be 1m above the ground.

I don't know what is in the code but what it looks like is the code is using the path values in the tsection file instead of the origin point to place these shapes.

I can send you the shapes, textures, and tsection data if that would be of any use to you.



FWIW I'm building this as a modular "mix and match" set of shapes. The initial placement use generic shapes -- they're not textured for a road. At some later time I will replace the generic shape with a static "display purpose" shape via an edit in the world file. IOW the generic shape is used to create the path in the .rdb but something else is used for display in-game. This allows me to create a handful of generic shapes, document them in the tsection file, and then create as many substitute shapes as I might want -- asphalt, cobblestone, concrete, gravel, and streetcar -- and do so w/o having to put all of them into the tsection file. Any substitutions (at any time) can be done by anyone w/o any effect on the .rdb data.

User avatar
Goku
Site Admin
Posts: 363
Joined: 15 Jan 2019, 18:10
Location: Poland
Contact:
You can send me these shapes with tsection file. I can look at this problem if I have some time.

Dave Nelson
Posts: 19
Joined: 24 Dec 2019, 03:38
I think this archive contains everything you need. \Shapes and \textures contain only the items in question. The tsection.dat file has unsubmitted entries so I suggest being careful to not over-writing another tsection file you need to keep.
Global.zip
(540.36 KiB) Downloaded 432 times
Thanks for looking into this problem.

Dave Nelson
Posts: 19
Joined: 24 Dec 2019, 03:38
A bit more information.

The tsection file has a parameter value for path elevation above the shapes origin point. It has almost never been used and it seems in those few cases where it has been use it had the same problem as I described in this thread.

What is particularly interesting about this is that while KUJU never used a non-zero value it appears they hardcoded the track path to be 0.325m above the track orig point. I suspect it was simply much faster and easier to do that than edit the tsection file to find and change the relevant zero.

Given the above, here is the straightforward problem statement with things as they are now: Whenever you have tracks in a street and are using TSRE you cannot do copy/past object rotation and location from one to the other and get a proper alignment. There will always be a 0.325m gap between the two.

I'd show you a picture right here but I don't see any means to upload the file....

Given there are virtually no track shapes with the correct offset it seems to me the easiest fix is to craft a few customer road shapes where the top of the road (and the path for any carspawner) is 0,325m above the origin point of the shape. Pretty much what I was trying to (tho in hindsight at the time I had not yet realized the true nature of the problem).

User avatar
Goku
Site Admin
Posts: 363
Joined: 15 Jan 2019, 18:10
Location: Poland
Contact:
TSRE doesn't use any .325m offset. Never saw it and also it would look ugly.

Dave Nelson
Posts: 19
Joined: 24 Dec 2019, 03:38
Goku wrote: 12 Jan 2021, 12:42 TSRE doesn't use any .325m offset. Never saw it and also it would look ugly.
Yup... that's every MSTS track shape every made.

I guess I didn't write clearly enough. The path trains follow is always 0.325m above the origin point of the track shape. ALWAYS. This is defined by KUJU who picked that dimension while leaving the origin point of the shape at zero. The could have used the Tsection file to specifiy that offset but they didn't -- they left the tsection value at zero and instead hardcoded a path offset of 0.325m for all train patyhs. By train path I mean where the bottom of the wheels will be. That is the problem but that problem does not become apparent until you try and put track and road together.

Of course almost every instance you can find with real track and real roads occupying the same location the top surface of each is identical... or at least very close, There is not an easy way to achieve this in either KUJU's RE or TSRE w/o manually figuring out how much to raise or lower these shapes so the carspawner and train paths are about the same.

My preferred solution is to ignore the problem in track shapes -- too hard to get everyone to implement a code fix AND tsection distribution at the same time and instead take a look at roads only.

That's what I tried to do with those road shapes... put the origin point at zero, same as a track shape, but raise the road surface to about 0.325m higher to align the road surface with the top of the rails. IOW build the road the same way all MSTS track is built. To make carspawners work I put that offset into the tsection definition of the road.

Not all roads would be done this way... only those with tracks running in them.

I thought that would work but when trying to place the roads in TSRE the result was that "stair step" appearance. I don't know what is in the TSRE code but it looks like you are using the vertical offset value of the tsection to place the road instead of the shapes own origin point. I'm not saying that's what is going on, only that it LOOKS like that.

If you could fix that placement problem then I could test where OR is using that tsection offset for carspawners. If it is wrong then bug report to them.

Post Reply