Sorry your browser is not supported!

Can anybody tell me how the calculation of the visual objects inertia was calculated in the rigid body designer tool(RBD.exe) that comes with Newton wrapper 1.53?

I can confirm the tool is using the box calculation method for the visual object of the fiero.bod, yet the results I get from using the command to calculate box inertia(NDB_CalculateMIBoxSolid), do not match the results produced by the tool.

I have even checked a cube of size 1.0 in the tool against the results of the same command, the command produces uniform values for inertia on a cube but the rigid body designer tools x and y values are different, the z value DOES match the z result of the command, just the x and y values are different, they are slightly less, although they are both the same value as each other:

*I used a mass value of 200
tools box calculation results of 1.0 cube:
Ix=29.17, Iy=29.17, Iz=33.33

newton box calculation command results of 1.0 cube:
Ix=33.33, Iy=33.33, Iz=33.33

If a visual object for the body is present the tool appears to use this to get its sizes from for the inertia calculation, if not it will use first primitive created - it basically seems to use the first object loaded/created. That is how I was able to test the cube's results. I also checked the contents of the fiero.bod file against the tools results of the same visual object when loaded into a fresh project, this is how I can confirm the tools own box method was used as the results are the same.

So should I be doing something other than use the command on it's own?

Bump, anyone? Getting desperate now lol!

To clarify, i=(m(a^2+a^2))/12 is the same as the command NDB_CalculateMIBoxSolid.

The results of a uniform cube using the NDB tool show that the x and y results as less than the command's results. However using the fiero.x object with the tool, the x and y results are considerably greater than the command results.
I also checked a uniform cube of a size larger than the fiero.x models longest side, the cubes results show same pattern - the x and y results are also less than the command/manual calculation.

Fiero.x results(Mass 200, Size x 7.97, Size y 1.96, Size z 3.34):
NDB tool - Ix=429.25, Iy=1424.76, Iz=1124.23

i=(m(a^2+a^2))/12 OR NDB_CalculateMIBoxSolid - Ix=250.96, Iy=1246.47, Iz=1124.23

There must be some physics wizards around surely who can at least suggest what might be going on? I really need/want this calculation as well as understand it. In fact this bothers me so much I wonder if my need to understand is greater than my wanting the use of the calculation lol!

Regards

This is not my area of understanding.

If you have not already received a reliable answer from within Newton Physics plugin community, or the plugin developer, I wish you the best of luck finding it.

Thanks Chris, I did get a response from Kjelle69 who updated the wrapper around v1.32. User tiresius did latest version and I think it was walaber who started and updated it up to v1.32. Kjelle69 said

walaber has not responded. I have only just sent tiresius an email. I couldn't find anything on any of the forums, have even gotten to reading stuff there not related in the hopes something might twig. No luck so far though.
I replied to Kjelle but heard nothing back, I am guessing that is all that he/she has to say about it. Am currently trying to track down who created the tool, because I believe some other calculation was made to mimic centre of gravity, as the cg(centre of gravity) cannot be gained from the models data - a cube is uniform with a centroid dead centre. The tools mass inertia calculation results should show uniform results which suggests a new centre of gravity is imposed, so the mass inertia commands cannot have been used alone. The Newton.dll required in the executable's folder for the tool is also older than the latest wrapper version, I swapped it out, it ran with one error but continued anyway and the mass inertia commands gave the same results a the latest updated 1.53 version, so it is something definitely written in the tool and not the wrapper. So really I need to find out who wrote it, ask them, hope its not an old contact address should I even find one and then hope that they respond...favourably! So odds aren't looking so good so far, the further back in time I go in searches the more dead links I come across, I have so far read one post by walaber asking if anyone would care to make the RBD.exe tool, but saw no responses.

Hello sorry I have not played with Newton physics for a long time and actually never used the RBD tool. I always manually made rigid body shapes. Sorry can't be of more help.

You could always make your own RBD tool, might be fun ?

Hi tiresius thanks for the response, that is what I am doing, I used to use the tool years ago while just playing around really, but then had issues running it on win10 some time back. I am back on win7 now so thought I would do my own version as I recalled that even with RBD tool it was a pain in the neck to make and tweak vehicles. What I have so far allows me to manually recreate the fiero example 6 vehicle or any vehicle and works just fine, I can have extra wheels, manually align them and rotate the actual wheel all using the gizmo plugin...but there are some things yet to be done and having the center of gravity option where I could just manually place it then click on a button to do a fresh inertia calculation to account for the new centre, correctly, would be nice. So far I am stuck with having to load a mesh into RBD tool if I want to use this weird offset that appears to exist. I am just trying to stick close to the example. It looks like walaber wrote this tool in DBP but didn't want to progress it himself. I do seem to recall a conversation in these forums about the existence of the imposed offset and the reasons behind it, but I cannot find it and I don't even recall if the values and calculation where mentioned. I want to be able to add a new centre of gravity which there is a command for, but it does need a new inertia calculation to account for it. The code for solid box inertia was easy to work out for centroid from google searches and was able to confirm results using the newton command results for comparison...but I only have guesses as to what I do exactly with the new centre of gravity. I then have no way of confirming guesswork results as correct which is why I really wanted to know about RBD tool.

