Jump to content
karri

3D math using Suzy

Recommended Posts

Obviously using $4000 is a great choice for unit vectors 1.0.

 

Another thing is that there is some "magic rotations that will not cause cumulative errors.

16-bits   0x4000 = 16384
Magic Angles        Angular Error Limit = 0.005000 %

  COS     SIN    ISINE  ANGLE(deg)  %Error(deg/deg)  %Magnitude Error
 16382   255.992   256   0.89525642   0.0030521   -0.0000007
 16380   362.017   362   1.26609665   0.0045790   +0.0000022
 16375   542.983   543   1.89919328   0.0030537   -0.0000034
 16354   991.030   991   3.46780721   0.0030074   +0.0000110
 16350  1054.967  1055   3.69183785   0.0031041   -0.0000129
 16334  1279.023  1279   4.47737570   0.0018070   +0.0000110
 16322  1423.999  1424   4.98609928   0.0000989   -0.0000007
 16319  1457.976  1458   5.10538374   0.0016273   -0.0000129
 16305  1606.994  1607   5.62880539   0.0003496   -0.0000034
 16301  1647.075  1647   5.76966484   0.0045495   +0.0000458

Is there any other considerations to think about when doing 3D math with Suzy?

 

 

 

Share this post


Link to post
Share on other sites

I think: Avoid Suzy as much as possible. AFAIK one can use delta approach also for rotation but you have to  correct the error from time to time.

 

  • Thanks 1

Share this post


Link to post
Share on other sites
On ‎12‎/‎9‎/‎2019 at 1:40 PM, karri said:

Obviously using $4000 is a great choice for unit vectors 1.0.

 

Another thing is that there is some "magic rotations that will not cause cumulative errors.

16-bits   0x4000 = 16384
Magic Angles        Angular Error Limit = 0.005000 %

  COS     SIN    ISINE  ANGLE(deg)  %Error(deg/deg)  %Magnitude Error
 16382   255.992   256   0.89525642   0.0030521   -0.0000007
 16380   362.017   362   1.26609665   0.0045790   +0.0000022
 16375   542.983   543   1.89919328   0.0030537   -0.0000034
 16354   991.030   991   3.46780721   0.0030074   +0.0000110
 16350  1054.967  1055   3.69183785   0.0031041   -0.0000129
 16334  1279.023  1279   4.47737570   0.0018070   +0.0000110
 16322  1423.999  1424   4.98609928   0.0000989   -0.0000007
 16319  1457.976  1458   5.10538374   0.0016273   -0.0000129
 16305  1606.994  1607   5.62880539   0.0003496   -0.0000034
 16301  1647.075  1647   5.76966484   0.0045495   +0.0000458

Is there any other considerations to think about when doing 3D math with Suzy?

 

 

 

Please, just resist and say no to this approach. I know that you have a great debugging set-up with real Lynx, but still - this approach will drive you nuts trying to reproduce a very occasional bug. That time is better spent putting more features in or watching Northern Lights or dipping in the lake :)

 

Just got for LookUp Tables or compute the thing each frame brute-force.

 

And if you can't resist, at least spend half day in Excel and create these huge 10,000 line long tables that will somewhat "emulate" the loss of precision. At least this way you'll know exactly how soon you can expect the error to become significant in your particular scenario.

Share this post


Link to post
Share on other sites
51 minutes ago, VladR said:

Please, just resist and say no to this approach. I know that you have a great debugging set-up with real Lynx, but still - this approach will drive you nuts trying to reproduce a very occasional bug. That time is better spent putting more features in or watching Northern Lights or dipping in the lake :)

 

Just got for LookUp Tables or compute the thing each frame brute-force.

 

And if you can't resist, at least spend half day in Excel and create these huge 10,000 line long tables that will somewhat "emulate" the loss of precision. At least this way you'll know exactly how soon you can expect the error to become significant in your particular scenario.

 

Thanks Vlad, watching Northern Lights and dipping in the lake does not rule out doing silly things with the Lynx.

 

I don't really need to do transformations for actual angles. Most likely I could limit my rolls to a few deltas/frame. Perhaps minor turn, normal turn, steep turn. So the needed angles could be 0.89525642, 1.89919328, 4.98609928. If I could then get rid of code trying to check for orthogonal matrix after the transformation I would save a lot of time. The same "magic deltas" would be used in all three axis.

 

