Sorry your browser is not supported!

You are using an outdated browser that does not support modern web technologies, in order to use this site please update to a new browser.

Browsers supported include Chrome, FireFox, Safari, Opera, Internet Explorer 10+ or Microsoft Edge.

AppGameKit Classic Chat / 3d physics a bit odd?

Author
Message
shadey
14
Years of Service
User Offline
Joined: 25th Jan 2010
Location:
Posted: 23rd Apr 2016 10:44
I am rewriting my 3D level editor, putting the physics in straight away, improved a few things which was nice, but should they be as trigger happy? in the video below I built a few structures, the tallest one with the wooden beam has no chance of staying up, the middle one with like the vent beam kinda stays up but on one run I dunno how it gets away with it! Which brings me to another thing noted, each run switches between to possible outcomes, if you keep an eye on the final resting places you will see! I noted this effect also in the box2d physics using sprites.

Hail to the king, baby!
BatVink
Moderator
21
Years of Service
User Offline
Joined: 4th Apr 2003
Location: Gods own County, UK
Posted: 23rd Apr 2016 10:58
It looks like they are not perfectly touching. The tower "slumps" into place, then falls over.
The other explanation may be that they are overlapping. even if it is by a tiny fraction, the blocks will jump to find their own physical space.

But I agree, I have seen this problem for many years with physics in 2D and 3D.
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Quidquid latine dictum sit, altum sonatur
TutCity is being rebuilt
BatVink
Moderator
21
Years of Service
User Offline
Joined: 4th Apr 2003
Location: Gods own County, UK
Posted: 23rd Apr 2016 11:23
I ran a test, and got the same results. It didn't fall but it was unsteady.
I don't know if you can do this, but I added a fixed joint between each block and it was much more stable.

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Quidquid latine dictum sit, altum sonatur
TutCity is being rebuilt
shadey
14
Years of Service
User Offline
Joined: 25th Jan 2010
Location:
Posted: 23rd Apr 2016 15:51
Still recoding the editor, need to get in the basics, almost done! I will add more boxes to change the mass,friction,restitution, damping and whatnot,perhaps changing a combination of these values will make some balance! I will run a few tests with various values.
Hail to the king, baby!
Stab in the Dark software
Valued Member
21
Years of Service
User Offline
Joined: 12th Dec 2002
Playing: Badges, I don't need no stinkin badges
Posted: 23rd Apr 2016 20:07
BatVink
Try this, I removed the fixed joint and called SetObject3DPhysicsDamping() instead.



The coffee is lovely dark and deep,and I have code to write before I sleep.
shadey
14
Years of Service
User Offline
Joined: 25th Jan 2010
Location:
Posted: 24th Apr 2016 16:28 Edited at: 24th Apr 2016 17:50
Yeh that has some effect,though stacking around 9 * 2 columns with a crossbar on top eventually gave way. Aso it slows the whole thing down somewhat, make it too high like a 3 and some objects never actually get to fall out of view and instead are suspended in mid-air!

Simply putting Set3DPhysicsGravity(0,-0.27,0) near the top of the code suffices for me, I had set it at -3 but seemed a bit much.

Hail to the king, baby!
Stab in the Dark software
Valued Member
21
Years of Service
User Offline
Joined: 12th Dec 2002
Playing: Badges, I don't need no stinkin badges
Posted: 25th Apr 2016 01:10
The gravity by default is set to -10.0 on the y axis. What you have set it to is micro gravity( weightlessness ).
Objects will not fall at a realistic rate at that gravity. You can use the fixed joint to hold it together but break it when enough force is applied.
What scale are you using? There is a minimum object size for Bullet Physics depending on the scale factor.
The solver becomes unstable below the minimum object size which may account for your issues.

This video was for DBPro but it shows the fixed joint in action. Note: the fracturing of objects in the video is not available in AGK.


The coffee is lovely dark and deep,and I have code to write before I sleep.
shadey
14
Years of Service
User Offline
Joined: 25th Jan 2010
Location:
Posted: 25th Apr 2016 13:24 Edited at: 25th Apr 2016 14:06
I dunno, I think this physics could do with a lot more explanations!!
And examples, like a simple one of using the character controller and joystick to move about a box and make it jump, tried it before but again ran into issues without knowing why!

the size of the boxes are set to 1x1x1
which I change for the crossbar of course. but the stacked boxes are simply 1x1x1.

Dunno how i would implement the joints within my editor but it would be depressing to have to do so!
I actually used darkphysics in darkbasic with zero problems, and got the character controller working easily using it, yet I seem to be struggling to get to grips with it under AGK.
Hail to the king, baby!
Mobiius
Valued Member
21
Years of Service
User Offline
Joined: 27th Feb 2003
Location: The Cold North
Posted: 25th Apr 2016 14:30
Quote: "I think this physics could do with a lot more explanations!!"

