Mesh Twitching when beyond 20,000 in Z axis.
Blitz3D Forums/Blitz3D Beginners Area/Mesh Twitching when beyond 20,000 in Z axis.
| ||
| 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. |
| ||
| 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. |
| ||
| 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. |
| ||
| 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. |
| ||
| 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. |
| ||
| 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) |
| ||
| Thank you. :) I'm working on updating the code now. |
| ||
| 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? |
| ||
| 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. |
| ||
| 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. |
| ||
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 |
| ||
| 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? |
| ||
| 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... |
| ||
| 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? |
   |