CustomMultiBodyVehicle Joint

A place to discuss everything related to Newton Dynamics.

Moderators: Sascha Willems, walaber

Re: CustomMultiBodyVehicle Joint

Postby JernejL » Sun Jan 24, 2010 4:33 pm

Stucuk wrote:
PJani wrote:Offtopic: In process i found 3d max have negative Y(in newton and ogre Z axis) axis i have never notice that. :shock:


Most modelling applications seem to have Z as Height instead of Y, you always have to swap Z and Y around and then flip either the new Y or Z axis (Can't remember which) to convert to a Y = Height system. I always find it funny how they go against maths (In a 2D world Y is height, so in a 3D world all you add is Depth, meaning the new "thing" is Z. Re-inventing the entire coordinate system for one more dimension is stupid).


It depends on how you look at 2D world, you can look at it from sideways as a sidescroller and add a extra Z in that coordinate system as sideways, or as a top down game, which would have Z added in the height direction.

I personally prefer Z as "up", because it makes sense and is used same in real world applications (think GPS, aircraft avionics, etc..) it is also easier to logically reprisent X and Y going across the ground.
Help improving the Newton Game Dynamics WIKI
User avatar
JernejL
 
Posts: 1587
Joined: Mon Dec 06, 2004 2:00 pm
Location: Slovenia

Re: CustomMultiBodyVehicle Joint

Postby PJani » Sun Jan 24, 2010 7:23 pm

OgreMax(exporter for 3ds max) does convert left hand coordinate system to right, but the problem was, i was inserting wheel offset coordinates by hand, every time i was doing this i swapped Z to Y, but i have not notice of negative Y(in newton Z) axis which was causing unexplained swapped left and right wheels and other attached stuff. From Newton 1.35 till now i was like this -> :shock: .
| i7-5930k@4.2Ghz, EVGA 980Ti FTW, 32GB RAM@3000 |
| Dell XPS 13 9370, i7-8550U, 16GB RAM |
| Ogre 1.7.4 | VC++ 9 | custom OgreNewt, Newton 300 |
| C/C++, C# |
User avatar
PJani
 
Posts: 448
Joined: Mon Feb 02, 2009 7:18 pm
Location: Slovenia

Re: CustomMultiBodyVehicle Joint

Postby Stucuk » Mon Jan 25, 2010 2:21 pm

Delfi wrote:It depends on how you look at 2D world, you can look at it from sideways as a sidescroller and add a extra Z in that coordinate system as sideways, or as a top down game, which would have Z added in the height direction.


Thats actually a flawed way to look at it. X and Y are already defined in a 2D world, so all thats left for depth is Z. Reinventing the coordinate system instead of using the previous dimensions as a basis is just stupid. When your doing calculations everything should be the same, Y should always be Y in every amount of Dimentions, you shouldn't have to convert everything just to make it so you can convert stuff from a 2D world into a 3D world or visa versa. Its like if each Newton command was renamed between each release(Talking about 2.10->2.11 type of release) when Julio had only added a single new method.

P.S Just because alot of people wrongly use Z as Height doesn't mean its right.
User avatar
Stucuk
 
Posts: 801
Joined: Sat Mar 12, 2005 3:54 pm
Location: Scotland

Re: CustomMultiBodyVehicle Joint

Postby JernejL » Mon Jan 25, 2010 2:33 pm

Stucuk wrote:P.S Just because alot of people wrongly use Z as Height doesn't mean its right.


It doesn't mean it's wrong either ;) BOTH are correct, and i can give you a example of a very succesful gaming franchise which uses Z as "up" since 1997 and across many engines on many platforms they built for it: the grand theft auto series.
Help improving the Newton Game Dynamics WIKI
User avatar
JernejL
 
Posts: 1587
Joined: Mon Dec 06, 2004 2:00 pm
Location: Slovenia

Re: CustomMultiBodyVehicle Joint