TGC didn't pay Stabs for the examples.
Stab in the Dark software
Valued Member
21
Years of Service
User Offline
Joined: 12th Dec 2002
Playing: Badges, I don't need no stinkin badges
Posted: 25th Apr 2016 15:14
Quote: "the size of the boxes are set to 1x1x1
which I change for the crossbar of course. but the stacked boxes are simply 1x1x1."


At the default scale factor the boxes are too small. The minimum size for an object at the default scale factor is about 3.5 AppGameKit units.
Read the help for the Create3DPhysicsWorld() command to understand the scale factor.

Quote: "Dunno how i would implement the joints within my editor but it would be depressing to have to do so!"


It is easy just use the GetObjects3DPhysicsContactPositionVector() command to get the contact vector between the boxes and
call Create3DPhysicsFixedJoint() to create the fixed joint. Not depressing at all.
The joints demo shows it in action.

Quote: "I actually used darkphysics in darkbasic with zero problems, and got the character controller working easily using it, yet I seem to be struggling to get to grips with it under AGK."


AGK does not use Dark Physics, it is powered by the Bullet Physics engine. Bullet is easier to use.





The coffee is lovely dark and deep,and I have code to write before I sleep.
shadey
14
Years of Service
User Offline
Joined: 25th Jan 2010
Location:
Posted: 25th Apr 2016 15:37
3.5! That is pretty big, and impractical! or at least it limits to what I can do.
Hail to the king, baby!
Stab in the Dark software
Valued Member
21
Years of Service
User Offline
Joined: 12th Dec 2002
Playing: Badges, I don't need no stinkin badges
Posted: 25th Apr 2016 15:47 Edited at: 25th Apr 2016 15:55
Quote: "3.5! That is pretty big, and impractical! or at least it limits to what I can do."


It is not impractical you can change the scale factor. Please read the help for the commands.

You must create the Physics world before calling any other physics commands. Create3DPhysicsWorld Creates the physics world using the default scale factor of 40. This function will create the physics world with a different scale factor. The scale is not the size of the world, it is the factor by which all the data passed in is scaled down by to convert it to the Bullet Physics scale for the physics calculations. Then the data from Bullet is scaled up before it is passed to the AppGameKit 3D world. The default scale factor will be correct if your average character size is 72 AppGameKit units tall. Then the default gravity of -10.0 meters per second on the Y axis will give the correct visual result. The Bullet Physics solver has a minimum size for objects. Objects below this size will cause instability with the solver. At the default scale factor of 40 the smallest dimension that the solver can handle is about 3.5 AppGameKit units. To calculate the scale factor first determine your character's height in meters, a character of 72 units tall would be 1.8288 meters (or 6ft). Then divide the character's height in units by the characters height in meters, for this example the scale factor would be (72 / 1.8) = 40.

P.S. If you notice in BatVink's example code he used a scale factor of 1 which allowed him to use small size cubes.
You can also read this.
http://bulletphysics.org/mediawiki-1.5.8/index.php/Scaling_The_World

The coffee is lovely dark and deep,and I have code to write before I sleep.
shadey
14
Years of Service
User Offline
Joined: 25th Jan 2010
Location:
Posted: 25th Apr 2016 16:11 Edited at: 25th Apr 2016 17:55
well... I tried the default gravity of -10 and the boxes as 4x4x4, they still fall over immediately.
**edit**
Ah wait, I just noted that he sets up with Create3DPhysicsWorld(1) , I just had brackets without the 1, So I guess that was some default value that was too high as they seem to stay standing now... Even as 1x1x1 which Batvink also did .
This actually makes it harder for me to grasp... and looking at the examples here : https://forum.thegamecreators.com/thread/216683 you have the default and nothing in the brackets!

This is actually making me feel frustrated. But what must I do then if i simply want to stack boxes of 1x1x1, are you saying make them bigger then use setobjectscale ?? here is another thing when you say scale, as there is more than one scale!! The physics scale and the said object scale, I really am clueless and wish I could move on swiftly.. what you say and what i see don't tally up in my brain, god knows how i would deal with externally loaded objects also.
I wish it was as simple as darkphysics was.
I just want to place objects within my editor and have them have the correct physics.. really simple.. err.. meant to be!
Hail to the king, baby!
Stab in the Dark software
Valued Member
21
Years of Service
User Offline
Joined: 12th Dec 2002
Playing: Badges, I don't need no stinkin badges
Posted: 26th Apr 2016 03:04
First I take a DEEP breath.

