Elite Member

Posts: 124
From:
Registered: Jul 2003

As a work around I suppose I could write the code to move the whole world around the camera at the 0,0,0 position, so you don't see any of this shaking where ever you go, but this doesn't seem very elegant to me.

Here's a quick example showing the problem. The problem is even worse in the game I'm writing, as the players camera is very close to the model and it is very obvious something has gone wrong!

Graphics3D 640, 480, 32, 2 centre = CreatePivot() Global camera = CreateCamera(centre) cam_z# = -5 CameraZoom camera, 1.5 Global light = CreateLight() testentity = CreateSphere(16,centre) childentity = CreateCube(testentity) PositionEntity childentity, 1, 0, 0 childentity = CreateCube(testentity) PositionEntity childentity, 0, -1.5, 0 Repeat TurnEntity testentity, 0, 0.05, 0 If KeyDown(57) Then ;Space to teleport PositionEntity centre, 200000, 200000, 0 Else PositionEntity centre, 0, 0, 0 EndIf If MouseHit(1) Then ;Reset MouseXSpeed MouseXSpeed() MouseYSpeed() EndIf If MouseDown(1) Then ;Holding down left mouse moves camera cam_yr=cam_yr-MouseXSpeed() cam_xr=cam_xr+MouseYSpeed() EndIf cam_z=cam_z+MouseZSpeed()*2 If cam_z>-2 cam_z=-2 If cam_z<-300 cam_z=-300 PositionEntity camera, 0, 0, 0 RotateEntity camera,cam_xr,cam_yr,cam_zr MoveEntity camera,0,0,cam_z UpdateWorld() RenderWorld() Text 5,5, "X:"+EntityX(centre)+" Y:"+EntityY(centre)+" Z:"+EntityZ(centre) Text 5,30, "Hold space to teleport" Flip() Until KeyHit(1) End

[This message has been edited by nukomod (edited 06-14-2004).]

[This message has been edited by nukomod (edited 06-29-2004).]

               

1,000 Post Club!


*BlitzCoder VIP*

Posts: 3894
From: UK
Registered: Mar 2002

------------------
Tennis has never been more fun :

               

Elite Member

Posts: 124
From:
Registered: Jul 2003

I am using Tokamak for the positions of objects and I don't believe it suffers as Blitz does (higher precision floats probably) so as long as a render everything local to the camera Tokamak shouldn't care.

I don't suppose Mark would every consider increasing the accuracy of the float internally? I wouldn't want another data type, just more internal precision!

               

Moderator

Stickman Contest Winner
1st Place!

Contributing Author

Posts: 2426
From: NJ, USA
Registered: Jul 2002
ICQ: 44373244

------------------
Error reading brain: (A)bort, (R)etry, (I)gnore, (F)ail?

               

Elite Member

Posts: 124
From:
Registered: Jul 2003

500 Post Club!

Posts: 763
From:
Registered: Jul 2003

quote:

---

Intel processor floating-point unit (FPU) operates only with double values. To make operation with float it converts it first to double. So, c*d is faster.
Float operations may be faster than double only when SSE texhnology is used.

---

------------------

0100101001100001011011010110010101110011
010011100110010101110111011011010110000101101110

[This message has been edited by Scienthsine (edited 06-14-2004).]

            

500 Post Club!

Posts: 763
From:
Registered: Jul 2003

quote:

---

Direct3D and the FPU..
I had an email this morning about Managed Direct3D 'breaking' the math functions in the CLR. The person who wrote discovered that this method:

public void AssertMath()
{
double dMin = 0.54797677334988781;
double dMax = 4.61816551621179;
double dScale = 1/(dMax - dMin);
double dNewMax = 1/dScale + dMin;
System.Diagnostics.Debug.Assert(
dMax == dNewMax);
}

Behaved differently depending on whether or not a Direct3D device had been created. It worked before the device was created, and failed afterwords. Naturally, he assumed this was a bug, and was concerned. Since i've had to answer questions similar to this multiple times now, well that pretty much assures it needs it's own blog entry.

The short of it is this is caused by the floating point unit (FPU). When a Direct3D device is created, the runtime will change the FPU to suit its needs (by default switch to single precision, the default for the CLR is double precision). This is done because it has better performance than double precision (naturally).

Now, the code above works before the device is created because the CLR is running in double precision. Then you create a Direct3D device, the FPU is switched to single precision, and there are no longer enough digits of precision to accurately calculate the above code. Thus the 'failure'.

Luckily, you can avoid all of this by simply telling Direct3D not to mess with the FPU at all. When creating the device you should use the CreateFlags.FpuPreserve flag to keep the CLR's double precision, and have your code functioning as you expect it.

---

Taken from some website with a "Managed DirectX" lib I think.
|EDIT|
Also found something saying that DarkBasic has floats and doubles... not sure though.
|EDIT|
------------------

0100101001100001011011010110010101110011
010011100110010101110111011011010110000101101110

[This message has been edited by Scienthsine (edited 06-14-2004).]

            

Elite Member

Posts: 124
From:
Registered: Jul 2003

Thanks for the info, it's quite interesting. At least I won't have a grudge with Blitz basic over it. I've just finished the system that keeps the camera at the origin and its eliminated the problem. Now Tokamak precision is the limitation and so far I haven't run in to it. The useable area seems to be way bigger than I'll ever need so I'm very happy now

[This message has been edited by nukomod (edited 06-18-2004).]

               

1,000 Post Club!

Posts: 1818
From: Louisville Kentucky
Registered: Aug 2003