Edit:
I thought I read you was considering updating to 2.0 years ago, is that right/how far did you get?

I did not get to update to Newton 2.0 there was someone who had gotten bare-bones dll started but the project never went anywhere.
I'm (still) not a real C++ programmer so even finishing the minor update to 1.53 took a lot of work for me to get it going.
Newton 2.0 / 3.0 / latest is a lot different from Newton 1.x so it would probably need a complete rewrite.

Well thanks for what you have done already

Ah! I'm of no use, but this reminds me I used to have a great Newton physics demo downloaded from somewhere in the forums here but I lost it. Would like to recover it if possible... does anyone by chance recall such a demo? It had some stairs and some bullet textures, etc. It was a simple, yet flawless demo.

There is a demo matching that description that comes with the wrapper - demo 5 fps example

Bump. I did work out the right calculation for this some time ago - it is Ixyz=Icm+md^2 where Ixyz=Inertia along any axis of an altered centre of gravity, Icm= Inertia of a centroid - basically symmetrical centre of gravity - this is the result from the calculation mentioned earlier(i=(m(a^2+a^2))/12), m=mass and d=distance from centroid, I was just holding off making unnecessary posts as this is still not solved, the 2 calculations where only part of it and there's nothing worse than making post after post in a short period of time with nothing of value to show for it. I was able to work backwards obviously by using the target results with that calculation and determined the centres of gravity. Looking at it on 2 models(cucumbers bmw and the fiero example) the centre of gravity is located roughly forward and up near front of dashboard in both cases - the real centres of gravity for vehicles in real life are definitely not situated where I found them!

So if I have worked it out then why is it not as simple as this? Because Walaber put in some calculation to get the centre of gravity prior to making the calculations, well at least not get it but produce it where he felt the results of the inertia affected the vehicle best. What I seem to recall is that I think he mentioned something along the lines of it needed to be relatively close to the actual centre of gravity. He is also definitely only using the objects data to influence this formula's output.

On top of this issue he is somehow either getting a negative result in certain situations purposefully or it's an error - because you may notice in either calculation there is the power of 2 used - which will never yield any negative number. This is shown in the results of the 1*1*1 cube above. I think it is purposeful on the basis that it would be impossible to get a negative number from those inertia calculations - which reinforces my thoughts that not just internal commands where used. Then again I suppose it could be undesirable results rather than an error, but based on what I mentioned early on I doubt it(that uniform objects have two results less than the third - and the third result is correct(z axis)). It would have to be a negative value to yield the results of the cube because the altered centre of gravity calculation involves adding the centroid results to the second part of the calculation. I can't even check slightly less uniform object results because since M1U plugin had some dll's just stop working on my rig, the RBD tool has also stopped working...this is the very reason I started this project lol. At least now I know that it was a change in my systems software somewhere along the lines that caused it. What I don't get is why Walabers tool stopped working(written in dbp) even though my own exes prior to the m1u compile issues still work!

One interesting thing I have noticed just now - in the actual vehicle demo 6 - even though inertia results for altered centre of gravity are used, at no point did anybody use the actual command to finalise the new centre of gravity!!! Could be purposeful, might not be though as I spotted a mistake in the code for velocity - where vector axis' xxx are used instead of xyz and if there's one mistake, well enough said. One thing I forgot to mention at the beginning of all this - the cars body(of which the sizes are used to make the calculation) is non centroid as its pivot point is at the base of the model not the centre. I think the reason we treat it as centroid is because the vehicle is an invisible box so the cars body bounds are actually only the top half of the entire vehicles mass. When I render a transparent object of same dimensions as body frame with object bounds showing and orientated/situated to match the vehicle, the behaviour of the vehicle makes more sense. This does mean that mass should be doubled really as should the y dimension...something I should look into soonish. I also seem to recall someone saying they had to double the mass to get things to work better - pretty sure this was kjelle as I also recall them saying that both themself and Walaber had to almost double the mass(kjelle worked on the wrapper after Walaber which is why I think it was kjelle who said it). The real question there is why they didn't double the height of the vehicle body frame in the inertia calculation - otherwise the calculation seems, well, wrong.

So what would help me now is suggestions on a way to guesstimate this centre of gravity which is nowhere near a real centre of gravity in real life, along with any suggestions on why uniform objects have a negative result in x and y axis even though ^2 is used! I can leave it to the end user to place the centre of gravity themselves, but I would rather they had 3 choices than 2 especially as I may be entirely wrong and the Walaber calculation might be 100% correct for all I know (3 choices being, centroid mass, their own manual positioning of a new centre of gravity and the 3rd being Walabers automated version).

Edit: Forgot to mention that the dimensions of Walabers offset in the z axis does not change but the x and y - are actually the same offset values for fiero and either the same or very close to one another for the bmw(probably the same - I can't quite recall, if anyone feels that this bit is important I will double check, just ask).