Postby Stucuk » Mon Jan 25, 2010 4:42 pm

Its wrong because its not mathimaticaly right. You don't destroy the coordinate system that was made up for a 2D system when you add a new dimension. Topdown games do not "prove" anything, even if you make a true 3D topdown game. Just because you are looking through a flat monitor doesn't make Height have to be Z.

Its a simple case of inheritance. When you make an object that does the same thing as a current one but slightly different, you don't make a new one using a completely different system, you make your class inherit the old system (Aka 2D) and just add what the new system (Aka 3D) has and the old doesn't. Its completely illogical to reinvent basic maths each time a dimension is added. With your way we might as well make + turn into a * when there are 999 Dimentions, just because GTA creators may have wanted to do that.
User avatar
Stucuk
 
Posts: 801
Joined: Sat Mar 12, 2005 3:54 pm
Location: Scotland

Re: CustomMultiBodyVehicle Joint

Postby JernejL » Mon Jan 25, 2010 6:14 pm

Stucuk wrote:Its wrong because its not mathimaticaly right. You don't destroy the coordinate system that was made up for a 2D system when you add a new dimension.


Are you kidding me? ANY system IS mathematically correct, Z height and Y height, they both are, there is no right or wrong, you may even choose to have X axis as "down" if you so desire and it won't be "wrong".

Assigning letters to axis is like naming puppies - any is good as long as you know which direction it points at :)
Help improving the Newton Game Dynamics WIKI
User avatar
JernejL
 
Posts: 1587
Joined: Mon Dec 06, 2004 2:00 pm
Location: Slovenia

Re: CustomMultiBodyVehicle Joint

Postby Stucuk » Mon Jan 25, 2010 8:15 pm

Mathematically correct is different from going against maths. Maths states what a 2D world is, Y is Height. A 3D world is just a 2D world with depth, which means logicaly Z is depth and not A,B,C,D,E,F,G,H,I,J,K,L,M,N,O,P,Q,R,S,T,U,V,W,X or Y. Which is one reason you hear people calling depth buffers "z-buffers" and not "y-buffers".
User avatar
Stucuk
 
Posts: 801
Joined: Sat Mar 12, 2005 3:54 pm
Location: Scotland

Re: CustomMultiBodyVehicle Joint

Postby PJani » Mon Jan 25, 2010 8:39 pm

Stucuk wrote:Mathematically correct is different from going against maths. Maths states what a 2D world is, Y is Height. A 3D world is just a 2D world with depth, which means logicaly Z is depth and not A,B,C,D,E,F,G,H,I,J,K,L,M,N,O,P,Q,R,S,T,U,V,W,X or Y. Which is one reason you hear people calling depth buffers "z-buffers" and not "y-buffers".

Delfi wrote:
Stucuk wrote:Its wrong because its not mathimaticaly right. You don't destroy the coordinate system that was made up for a 2D system when you add a new dimension.


Are you kidding me? ANY system IS mathematically correct, Z height and Y height, they both are, there is no right or wrong, you may even choose to have X axis as "down" if you so desire and it won't be "wrong".

Assigning letters to axis is like naming puppies - any is good as long as you know which direction it points at :)


Anyway 3ds max uses left hand XZY coordinate system and newton uses right hand XYZ coordinate system. And XYZ are named becouse of defacto.
| i7-5930k@4.2Ghz, EVGA 980Ti FTW, 32GB RAM@3000 |
| Dell XPS 13 9370, i7-8550U, 16GB RAM |
| Ogre 1.7.4 | VC++ 9 | custom OgreNewt, Newton 300 |
| C/C++, C# |
User avatar
PJani
 
Posts: 448
Joined: Mon Feb 02, 2009 7:18 pm
Location: Slovenia

Re: CustomMultiBodyVehicle Joint

Postby JernejL » Tue Jan 26, 2010 5:18 am

