Strange alpha problem...

Blitz3D Forums/Blitz3D Programming/Strange alpha problem...

Ross C(Posted 2005) [#1]
I was just putting a river into my landscape. A basic mesh, coloured blue and given an alpha value of 0.4 from within blitz. When viewed from certain areas, the mesh all but disappears. It leaves a very small amount of blue. Then re-appears from a different camera angle.

River disappears...




River re-appears...



River disappears again...



Anyone got any ideas?


Ross C(Posted 2005) [#2]
It's ok, i believe i've found the problem. My gfx card can only render 4 surfaces per mesh in one go. That mesh there contained 6, so it was buggering up randomly. Very annoying :o) I just took 2 surfaces out and it's ok :o)


Picklesworth(Posted 2005) [#3]
Whoever it was that is responsible for having such a limited thing as surfaces should be shot.

Nice looking river and terrain textures, by the way.
(I would say terrain, but I would probably be blasted by numerous people for it since it is mostly flat)


jfk EO-11110(Posted 2005) [#4]
And also, Terrains don't use multisurface.

Ross - I guess you are using ALE or FLE to create the terrain-mesh? Because, they use Vertex Alpha to "blend" in additional surfaces. But when you are using any alpha meshes, you'll automaticly get Z-Order troubles, exactly as you describe it.

This is also why I suggested RifRaf should use two meshes for FLE: one for the basic mesh with Texture 1. This mesh doens't use ALpha at all. The second mesh is made of the remaining 7 surfaces that are using Vertex Alpha. So you have to check for collision on less geometry, and it also allows to limit the Z-Order problem with additional Alpha Meshes.

There are still some versions of FLE tha are using the two meshes export method, but they lack of a number of features RifRaf added later (eg. Lightmapping)


Ross C(Posted 2005) [#5]
Yeah, it was created in ALE. It produces 4 versions of the mesh. What ever part is textured, is made into a surface, with all the triangles that are textured. I basically ended up with double the polycount, which isn't much use. I think i'd be as well texturing it manually using UU or something. Thanks for the comments :o)


D4NM4N(Posted 2005) [#6]
is this problem on all graphics cards


Ross C(Posted 2005) [#7]
It depends i think on how many textures the gfx card can render on a single pass.


D4NM4N(Posted 2005) [#8]
weird thing is, its fine for textures with alpha < .5 but textures with alpha of 1 seem in front of everything else.

jfk, i tried that idea of separating the meshes but no joy there, also tried having a separate mesh for each layer, still no joy.


Paolo(Posted 2005) [#9]
When you work with any transparent thing, if you don't
resolve then z-order manually then you will have different
problems in all the PCs.

Blitz render the transparent objects according to the distance
from the camera, the farthest first and the closest at the end.
If you want a mesh to be always rendered in front of another one,
you should modify a little the "position pivot" of the mesh,

for example if you have 3 transparent meshes, mesh_a, mesh_b and mesh_c
all at the 0,0,0 position you will get lot of Z problems,

let's say you want the mesh_c in front of the mesh_b which
will be in front of the mesh_a

you should add this when you load the meshes,

PositionEntity mesh_a,0,-30,0 : PositionMesh mesh_a,0,30,0
PositionEntity mesh_b,0,-20,0 : PositionMesh mesh_b,0,20,0
PositionEntity mesh_c,0,-10,0 : PositionMesh mesh_c,0,10,0

this way "C" is always closer than "B" which is always
closer than "A"

hope it helps :)
bye!

(the above code is correct only if the camera "Y" position
is always bigger than cero)


Ross C(Posted 2005) [#10]
Good tip there, thanks :o)


DH(Posted 2005) [#11]
indeed a good tip.