Because I am probably more interested in a game than a simulation I want the crafts to be upright. So there would be "gravity" pointing down all the time. The distances would also be linear, meaning that the craft becomes bigger at a constant rate instead of being a dot for ages and suddenly zoomed up for fly-by.

 

But @42bs has a point. In the long run it may be better to leave Suzy free to do graphics and use the CPU for math. Especially if I manage to squeeze out all tricks from @enthusi about how to code for the Lynx <:evil grin:>

Share this post


Link to post
Share on other sites

I did the Delta thing once on PC when I had my 6-DOF underwater simulator game demo about 15 yrs ago. Even using doubles, very quickly the precision deteriorates.

 

Problem is, it's non-linear and really dependent on how frantic the action is. You can fly forward for 30 seconds and it's all fine, but when action becomes frantic and you need to do dozen maneuvers within half second avoiding shots from 3 ships, which is exactly where you need it most, it barfs on you.

I've lost more time debugging and creating workarounds than it was worth the performance it saved.

 

People don't mind 5% lower framerate as much as they mind occasional glitch - like once in 10 seconds. The cost of the workarounds for those glitches will be certainly substantial on 6502.

 

Of course, I'm not saying it's impossible to design a useable system for 6502. It's just not worth the effort in my opinion. You can have giant LUT tables and require the game to use 1 MB, so I really see no point.

 

Then again, if you have the itch and simply must do it, it's different - you do it for fun :)

 

 

Share this post


Link to post
Share on other sites

I believe the point of "magic angles" is that a turn left followed by a turn right would bring back the original matrix. So for these special angles the cumulative error is small enough to be ignored. This could be true for the lifetime of an object on screen. If I can keep the object there for tens of seconds it should work. The UI would be limited to allow only these special rotations and tilts that don't allow errors to accumulate.

Share this post


Link to post
Share on other sites

Well, I was doing full-blown 6-DOF simulator, with complete freedom of movement, so it's quite possible that if you restrict rotation to only certain axis, the total precision will get bumped up as you're not accumulating errors from multiple axis.

 

Are you using fixed point ? How many bits ?

  • Like 1

Share this post


Link to post
Share on other sites
41 minutes ago, VladR said:

Well, I was doing full-blown 6-DOF simulator, with complete freedom of movement, so it's quite possible that if you restrict rotation to only certain axis, the total precision will get bumped up as you're not accumulating errors from multiple axis.

 

Are you using fixed point ? How many bits ?

Just 16 bit 2's complement integer math. Resolution is only 14 bits. 0x4000 = 1.0.

We want to have 1.0 * 1.0 = 1.0

In hex the multipy A*A becomes ((A*A) << 2) >> 16.

0x4000 * 0x4000 = 0x1000 0000

0x1000 0000 << 2 = 0x4000 0000

By just using the high 16 bits we have 0x4000 which happens to represent 1.0

 

The "magic angles" are calculated in this same numbering system.

Share this post


Link to post
Share on other sites
1 hour ago, karri said:

Just 16 bit 2's complement integer math. Resolution is only 14 bits. 0x4000 = 1.0.

We want to have 1.0 * 1.0 = 1.0

In hex the multipy A*A becomes ((A*A) << 2) >> 16.

0x4000 * 0x4000 = 0x1000 0000

0x1000 0000 << 2 = 0x4000 0000

By just using the high 16 bits we have 0x4000 which happens to represent 1.0

 

The "magic angles" are calculated in this same numbering system.

Actually, that's fix-point math, but doing the double-shift left kills upper bits.

For demo0006 I use the sinus table from BLL using 8bit which should be sufficient for the screen size of 160x102 pixels.

 

Share this post


Link to post
Share on other sites

It has 32 bit automatic accumulate after 16*16 multiplication. So it presents a pipeline. It also has division and qubertroot.

Share this post


Link to post
Share on other sites
1 hour ago, Cyprian_K said:

so is Suzy math usable?

Sure it it. See the mandelbrot demo. But don't expect wonders.

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...

  • Recently Browsing   0 members

    No registered users viewing this page.

×
×
  • Create New...