The 3D physics scale factor is a value that AppGameKit uses to scale all the values that are passed to the Bullet physics engine in order to keep
the numerical values within the Bullet physics engine's solvers limits. For Bullet moving objects are assumed to be in the range of 0.05 units,
about the size of a pebble, to 10, the size of a truck. For example if a truck model in your game is 144 units high, when you call Create3DPhysicsDynamicBody()
for the truck AppGameKit takes the dimensions of the truck and divides it by the scale factor then passes that data to the Bullet Physics engine for the physics calculations.
Then the data coming back from the physics solver are multiplied by the scale factor before using the data to position the object. This allows objects to fall at the correct rate
when gravity is set to -10.0 meters per second on the Y axis which is the default rate.

Really you do not have to be concerned with what happens behind the scenes. Just use the equation in the post above to figure out the scale factor for your game world
and pass in that value when you call Create3DPhysicsWorld(). This scale factor has nothing to do with any other commands concerning scaling.

When Batvink called Create3DPhysicsWorld(1) he was changing from the default scale of 40 to no scaling because dividing or multiplying by 1 is the same value.
Then the cubes of size 1,1,1 fall between the Bullet solver values of 0.05 and 10.





The coffee is lovely dark and deep,and I have code to write before I sleep.
shadey
14
Years of Service
User Offline
Joined: 25th Jan 2010
Location:
Posted: 26th Apr 2016 11:17 Edited at: 26th Apr 2016 13:28
I got that bit, but I dont get what happens if I chose to have boxes of varying sizes, from 1x1x1 to 50,50,50 or whatever... what are you expected then to pass in as a value to create3Dphysicsworld()?! Originally I had no parameters and everything was left as a default but of course the boxes simply fell straight over, as I showed in the first video.
Hail to the king, baby!
Mobiius
Valued Member
21
Years of Service
User Offline
Joined: 27th Feb 2003
Location: The Cold North
Posted: 27th Apr 2016 10:38 Edited at: 27th Apr 2016 10:41
Quote: "what happens if I chose to have boxes of varying sizes, from 1x1x1 to 50,50,50 or whatever"

How big are the boxes compared to a person?

If your 1x1x1 box is 10cm, then your 50x50x50 box must be 5m. They'll all use the same scale values in the calculation.

Instead of Create3DPhysicsWorld( 40 ) , try Create3DPhysicsWorld( 11.425 ) .......
BatVink
Moderator
21
Years of Service
User Offline
Joined: 4th Apr 2003
Location: Gods own County, UK
Posted: 27th Apr 2016 11:06 Edited at: 27th Apr 2016 11:07
To cut through all the technical details, just use the following calculation:

scale = AppGameKit units per metre

If a 1 unit box is 5 metres high in your virtual world, the scale is 0.2. (1 / 5)
If a 10 unit box is 1 metre high in your virtual world the scale is 10 (10 / 1)
If a 100 unit box is 2 metres high in your virtual world the scale is 50 (100 / 2)

Also bear in mind that bullet physics is not designed to get a mouse to interact with an elephant. The scale difference is too vast.
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Quidquid latine dictum sit, altum sonatur
TutCity is being rebuilt
shadey
14
Years of Service
User Offline
Joined: 25th Jan 2010
Location:
Posted: 27th Apr 2016 12:34
i dont get it.. really aint clear, cm? I simply use createobjectbox(1,1,1).. I have no idea what real height this gives me?

Seems to make no difference if I simply use:
Create3DPhysicsWorld(1)
Set3DPhysicsGravity(0,-10,0)


I did another video showing this within the editor I am developing Using the function to throw the ball from the manipulating 3d physics example :


Hail to the king, baby!
Mobiius
Valued Member
21
Years of Service
User Offline
Joined: 27th Feb 2003
Location: The Cold North
Posted: 27th Apr 2016 12:53
I dislike repeating myself but..
Quote: "try Create3DPhysicsWorld( 11.425 )"
shadey
14
Years of Service
User Offline
Joined: 25th Jan 2010
Location:
Posted: 27th Apr 2016 13:43 Edited at: 27th Apr 2016 14:04
I have done, they fall straight away with the stack in the last video! I will stick to the value of 1 until things look odd, but with 1 they at least remain standing with zero shift! If I change the value to anything greater than 1 in fact it fails to remain steady. Am I the only one not getting these values!! Who else is bothering with the 3d physics?

** edit **
Actually on some runs they fail to fall even when hit! I give up for now...
Hail to the king, baby!
Stab in the Dark software
Valued Member
21
Years of Service
User Offline
Joined: 12th Dec 2002
Playing: Badges, I don't need no stinkin badges
Posted: 27th Apr 2016 14:08
As I explained above, set the damping higher so they settle after positioning.
You complained it slows things down, so what you need to do is first get the default
damping values, store them, then set the cubes to damping 2.0, then set them back to default after
the stack is stable. Otherwise use a fixed joint in between to hold them stable.
The coffee is lovely dark and deep,and I have code to write before I sleep.

Login to post a reply

Server time is: 2024-11-25 07:46:59
Your offset time is: 2024-11-25 07:46:59