Stucuk wrote:Mathematically correct is different from going against maths. Maths states what a 2D world is, Y is Height. A 3D world is just a 2D world with depth, which means logicaly Z is depth and not A,B,C,D,E,F,G,H,I,J,K,L,M,N,O,P,Q,R,S,T,U,V,W,X or Y. Which is one reason you hear people calling depth buffers "z-buffers" and not "y-buffers".


Z-buffer is called depth since it extends from your camera origin and will always be depth regardless in which direction you look at, it reprisents depth of a 2-D image, which can be aligned along ANY axis, and it will be depth along that axis.

I suggest you read a bit on this subject:

http://en.wikipedia.org/wiki/Cartesian_plane

In mathematical illustrations of two-dimensional Cartesian systems, the first coordinate (traditionally called the abscissa) is measured along a horizontal axis, oriented from left to right. The second coordinate (the ordinate) is then measured along a vertical axis, usually oriented from bottom to top.


For three-dimensional systems, mathematicians usually draw the z axis as vertical and pointing up, so that the x and y axes lie on an horizontal plane. There is no prevalent convention for the directions of these two axes, but the orientations are usually chosen according to the right-hand rule. In three dimensions, the names "abscissa" and "ordinate" are rarely used for x and y, respectively. When they are, the z-coordinate is sometimes called the applicate.


http://en.wikipedia.org/wiki/Cartesian_ ... dimensions

Once the x- and y-axes are specified, they determine the line along which the z-axis should lie, but there are two possible directions on this line. The two possible coordinate systems which result are called 'right-handed' and 'left-handed'. The standard orientation, where the xy-plane is horizontal and the z-axis points up (and the x- and the y-axis form a positively oriented two-dimensional coordinate system in the xy-plane if observed from above the xy-plane) is called right-handed or positive.


So, if i choose the mathematically correct: XY ground (horisontal) and Z height and not Y for height it does not go "against maths" at all.

You can join that with this: http://en.wikipedia.org/wiki/Flight_dynamics

And you'll see how body dimensions are usually aligned along the axes:

* Pitch rotation about Y Body Axis
* Roll rotation about X Body Axis
* Yaw rotation about Z Body axis


All math based papers will match the Z = height notation, only game math specific related formulas have it different.
Help improving the Newton Game Dynamics WIKI
User avatar
JernejL
 
Posts: 1587
Joined: Mon Dec 06, 2004 2:00 pm
Location: Slovenia

Re: CustomMultiBodyVehicle Joint

Postby Stucuk » Wed Jan 27, 2010 11:32 am

Z-buffer is called depth since it extends from your camera origin and will always be depth regardless in which direction you look at, it reprisents depth of a 2-D image, which can be aligned along ANY axis, and it will be depth along that axis.


My point wasn't that it always goes along one axis, but how its named. Depth buffers are never called X or Y buffers. There a perfect example of 2D extending into 3D and being named correctly.


When i said going against maths i mean that it doesn't follow suit. Re-inventing the wheel just for a single dimension is stupid. If 2D states that X is Width and Y is Height then a 3D world should inherit everything thats inside a 2D world and have the new dimension (Depth) with a different letter from what 2D worlds use.

Note: Im not disputing the fact that people have come up with systems that use different letters. Just that they are stupid for not inheriting everything from the previous dimensions.
User avatar
Stucuk
 
Posts: 801
Joined: Sat Mar 12, 2005 3:54 pm
Location: Scotland

Re: CustomMultiBodyVehicle Joint

Postby Julio Jerez » Wed Jan 27, 2010 12:44 pm

well teh cordenade systmm proble is fix now with the nex Beta 17.
if anyone wnat to use Y up, is fine, if soem oen wa to use Y up is also fine.
I personally lie teh coodenate system Y up and X front.

The New file serializer have functions to rotate and scale scene or models any whay the end user to make the system it want to use. I can even make X up if they want.
Regarless of how is is stored in the database. I can even make X up if they want.

