Mesh Twitching when beyond 20,000 in Z axis.

Blitz3D Forums/Blitz3D Beginners Area/Mesh Twitching when beyond 20,000 in Z axis.

Imperium(Posted 2017) [#1]
I'm working on a little simulation and discovered that whenever I exceed either + or - in the Z axis by around 20,000 the main entity in my game (the speeder bike) begins to randomly twitch. It corrects itself if I move back within the values above. The further I fly past this point the worse it gets. The effect looks like turbulence.

I don't use pivots or anything very advanced in my code. The Speederbike entity is a parent to the camera. The arrow keys control where the ship moves with the camera following. When you get off the ship with the "e" key it simply moves the camera to the left and unlocks the W,A,S,D, controls while disabling the arrow keys which move the ship.

Things I have tried:
1. Cleaning up the mesh.
2. Disabled the lighting.
3. Disabled the textures.
4. Changed all Move Entity to Translate Entity.
5. Disabled all moving entities except for player.
6. Changing the Camera and Parent relationship.
7. Not touching a single key, except for setting the player thrust and the issue still occurs once you hit over 20,000 even if you stop moving.
8. Disable Mouse Look.

I feel as if something must be slowly multiplying when you accelerate. I will have a closer look at my math.


Imperium(Posted 2017) [#2]
Okay even the most basic Move Entity command still triggers this issue. I have two type(1) lights at opposite 45 degree angles which do not move with the player.

My thought was the light was freaking out not having a max range defined, but then I remembered type(1) lights have an infinite range.


Matty(Posted 2017) [#3]
It is floating point precision.

Blitz (and i think DirectX 7) only uses single precision floating point variables which means that small differences between two values out of a large value becomes difficult to precisely calculate.

Hence if x# = 20000.0 and you want to move it to 20000.5 the precision of the floating point number may not be accurate enough to go to 6 significant figures easily.

This is not a bug in blitz this is standard numerical problems with machines.

You may have to reposition the world around the origin such that all values can be calculated precisely.


RemiD(Posted 2017) [#4]
To prevent this you can have a sector coordinate (between 0 and 1000) and a world coordinate
The entity is always between 0x,0y,0z and 1000x,1000y,1000z but each time it reaches a border of the sector, it is repositionned as if it was entering a neighbour sector (frontborder->backborder, backborder->frontborder, leftborder->rightborder, rightborder->leftborder, topborder->bottomborder, bottomborder->topborder) and the world coordinate is recalculated.
This way you can still have a world coordinate which is impressive, but entities only turn move in the 0x,0y,0z to 1000x,1000y,1000z sector.


Imperium(Posted 2017) [#5]
If I understand correctly every object in the world will reposition itself around the player then?

This idea of using sectors must be how Minecraft operates when it updates the Chunks in the gameworld.


RemiD(Posted 2017) [#6]

every object in the world will reposition itself around the player then?


no! ;)

let me try to rephrase it another way :
let's assume that each sector/zone has a size of 1000width1000height1000depth (like a big cube) with its bottom left corner at 0x0y0z and with its top right corner at 1000x1000y1000z

each entity (static or turningmoving) has a position in a sector/zone

let's assume that the world is made of 1000x1000x1000 sectors/zones

each sector/zone has a position in the world

let's assume that player has a position of 420x10y650z

let's assume that player is in sector/zone 54x0y22z

its world position would be :
((54*1000)+420)x ((0*1000)+10)y ((22*1000)+650)z

and when a turningmoving entity reaches a border of the sector/zone, it will be in another sector/zone and the turningmoving will be repositionned in the new sector/zone (so that when it go the opposite way it will reaches the sector/zone it was previously in)


Imperium(Posted 2017) [#7]
Thank you. :)

I'm working on updating the code now.


Rick Nasher(Posted 2017) [#8]
Regarding the topic(thread by RemiD ;-)
http://www.blitzbasic.com/Community/posts.php?topic=103259

Krischan had a nice coding example of repostitioning the world around the player instead of moving the player through it(mentioned in above thread too), which appeared to work very well. Direct link: http://www.blitzbasic.com/codearcs/codearcs.php?code=2622

I don't know which approach is more complicated/smooth though for I've never seen the 'zone system' in action?


Imperium(Posted 2017) [#9]
That post has been a big help Rick. I'm working on a very large and detailed city in my game, it took a long time for it to grow large enough to make this little issue of floating points surface.

So far I have avoided using any pivots with my camera or entities because I do not understand why they radically change how the camera render works? The camera without the pivot entity looks fine with its range set to 2000. If I take those same camera settings and use a pivot slightly behind the player ship the entire look of the camera changes.

I'll post an example of what I mean.


RemiD(Posted 2017) [#10]
I have coded something like i described in post#6 in the past, it must be somewhere on my hard disk, i will try to find it...

Found it, too old, too ugly and bloaty for not much, you better try to code your own thing by following what i have explained...

I coded that because i wanted to reproduce the "streaming system" that we can see in morrowind/boilingpoint, with a progressive loading/creation saving/destruction of the entities and their properties/states.

This is doable if you have a world with a limited amount of premade things/characters/vehicles and you only need to load/save their properties/state (the meshes/textures/skeletons/animations/sounds are all loaded in memory when initializing the game.)
You can also load/shape a terrain progressively if you use blitz3d ROAM terrains where you can define each height.


Imperium(Posted 2017) [#11]
No pivot, things appear normal.


With pivot, everything looks wrong. Movement including the mouse look is also much slower when you detach yourself from the ship. The skybox is no longer visible as it appears out of range for the camera range despite it not changing.


If you do not use a Pivot, instead attaching and positioning the camera manually within an entity the camera settings behave entirely different. Here is the normal code without the pivot from the first image.
camera=CreateCamera(redship)
CameraRange camera,.06,2500	
PositionEntity camera,5,5.80,8.75,True
CameraClsColor camera,0,0,32
CameraZoom camera,0.9



Rick Nasher(Posted 2017) [#12]
That's rather strange, for I wouldn't expect any slowdown as a Pivot from how I understood it is just an entity without a mesh, so no additional rendering. I can't say I've ever experienced the issues you refer to.

Is the skybox parented to the player or pivot?


RemiD(Posted 2017) [#13]
This is because a child is affected by the scale/position/orientation of its parent, so the camera may have its properties altered by the parent...
Anyway, i don't set the camera as a child of an entity anymore, i oriente it position it with the same orientation same position than a "eyes" pivot, so that the camera is not affected by the pivot...


Imperium(Posted 2017) [#14]
I should have mentioned that the slowdown isn't accidentally slow down, it was more like everything was exactly halved but no drop in frame rate.

Skybox
If DrawSky = 0 Then
PositionEntity Skybox,EntityX(redship),EntityY(redship),EntityZ(redship),True


Ah I think I get whats happening now. The Ship is scaled 12,12,12 which without the pivot the camera is matching these variables? With the pivot it loses the scale information in regard to the camera?