------------------

               

Elite Member

Posts: 124
From:
Registered: Jul 2003

At first I set up the world so the camera remained at 0,0,0 (global) and everything moved around it, but it had the same problem. I figured this was because everything was parented to a single entity, and there distance from this entity was causing the same problem.

So I came up with another idea. I parented everything to the camera, but positioned everything still with global positions from Tokamak. So everything was still in its correct place, but relative positions were all from the camera. Anything far away enough to become unstable is out of view range so it doesn't matter. The problem remains though. The camera can still go too far and reach the 'unstable' distance, but because everything is relative to the camera I didn't think this would matter.

Does anyone have any practical experience with this problem?

               

Elite Member

Posts: 124
From:
Registered: Jul 2003

explanation

               

Elite Member

Posts: 124
From:
Registered: Jul 2003

If anyone's interested in how this is done I can post a full explanation... but for now precious sleep.

               

1,000 Post Club!

Posts: 1063
From: bradford- uk
Registered: Mar 2003

------------------
I'm with STUPID ^^^^

               

Elite Member

Posts: 124
From:
Registered: Jul 2003

As a note it probably wasn't very clear but on the explanation there are arrows at the top to move between the different pages. (there's 6)

               

Veteran Member

Posts: 493
From:
Registered: Aug 2001

If you had searched the board, you would have found many threads on this subject...

http://www.blitzcoder.com/cgi-bin/ubb-cgi/postdisplay.cgi?forum=Forum4&topic=000352

With code and everything... Just read the whole thread and remember to disable/enable collisions.

EDIT: Maybe this should be in a FAQ of some sort... It would help newbies if they didn't have to reinvent the wheel all of the time...

Andy

[This message has been edited by Andy (edited 06-29-2004).]

            

Elite Member

Posts: 124
From:
Registered: Jul 2003

What I'm trying to do now is basically use the Tokamak double precision floats to position everything, but keep a blitz pivot to offset the world so the camera is at 0,0,0. None of the blitz entities positioned with tokamak will be parented to the pivot however, it'll just be used for reference. This way the objects that are too far from the origin will become unstable, but won't be visible. As the player approaches them their positions will become more accurate as the original Tokamak positions are always used as the source.

I think the problem may be magnified in my game as many of the objects affected have slightly more complex hierarchies than usual.

If you have any other ideas and suggestions their definatley welcome.

               

Veteran Member

Posts: 493
From:
Registered: Aug 2001

Weird... It works for me and many others.

>I pivoted the whole world and moved it so the
>camera remained at 0,0,0 but the problem continued. I'm guessing this is
>because the pivot got so far away that the local positions to the pivot
>of the entities were causing inaccuracies.

So basically you didn't use the method described at all.

>What I'm trying to do now is basically use the Tokamak double precision
>floats to position everything, but keep a blitz pivot to offset the world
>so the camera is at 0,0,0.

So you convert from double precision floats to single precision floats and expect them to be more accurate than usual? Then you add a pivot, decreasing accuracy even further!

>None of the blitz entities positioned with tokamak will be parented to
>the pivot however, it'll just be used for reference. This way the objects
>that are too far from the origin will become unstable, but won't be
>visible. As the player approaches them their positions will become more
>accurate as the original Tokamak positions are always used as the source.

It doesn't matter what you use as a source... You try to achieve double precision accuracy with single precision numbers... It can't be done, except if you have access to B3D's internals... AFAIU, B3D uses double precission floats internally. Are you using a dll or userlib to mess around with the programs in memory?

I have to admit that I am confused! It sounds like you are trying to do the same thing as is described in the post, but instead of doing it the simple way we all know works, you have decided to reinvent it in a complex way that won't easily work...

Andy

            

Elite Member

Posts: 124
From:
Registered: Jul 2003

I'm going to have another crack at it today.. wish me luck.

------------------
NovaStorm Scrolling Shoot 'Em up SDK|Magic Mokey Spaceship|AI Germs|Voxel Demo 3

               

Veteran Member

Posts: 493
From:
Registered: Aug 2001

What is the connection between tokamak(a physics library I believe?) and the 3D world coordinates? Surely the physics work in local space?

Is there a special reason why you use double precision floats and then convert to single precision?

I am not being critical, but I am just not sure I understand how the work around for FP precision is related to the physics library in your program!?

Moving the world around the camera is very processor intensive and will easily introduce problems with precision and movement of entities, which is why the simpler approach of moving entities and just resetting the camera to 0,0,0 every once in a while is better suited to B3D... Unless of course you wish to do in code what B3D already does for you.

Anyway, I wish you luck and hope you get it working!

Andy

            

500 Post Club!

Posts: 763
From:
Registered: Jul 2003

|EDIT|
The way I would do it, is to divide the entire world into sections. Then the world consists of a 2d dimensional array of sections of land (or whatever) each so big. The character has an area that is always positioned around him. This area moves with him. (Probley best to have it move after he has gotten so close to one of it's sides or something.) Ohh and the player has a section position, as well as a position in that section like everything else. Then, with a very small bit of math, and logic, when you move the "Active" area around the player, place everything that should be somewhere in their respective places.

Hmmm I'm not sure how to describe it better than that... Basically though your infact just increasing how many bytes are used to store your position. Ohhh and you can load everything into ram, streaming from disk isn't required.
|EDIT|
------------------

0100101001100001011011010110010101110011
010011100110010101110111011011010110000101101110

[This message has been edited by Scienthsine (edited 06-30-2004).]