Clipping Issues

Blitz3D Forums/Blitz3D Programming/Clipping Issues

Omnicode(Posted 2013) [#1]
There's an issue or misconception with my current game and its been present in any scene i render in blitz3d.

I have no other idea on what to call it but it appears as though every object wishes to "clip" through each other.

Example Scenario:
Lets say there is a sword, the player is holding said sword and his fingers are around the sword. The sword's edges can be seen (only when moving) apparently glitching in and out of the player's hand. Though ik for a fact they aren't overlapping nor touching at all.

Desired Result:
--------------------- <-HAND
---] SWORD HERE [---
--------------------- <-HAND

Actual Result:
-----S---R--W---D--O- <-HAND
---] REST OF SWORD [---
--------------------- <-HAND

-Sorry... i just really like diagrams.



Its only when the main player moves, otherwise everything is stagnant.
I noticed this phenomenon a while back in most of my creations with blitz3d.

Its not my computer it appears to be universal, as i've tried on multiple computers/laptops. I'm using the castle demos FPS loop to render and keep everything going smoothly. The issue gets more and more noticeable the higher FPS(35 min.). Its nothing major just id like to tackle it to a reasonable extent.

NOTE#1: THIS IS NOT ACTUAL SOURCE CODE
NOTE#2: JUST MAKING SURE I DON'T GET A "DUDE UR NOT DEFINING ANYTHING RIGHT comment."


-Basic hierarchy of the games pivots and layering methodology.

Global Layer Pivots:(3)
-------\Sky 1
-------\Terrain\Creatures 2
-------\Player\Projectiles\Particles 3

\Sky
--\Sun\Moon\SkySphere\Clouds
\Terrain
--\Terrain
----\Trees\Bushes\Ores\Monsters
\Player
--\GROUND_PIVOT
----\CAMERA_PIVOT
------\HUD\CAMERA
------\ITEMS

Render_Layers: Sky<Terrain<Player (Prevents Sky going into terrain.. annoyed me; so i fixed)

Any insight would just be amazing.


xlsior(Posted 2013) [#2]
Stupid question but is the hand actually larger than the sword?

If the surface is in the same location, then visible surface may switch in places due to floating point rounding errors.

Alternatively, it could also be due to the scale of your scene. If things are too small, coordinates may also mash together.


Omnicode(Posted 2013) [#3]
I know of the situation you're speaking of and it was none of them, my issue, i believe was with my camera range. It seems when starting from the min view-range of (x<1) things begin to become rather entangled and block(y) with reference to z-buffer. I tested it and it managed to actually bandage the issue just by simply changing my min view range from .1 to 1 as this issue becomes non-apparent.

I used this min view-range to display objects very close to the camera; probably due to "floating point rounding errors" with a blitz camera.

So it appears tinkering and testing the issue by myself was the best bit.

Ill post some code when i get home to show how i tested this, though it's a simple fix id just like to actually show why i would even bring it up to begin with.

;Change
CameraRange P\Entity,.1,(1500+ViewDistance/2)
;To
CameraRange P\Entity,1,(1500+ViewDistance/2)

I kinda laughed when it worked tbh. It frustrated me for quite awhile.


Yasha(Posted 2013) [#4]
Oooh yeah a range of 0.1 to 1500 will often cause all sorts of problems like that. Ideally you want your camera range to be as small as possible while still enclosing the entire scene, and more significantly, the distribution of Z positions is non-linear, so extending the camera's near clip plane towards the camera itself will dramatically reduce the accuracy of things being rendered further away (the space between Z 0.1 and 1.0 in your original setup was wasting a sizeable percentage of the Z buffer's total ability to represent depth, something like 8-10%, not just 0.67% like you might assume if the distribution was linear; as well as throwing off the accuracy of the space beyond).

Good article on it here: http://www.sjbaker.org/steve/omniv/love_your_z_buffer.html

It uses OpenGL terminology but the principle is the same for DirectX.


Omnicode(Posted 2013) [#5]
Interesting, thank you for that bit Yasha, ur always here to provide input around these parts it seems. :D


Omnicode(Posted 2013) [#6]
Alright, well this new issue isn't really related to clipping but id like some input.

This issue is rather simple and is just mainly a question.
If you set an Entity's alpha value to 0 and then use Show or Hide entity commands, does it briefly reveal the entity? I've encountered this repetitively and is quite baffling. I was using invisible cones to give each tree a collision radius, hiding them from afar and then unhiding them (with alpha 0 - still shouldn't be visible) so that i could use them for collision testing however, once i reach my desired distance the collision cone flashes into existence for a brief second though nothing was done to alter its alpha value. The collision works perfectly just i wouldn't wanna be flashed with a cone of white everytime i get near a tree. Is this a rendering error? Or something spooky im unaware of within Blitz3d. The other weird thing is the effect only happens once per tree.

Here's the bit.





The only thing that seems to prevent it from occurring is by assigning an Autofade value that is so small (T\Scale/3):(T\Scale/3) that it dramatically decreases the possibility of it being seen. I currently don't have a autofade on the object, for this is the topic of interest; the appearance of an object though it has an alpha of 0 upon Showentity.