[jared2982]

steamer_ctn, on 30 March 2018 - 03:48 AM, said:

ii) ORTSShapeCentre - used to offset the shape in the Z direction as discussed. As a potential new feature, it may also be useful to allow the Y value (height) to be used to raise or lower a wagon slightly if it is not sitting on the track correctly.

I think this is a wonderful idea. Many steam engines use the CoG entry to get the position of the tender adjusted correctly. In addition to the Z and Y values I would like to suggest also allowing the use of the X value to offset the shape left and right. My current route has dual gauge trackage and the only way to allow the interaction between standard gauge and narrow gauge is to offset a models origin, if you have access to the source files. Trying it any other way sometimes has undesired consequences. Currently we have to build separate models with offset center points to accomplish this. Allowing the use of the X value would allow us to offset any model for use in this manner, or to adjust any model that might not be quite centered on the rail like it should be.

[steamer_ctn]

Hi James,

James Ross, on 30 March 2018 - 09:17 AM, said:

I agree with Peter that adding new ORTS parameters to explicitly set visual position, physics CoG, etc., would be useful, even if it would not help the existing content.

If of assistance I could add the two new parameters and remove the Z value restriction, but I wouldn't have a clue how to implement the X and Y value changes.

Do you want to take ownership of this potential change, including the possibility of offsetting the X and Y values (as suggested in post #31)?

Thanks

[James Ross]

steamer_ctn, on 30 March 2018 - 05:07 PM, said:

If of assistance I could add the two new parameters and remove the Z value restriction, but I wouldn't have a clue how to implement the X and Y value changes.

Hmm, yeah, it's fun. I guess we'd need to shift the bogies in X and Y as well as Z, but the Z change seems to be done dynamically at runtime and not during loading - and I don't know why. :(

steamer_ctn, on 30 March 2018 - 05:07 PM, said:

Do you want to take ownership of this potential change, including the possibility of offsetting the X and Y values (as suggested in post #31)?

It looks like adding an ORTS parameter for the centre of gravity for physics should be easier to do, and we leave the model adjustment as-is using only the old MSTS parameter (and keeping the limit). That should be achievable by switching the code in TrainCar.cs to use "InitialCentreOfGravityM" instead of "CentreOfGravityM", leaving the latter free for the physics.

You're welcome to work on the new physics parameter, and I'm happy to check over the changes if you have any concerns/questions. We'll keep the model shifting on hold for now.

[steamer_ctn]

Hi James,

James Ross, on 31 March 2018 - 05:58 AM, said:

You're welcome to work on the new physics parameter, and I'm happy to check over the changes if you have any concerns/questions. We'll keep the model shifting on hold for now.

Attached is a potential patch to add the extra parameters discussed.

I will leave it up to you to incorporate model shifting into it as and when you see fit to do it. Please commit it when you are ready.

Attached File(s)

•  CoG_patch.zip (1.89K)
  Number of downloads: 627

[ErickC]

It will probably be a useful feature, but it's pretty sad that MSTS model builders are so bad, on average, at getting the basics of good model building right that a crutch needs to be devised for them.

[slipperman]

Hi,

ErickC, on 01 April 2018 - 12:07 PM, said:

It will probably be a useful feature, but it's pretty sad that MSTS model builders are so bad, on average, at getting the basics of good model building right that a crutch needs to be devised for them.

Sorry, Erick, but I think that is an uncalled for slur on many contributors to the MSTS Community. It is, after all, mentioned in the MSTS TechDocs, dated 9 May 2001 :

Quote

The centre point of the vehicle is defined in CentreOfGravity (x, y, z ) “z” value.

Cheers,
Ged

[ErickC]

It's the truth. You might not like it, but it is. Many models with these issues looked that way in MSTS, regardless of what parts of the physics OR chooses to ignore. People exploited that parameter to correct problems with models that were released in a state of floating above or sliding below the rails. It wasn't used by model builders to position their models, because they didn't care. They just released them that way and left the user to "fix" the problem. Fixing it for real is as simple as moving a pivot and re-exporting. In other words, fixing a model that does not sit right literally takes five seconds of actual effort for the model builder.

It's a good thing that OR is getting a parameter to deal with the problem, but the fact remains that a long-standing problem with MSTS models, that goes all the way back to 2001, is that developers put all that effort into detail parts and textures without spending a few seconds ensuring that the model was actually going to sit on the rails correctly, or that the ends of the couplers were equidistant from the pivot. This isn't to say that the models were bad or the builders did an otherwise poor job, indeed many of my favourite models suffer from misplaced pivots. But MSTS model builders, on average, were very bad at setting top node pivots properly. Most of them just didn't care. I think most contemporary model builders are a bit more aware. This is a good thing. I've never run a Tyler Bundy model that didn't sit exactly where it was supposed to, for example.

[darwins]

Need to say here Erick, that it can take a lot more than a few seconds to re-centre a steam loco model with complex valve gear (well at least if making in TSM).

So variations of a class or group of locos might use the same driving wheels and valve gear but have different frames or bogies, making them say four inches longer.

So moving the model centre back takes a few seconds - then all the valve gear will animate in the wrong place.

To move all the animations can take several hours - 10, 20 or 30 moving parts with 8, 16 or even 32 frames animation to edit for each. Then recheck for mistakes.

Having a small adjustment that can be used in OR will make life much easier.

(That is without thinking about the y direction - I build models to sit nicely on UKFS track... which results in their wheels being buried in the default track - life would be easier if the datum chosen was the top of the rail rather than the ground.)

[ErickC]

Nope. I just ran some tests in TSM and literally all you have to do is move the top node's pivot. Transform|Translate, select "axis only," enter whatever number will place the pivot in the right spot, and the child animations work just fine.

Wait - you were aware that the origin of the project in TSM and the exported model's center have nothing to do with each other, right? Does the TSM documentation not make this clear? Because that would explain a lot of the miscommunication between me and TSM users on the subject elsewhere. If you were trying to fix the problem by moving the model, then you would indeed have major issues, as FSDS/TSM does not move the pivots with the parts (which is out of the ordinary, but there must be some reason I guess).

[darwins]

Good news and bad when I finally tried this with a more complex model.

Exactly as you say - move the top node (in this case closing up an engine tender gap that would otherwise be too large) and the animation still works perfectly.

Unfortunately some of the other parts of the model shifted for no apparent reason.

http://www.atomic-album.com/showPic.php/121473/gaps1.jpg

Having all parts centred to the new model centre brought some parts into line. Changing the hierarchy (parents and children) got some other parts into line. Some parts want to stay in the wrong place whatever...

So the easy solution again becomes adjust the model centre in the eng file using the "CentreofGravity" line z value. :wacko: :wtf01: :(

[ErickC]

Are you moving the top node or just the top node's pivot? The former will cause issues, the latter won't. I made a more detailed post at trainsim.com:

Quote

So I just downloaded TSM and ran some tests. Indeed you can move the top node's pivot to your heart's content without affecting the children's animations. What I think is missing here is an understanding that the origin in TSM and the center of the final exported model have absolutely nothing to do with each other. The location of the top node's pivot determines the model center. I think that TSM users have been trying to solve the problem by moving the entire model and then moving the individual part pivots (since TSM doesn't move them with each other for whatever reason). The solution is as simple as opening the translate dialog box, selecting "axis only," and then moving the pivot to a place that will put the model in the right place.

To calculate the amount of translation required, you will need to locate the correct edges of the model and find the average between them. The simplest way to do this would be to find the z-axis (fore/aft) location of one vertex on the front coupler or buffer, then find the matching vertex on the opposite coupler or buffer, add the two values, then divide by two. This will give you the proper location of the top node pivot. Then it's a simple matter of finding out where that pivot presently is, and doing some basic arithmetic to find out how much translation is required.

I'll walk you through an example. Let's say I have a locomotive that is off-center, and let's presume that this locomotive has buffers at each end. So I select a single vertex from the furthest forward part of one of the front buffers, and get a z-value of 10.125m. Let's say I then select the furthest aft vertex of one of the aft buffers and get a z-value of -10.250m. I then add these two values together to get -0.125m, and divide by two to get the correct location of the model center, which is -0.0625m. Let's say the top node pivot is located at a z-value of 0m. I then simply translate the pivot -0.0625m by entering that value in the translate dialog and clicking "axis only."

Let's say I did all the same work, but the top node's pivot was originally located at z=-0.213m. Subtract -0.213 from -0.0625 to yield +0.1505m.

Note that what TSM calls the z-axis, 3DS/GMax calls the y-axis. Most Max users are probably already familiar with the "affect pivot only/affect object only/affect hierarchy only" buttons on the hierarchy tab, though.

[darwins]

Only the pivot was moved.

In short I made the first model - centred at origin.

Converted to second variation 0.304 m longer at front end. Following the instructions selected "Main" (the top of the hierarchy) and selected move axis only 0.152 m in the z direction.

Did not move any parts of the model at all in TSM. (Had I done that as previously discussed I would have messed up the animations anyway!)

[ianmacmillan]

Easy way to move the model in TSM is to measure the distance between the buffers or couplings.
Then make a box of that length.

Select all parts (A) and deselect the new box.
Then slide the parts to fit inside the box and re-centre the main part to origin.
The pivots for animated parts should move with the part.

[darwins]

Moving all parts to fit the new centre works fine for rotations as rotations are about the centres of the animated parts.

The problem with TSM is that the animations of motion (as opposed to rotation) are based on the origin and do not move when you move the parts.

[darwins]

I am now thinking that what Erick said earlier might work if all parts are children of "Main" (that is there are no grandchildren)... I will try changing the hierarchy and see what effect that has.