objects blinking on and off strangely...

Blitz3D Forums/Blitz3D Beginners Area/objects blinking on and off strangely...

tsmpaul(Posted 2010) [#1]
Hi guys. I've done lots of stuff with Blitz3d, and never had this problem before...

In my project, I load up a some 3D objects, and position them where I want them. My problem is, some of the objects flicker - they appear and disappear, then appear again, then disappear again, etc. I'm not sure what the problem could be!


xtremegamr(Posted 2010) [#2]
Could you post some sample code? It'll help us help you :)


tsmpaul(Posted 2010) [#3]
Hi! Funnily enough, I just worked it out after hours of uneventful trial and error.

It's the distance the object is from coords 0,0,0.
If I go too far from the middle of the blitz 3d game environment, objects flicker and won't display. If I bring them closer to 0,0,0 then they display fine without an issue.

I'm doing a realistic solar system, for space simming, and while I can make the planets life-size, at a scale of 0.5 units = 1 kilometer, I need to massively adjust how far the gap is between them, to fit all of the planets within the 'boundary limits' of the blitz 3d engine.

At the moment, I'm runnig our solar system on an orbit distance scale of 150 km : 1 km, but Neptune and Pluto are still so far away if real measurements are used, and fall outside of the Blitz environment's drawing zone.

Does anyone know what the 'boundary' size is for a blitz 3d environment?
I need to work out how far away is the maximum I can place a planet and not cause glitches, then I can rescale my solar system to fit inside the size limit.


tsmpaul(Posted 2010) [#4]
I should do more research before posting! Sorry to double post, but in case anyone else wants to know as well, I worked it out.

Blitz Integers only range from -2,147,483,648 to +2,147,483,648

So, anything in a game that falls outside of those coordinates x/y/z will have problems. As long as objects are within those 'maximum' coordinates, they will display fine.


Yasha(Posted 2010) [#5]
...are you sure this is a problem of appearing/disappearing, and not just appearing in the wrong place?

Blitz's 3D coordinates don't use integers, they use single-precision floats, with a range of something like 10^38 - so max range shouldn't be the problem. However, they only have an accuracy of about seven decimal places - in other words, the object will move in minimum increments of ten thousand or so once its position is measured in the billions, as the number lacks the precision to move more accurately than that.

Normal approaches to solving this problem include creating more than one scene at different levels of scale, and switching between them impreceptibly, so that each is being drawn within the limits of single-precision. Half-Life 2 provides a notable example of this with the Citadel background.


puki(Posted 2010) [#6]
This type of problem can also occur when Blitz3D cannot determine the correct centre of a mesh and incorrectly culls the mesh which can cause it to flicker. You can use the FitMesh command to centre any meshes within Blitz3D - assuming that this is what is causing the problem. If these meshes are flickering from a distance, then it may not be the problem, as this would normally occur when the mesh is partly on screen and Blitz3D is culling it from what it thinks is the centre.


tsmpaul(Posted 2010) [#7]
Hi! Thanks for the suggestions guys. I tried them out to see if any would solve the problem.

Going to a distance from a world still caused objects to flicker - and also, teh further away, the more objects on the other side of a planet would appear and disappear briefly - seen through the planet. I assumed this was then a 'draw order' problem.

I tried assigning manual entityorder values to everything, and there was no more flickering, it drew them correctly on the screen. The problem is, with objects orbiting objects, and the player position constantly changing, the entityorder values for everything in the level would have to keep changing too! I couldn't work out a good way of doing that that worked.

I ended up trying the 'switching between different scales' that was suggested above.

Since within a certain range, there is never any flickering, I changed the game scale and made two scales of measurement. I have a kilometers value, which is used for measuring and sizing planets, moons, sun, etc. And I have a meters value, which is used for measuring ships, stations, character movement, etc. They don't equate to each other like in real life - so a 'kilometer' unit is not 1000 'meter' units. I've gone for a ratio of 4 game units is one meter, and 8 game units is one kilometer, and then I did this:

Instead of making planets bigger or smaller, they are all roughly the same size object - but when the player is at a planet, the meter variable is shrunk or enlarged instead, so the player, ships, stations, etc, are shrunk or enlarged, giving the illusion that each planet object is much bigger or smaller from world to world, and it takes longer to fly places when the planet is 'bigger', and faster to go places when the planet is 'smaller'.

This has worked out great, and resulted in no more flickering or draw order problems of any kind.

The only problem is, now when orbiting a gas giant, any objects near the camera have shivers, because the camera/player/ship is shrunk so much. So I've made the gas giants relatively smaller than they would be in real life, so there isn't such a size reduction on the meter variable, and that's made the object shaking very minimal now. They're still huge compared with places like Earth.

At the moment, I explain the shivers in the game by saying that the gas giants are so big, they cause turbulence with the ship's gravitic drive :)

Anyway, here's two pics from 'external camera' view, showing how planets appear to be bigger when it is the spaceship and camera that have actually shrunk.

'small' planet of Mercury



'big' planet of Jupiter




Mikorians(Posted 2012) [#8]
For everyone's info:
I had this problem years ago with my solar system simulator, and object occlusion errors were caused by using such a large scale that it confuses the z buffer.