[CGW121]

This is from the shape file of a berm I am making.

volumes ( 1
vol_sphere (
vector ( 0 -6.246 175 ) 22.7431
)
)

The 22.7431 number is wrong. I know that it should be a larger number than the largets number within the brackets, which in this case is 175. What is the proper number to multiply by? I used to know it but have forgot it.

Also do berms need a bounding box? The sim acts funny when I use the berms I made, not too sure why.

[Genma Saotome]

CGW121, on 28 January 2010 - 10:33 AM, said:

This is from the shape file of a berm I am making.

volumes ( 1
vol_sphere (
vector ( 0 -6.246 175 ) 22.7431
)
)

The 22.7431 number is wrong. I know that it should be a larger number than the largets number within the brackets, which in this case is 175. What is the proper number to multiply by? I used to know it but have forgot it.

Also do berms need a bounding box? The sim acts funny when I use the berms I made, not too sure why.

A ballpark multiplier to use is 115% of the last number within the parens. I just eyeball a number rather than pull out a calculator... take 10% of the last number inside the parens, rounding up (e.g., 10% of 175 is ~18, then half of that rounding up (e.g. 9), add the two together ( 18 + 9 = ~27 ) and then add that back to the original number... 175 + 27 = 202, which is a bit more than 115% of 175. Objects that are really long... like 400m or more should be examined within the sim to verify all is well. Those really long ones require 120-150%, not 115%.

[CGW121]

Genma Saotome, on 28 January 2010 - 03:53 PM, said:

A ballpark multiplier to use is 115% of the last number within the parens. I just eyeball a number rather than pull out a calculator... take 10% of the last number inside the parens, rounding up (e.g., 10% of 175 is ~18, then half of that rounding up (e.g. 9), add the two together ( 18 + 9 = ~27 ) and then add that back to the original number... 175 + 27 = 202, which is a bit more than 115% of 175. Objects that are really long... like 400m or more should be examined within the sim to verify all is well. Those really long ones require 120-150%, not 115%.

Which would be why the editor would take a dump when I would jump back to a tile using one of the long berms.

[Huecuvoe]

There is no such thing as a "vol_sphere multiplier".

The vol_sphere defines a sphere in 3-D space centered at coordinates X, Y and Z (relative to the origin of the shape file) with a radius R (all in meters). For the model to function correctly in MSTS, all points in the mesh of the shape file should be contained within this sphere. Although the radius value does depend on the center coordinates, it is a primarily a function of the size of the model. Simply scaling from the X, Y and Z values does not work in most cases (e.g., X=Y=Z=0).

vol_sphere ( 
     vector ( X Y Z ) R 
) 

For some reason, TSM has a trouble doing this calculation, especially for long skinny objects. TSM usually does a good job of calculating the center of an object so I assume your berm is a long skinny object between Z=0 and Z=350. If the MAX/MIN X and Y are less than +/-50, then a conservative R value can be calculated as:

R = √( (175)^2 + (50)^2 + (50)^2 ) = 188.7458609 ~ 190

This R value would not be useful if TSM has miscalculated the center coordinates or if the X and Y extents are larger. If, for example, the berm actually runs from X=-150 to X=+10, then the required R would be:

R = √( (175)^2 + (50)^2 + (150)^2 ) = 235.849 ~ 240

Dave's 15% to 25% probably works OK in this case, but it ain't always necessarily so.

[CGW121]

Thanks I got them working properly. Now to figure out how to do curves.

[captain_bazza]

Quote

The sim acts funny when I use the berms I made, not too sure why.

What I know about the route editor you could engrave on the point of a pin, and still have room for the 'Rhyme of the Ancient Train Simmer', but there is the provision for an object to be a terrain object. The berm is sort of in this category. This might give it special properties? It's worth a try.

Cheers Bazza

[Genma Saotome]

The use of the "Terrain Object" attribute has something to do with keeping the display of the track above and the terrain object below, even if they're at the same altitude.

Shame Kuju wasn't able to cast shadows on these kinds of objects... it's only real terrain that shows it.

[CGW121]

Since berms go under track, like bridges they must be set as terrain objects. It has to do with the viewsphere value, which the route editor is extreemly fussy about. At another forum you mentioned Sketchup Dave, is there a huge learning curve? Can I import from TSM? And is there a bug like the one in topic here?

[Genma Saotome]

SketchUp is extremely easy to learn and there are many fine tutorials on Youtube (a number of good ones from Google). It does not import or export TSM models. And the export has the same problem in generating the vol-sphere value. I make a point of checking the .s file value for any berm that's longer than 35m.

I expect you'll find it much easier to use than TSM.

Over in the General Modeling tools forum, I have posted "SketchUp for MSTS". Some of what I wrote you need in order to get started, some of it won't make any sense until much later on. Anyway, the most important tip I can give a SU noob is to go to the Styles page and find the tab where you can toggle ON Display End Points -- a.k.a. vertex points. SU has a great tendency to give you those where you really don't want them and if you don't have display on, you can't see what it's doing. Ignore it and you get way too many polys. They can be culled but it does take time to do.