The default is Y up and Z back, so I myself have to apply a 90 degree rotation.
Engines how use system teh same system as XSI, MAX or Maya can use as it.
I can also convert from left to right handed, for exampel engien who use cordenate system liek Max, but floi Z to be teh front, I can also delat with that.
I it taken me a long time to get the all ready bu I am almost truoght, an dI will also provide some Plug ins.

The only cacth is that teh enfio libary have to use teh NewtonToll Library, whis is simulat to eth Joint Library.
at the moment is only have CPP inteface but isn nex realises I will add a C interface.
Julio Jerez
Moderator
Moderator
 
Posts: 12426
Joined: Sun Sep 14, 2003 2:18 pm
Location: Los Angeles

Re: CustomMultiBodyVehicle Joint

Postby PJani » Mon Feb 01, 2010 9:23 am

Hy. I found glitch in CollisionTree and CustomMultiBodyVehicle Joint. When i go over low edge like you can see on yt video, vehicle contact explodes.

| i7-5930k@4.2Ghz, EVGA 980Ti FTW, 32GB RAM@3000 |
| Dell XPS 13 9370, i7-8550U, 16GB RAM |
| Ogre 1.7.4 | VC++ 9 | custom OgreNewt, Newton 300 |
| C/C++, C# |
User avatar
PJani
 
Posts: 448
Joined: Mon Feb 02, 2009 7:18 pm
Location: Slovenia

Re: CustomMultiBodyVehicle Joint

Postby Julio Jerez » Mon Feb 01, 2010 12:43 pm

wow that seems really bad.
those are the bugs I look for, can you reproduce it?
and also can I have demo to see what I can do about?
Julio Jerez
Moderator
Moderator
 
Posts: 12426
Joined: Sun Sep 14, 2003 2:18 pm
Location: Los Angeles

Re: CustomMultiBodyVehicle Joint

Postby PJani » Mon Feb 01, 2010 5:31 pm

Julio Jerez wrote:wow that seems really bad.
those are the bugs I look for, can you reproduce it?
and also can I have demo to see what I can do about?


Yep its reproducable...every time i drive over that edge(NOTICE! 10cm rised edge) more or less vehicle explodes, but not so violently as it was in the video, i was surprised when i was recording(i think fps is the main cause for the size of explosion, because fraps limits fps to 30FPS my default fps is 60FPS), usually these explosions are smaller. :shock:

I was playing with friction, elasticy and softness parameters for this problem but is the same all the time.

I will try to make small demo...i need to write another program because this project is very big 500Megs with all other libraries in the background, but i think i will reproduce it, because same thing was happeing in old 1.3x.
| i7-5930k@4.2Ghz, EVGA 980Ti FTW, 32GB RAM@3000 |
| Dell XPS 13 9370, i7-8550U, 16GB RAM |
| Ogre 1.7.4 | VC++ 9 | custom OgreNewt, Newton 300 |
| C/C++, C# |
User avatar
PJani
 
Posts: 448
Joined: Mon Feb 02, 2009 7:18 pm
Location: Slovenia

Re: CustomMultiBodyVehicle Joint

Postby Dave Gravel » Mon Feb 01, 2010 7:38 pm

This is a very old bug.
It have begin around the version 2.04.
It's possible to reduce it by changing implementation about projection tire parts but the problem don't go totally.

Edited:
Other problem related to this bug, more your tires have torque more it is present.
If you use the continuous collision on tires the effect is 5x to 10x times higher.
You search a nice physics solution, if you can read this message you're at the good place :wink:
OrionX3D Projects & Demos:
https://orionx3d.sytes.net
https://www.facebook.com/dave.gravel1
https://www.youtube.com/user/EvadLevarg/videos
User avatar
Dave Gravel
 
Posts: 801
Joined: Sat Apr 01, 2006 9:31 pm
Location: Quebec in Canada.

PreviousNext

Return to General Discussion

Who is online

Users browsing this forum: No registered users and 0 guests

cron