Problems with shading and lights

[ProN3rd]

i am still having troubles with shading. Its a bit difficult to explain: the scene is rendered nicely with shadows even... but if I step inside the shadow, the shadow dissapears.

i am really struggeling with this. To explain i have enclosed three screenshots, where you see me flying in a tunnel which casts a shadow on the road (example1 and example2), the light source is behind right in the scene. However as soon as I am completly in the tunnel the shadow of the tunnel dissapears (Example3) and doesnt get rendered any more. The tunnel itsself is still rendered but it doesnt block the light any more. the ball is still casting a shadow on the road, which should be impossible as the ball is now fully in the tunnel.

The tunnel constist basically of thin plates using the top and bottom surfaces of the create cube function. The plates are wrapped around the road. I used Cullmode 1.

for the rendering pipeline, its nothing fance with the very basic setup. I didnt include any spotlight (1 to7) or ambient light, neither a 2nd spotlight-3 call at the end (shadows get rendered with the Xmake2d call it sais in the help file).

Make 3d
Set Cam
draw skybox
X Spot Lt -1 at cam pos
draw objects
X spot lt -3 at light source
draw objects again
make 2d

[BumbleBee]

Hi

Yes, you are right.  Shadow disappears when you dive into the shadow or you are close to the shadowcasting object and turning camera. I've already posted that bug 4 or 5 years ago
but it hasn't been fixed.
 

Cheers

[matchy]

I had some sort of problem like this where I'm guessing it's a zbuffering issue, which you can see in my video demo. Alternatively, I've experimenting with drawing the 3d objects from afar then inwards in a circle radar fashion. Otherwise, far objects with cover close object with no zbuffering.

My suggestion is remove the shading for now because really you don't need it. If you want to work on shading, produce smaller code samples to solve your problems rather than drag this awesome project down as we can't help due to a bug.

[erico]

While I never did much on the 3d front as of yet but I have a few suspicious.

I take your tunnel object is one object only right?
If so, imagine a cube surrounding the object on its boundaries, if your camera goes into it, you may loose the shadow.
I have seen this happening on open gl for ages into other aplications.

Possible way to resolve it:
-have multiple objects on the tunnel curve composing the final tunnel.
-Another reason could be related to front face polygons, here you will want your objects fully 3d closed, never as a thin plan.

Your case seems to be related with the first case, as the camera hops into the cube boundaries, specially on the concave part, I think the shadow renderer skips it since it believes you are inside it or something like that.

Can you upload that tunnel object? I´m pretty sure this is not a bug but it is just the way you have to deal with open gl.


edit: ops, just read that you are creating your objects on runtime... ;P
So try to create your arc segment with 3 objects, each covering 60 degrees from the 180 degrees arc, this way you will reduce the bounding box and the concave area, notice they must precisely fit together, otherwise you may get some light bleeding through. Secondly, make sure your light source is not going into the object and make sure the object itself is fully closed. This should resolve your issues. Additionally, you may want to create the tunnel segment part standing straight and then you clone it and rotate it because on some applications, if you create the object diagonally, the bounding box is going to form around it respecting world coordinates 90 degrees style and you will end up with a mess.

[erico]

Heck, this is horrible to explain with words only, let me try to show it.

On the ´box off' image you won´t notice any difference on your 3d game, you are probably constructing your model according to type A (ground is a different object).

Type B, I´m creating the left most piece first and cloning and rotating it 60 degrees 2 times, so to make the full arc.

Type C, I´m modeling the top part of the arc, cloning it twice and rotating a piece 60 degrees and the other -60 degrees.

Now check the ´box on´ image and you will see how the bounding box (red) behaves on the different types per objects.

Like I said, you don´t want your camera inside the red area or you will loose that object´s shadow.
So your best choice would be to use the type C.

The front 2 yellow blocks are just a visual guide so you see why when you model, it is important that the model is oriented towards the lowest bounding box area possible, the right yellow block is going to waste a good area while one could simply use the left one and rotate it.

I hope this helps. ( A,B,C, 1,2,3... ) 

[Ian Price]

Would it be possible to bake/fake the shadow? It won't fix the issue, but nobody will know...

[erico]

I will give a wild guess here:

-bake shadows is impossible since he is generating objects in code.
-fake is possible, it will add up to the number of texture tiles (just like 2d tiling when it comes to corners) or he will have to process shadows into the texture by the way of a virtual buffer, Mentalthink once pulled a technic for that by using the bump map channel, it is worth looking into.

I´m confident there is no issue or bug into this, it is just about dealing with the open gl as it is.
I have tried to explain it for ages, but our 3d vocabulary differs too much, hopefully the visuals will help.

I´m confident our shadow system is a projection map (or polygon) by its looks and it takes into account the object´s bounding box to speed up things considerably and cue objects that don´t need it, otherwise you would be looking into raytrace, which is not the case. By having the camera inside that bounding box, you kill its shadow. You will notice the chaps that responded earlier experienced the same thing:
"get close to an object and its shadow disappear"
And no, it is not a z buffer thing Matchy.
You don´t just model the whole world into a single object and expect a projection shadow map to work when the camera is inside its bounds!

I could be wrong... would have to try it myself. I´ve been wrong before.

[mentalthink]

HI Pron3n you have tried the command X_CULLMODE , perhaps the light and the camera into the tunnel don't works well.

The problem of X_Cullmode it's you can force draw the external and internal faces of a 3D Mesh, but you draw the double of polys... perhaps only apply to the tunnel don't drop down too much the FPS...

Another way like said Erico is doing the sadow pre-computed... In blender you have a very cheaper plugin for done the lightmaps or complete maps very very eaasily... and the good point in blender uses Cycles is a read good photorealistic engine. (Works with internal blender engine too).

[erico]

But Mental, the thing works, you just have to tile the objects considering its bounds and no camera inside it.
There is no way our shadow system is a raytracer, it is a projection map!!
Double face polygons won´t fix it. (while it is good to know, I didn´t know about that...)

[mentalthink]

  Sorry guys I don't read all the post and too much hours wake up... tomorrow I will back and will say another stupid idea 
Thanks for clarify Erico 

[erico]

Your ideas are great, problem is that what I said is theory based on ancient experience, but not experienced on GLBasic itself.
It would be best if ProN3rd or our friends that have similar problem could give it a try.

But heck, chaps stating this as a bug without trying it out first does bug me a bunch.
I can do some coding to try it out, but it will be a while, if some of you can code faster, I can provide the objects.

[ProN3rd]

I have recreated an example that shows exactly my problem in a few lines. Use ArrowUp and ArrowDown to control the player into the shadow. As soon as the player is fully in the shadow of the wall (tunnel), the shadow dissapears, meanwhile I will further check on your responses. thanks again for all your help

Code: (glbasic) [Select]

//Utility Class
TYPE Txyz
x;y;z
ENDTYPE

//Create Coordinates
GLOBAL pl AS Txyz ; pl.x = -0; pl.y = 0; pl.z = 10 //Player
GLOBAL cam AS Txyz ; cam.x = -50; cam.y = 0; cam.z = 10 //Cam
GLOBAL li AS Txyz ; li.x = -100; li.y = -400; li.z = 500 //Light
GLOBAL pr AS Txyz ; pr.x = 0; pr.y = 0; pr.z = -250 //Road
GLOBAL po AS Txyz ; po.x = 100; po.y = -75; po.z = 0 //Obstacle (Wall)

//Create Objects
GLOBAL player = GENX_OBJ() ; CreateSphere(player,5,10,RGB(255,0,0))
GLOBAL skybox = GENX_OBJ() ; CreateCube(skybox,3000,RGB(40,40,100))
GLOBAL road = GENX_OBJ() ; CreateCube(road,500,RGB(100,100,100))
GLOBAL obstacle = GENX_OBJ(); CreateCube(obstacle,100,RGB(130,10,130))

//Mainloop
WHILE TRUE
X_MAKE3D 1,2000,90
X_CAMERAUP 0,0,1
X_CAMERA cam.x,cam.y,cam.z,pl.x,pl.y,pl.z
//Draw skybox
X_CULLMODE -1
X_DRAWOBJ skybox,0
X_CLEAR_Z
X_CULLMODE 1
//Draw scene
X_MOVEMENT pr.x,pr.y,pr.z ; X_DRAWOBJ road,0
X_MOVEMENT po.x,po.y,po.z ; X_DRAWOBJ obstacle,0
X_MOVEMENT pl.x,pl.y,pl.z ; X_DRAWOBJ player,0
//Shadow light
X_SPOT_LT -3,0,li.x,li.y,li.z,0,0,0,360
//Draw scene again
X_MOVEMENT pr.x,pr.y,pr.z ; X_DRAWOBJ road,0
X_MOVEMENT po.x,po.y,po.z ; X_DRAWOBJ obstacle,0
X_MOVEMENT pl.x,pl.y,pl.z ; X_DRAWOBJ player,0
X_MAKE2D
SHOWSCREEN

//Movement Player
IF KEY(200); INC pl.x; INC cam.x; ENDIF
IF KEY(208); DEC pl.x; DEC cam.x; ENDIF
WEND

//Utility Functions

FUNCTION CreateSphere: num, r, n, col
LOCAL i,j, theta1, theta2, theta3, pi
pi = ACOS(0)*2
IF r < 0 THEN r = -r
IF n < 4 THEN n = 4

X_AUTONORMALS 2 // smooth edges
X_OBJSTART num
FOR j=0 TO INTEGER(n/2) -1
theta1 = j * 2*pi / n - pi/2;
theta2 = (j + 1) * 2*pi / n - pi/2;
FOR i=0 TO n
theta3 = i * 2*pi / n;
X_OBJADDVERTEX r*COS(theta2) * COS(theta3), r*SIN(theta2), _
r*COS(theta2) * SIN(theta3), i/n, 2*(j+1)/n, col
X_OBJADDVERTEX r*COS(theta1) * COS(theta3), r*SIN(theta1), _
r*COS(theta1) * SIN(theta3), i/n, 2*j/n, col
NEXT
X_OBJNEWGROUP
NEXT
X_OBJEND
ENDFUNCTION // n

FUNCTION CreateCube: num, sz, col
// Diese Variablen sind als LOCAL definiert:
// num, sz,
X_AUTONORMALS 1 // For a cube, hard edges
sz=sz/2
X_OBJSTART num
// Front Face
X_OBJADDVERTEX  sz, -sz,  sz, 1, 0, col
X_OBJADDVERTEX -sz, -sz,  sz, 0, 0, col
X_OBJADDVERTEX  sz,  sz,  sz, 1, 1, col
X_OBJADDVERTEX -sz,  sz,  sz, 0, 1, col
X_OBJNEWGROUP
// Back Face
X_OBJADDVERTEX -sz,  sz, -sz, 1, 1, col
X_OBJADDVERTEX -sz, -sz, -sz, 1, 0, col
X_OBJADDVERTEX  sz,  sz, -sz, 0, 1, col
X_OBJADDVERTEX  sz, -sz, -sz, 0, 0, col
X_OBJNEWGROUP
// Top Face
X_OBJADDVERTEX -sz,  sz,  sz, 0, 0, col
X_OBJADDVERTEX -sz,  sz, -sz, 0, 1, col
X_OBJADDVERTEX  sz,  sz,  sz, 1, 0, col
X_OBJADDVERTEX  sz,  sz, -sz, 1, 1, col
X_OBJNEWGROUP
// Bottom Face
X_OBJADDVERTEX  sz, -sz, -sz, 0, 1, col
X_OBJADDVERTEX -sz, -sz, -sz, 1, 1, col
X_OBJADDVERTEX  sz, -sz,  sz, 0, 0, col
X_OBJADDVERTEX -sz, -sz,  sz, 1, 0, col
X_OBJNEWGROUP
// Right face
X_OBJADDVERTEX  sz,  sz, -sz, 1, 1, col
X_OBJADDVERTEX  sz, -sz, -sz, 1, 0, col
X_OBJADDVERTEX  sz,  sz,  sz, 0, 1, col
X_OBJADDVERTEX  sz, -sz,  sz, 0, 0, col
X_OBJNEWGROUP
// Left Face
X_OBJADDVERTEX -sz, -sz,  sz, 1, 0, col
X_OBJADDVERTEX -sz, -sz, -sz, 0, 0, col
X_OBJADDVERTEX -sz,  sz,  sz, 1, 1, col
X_OBJADDVERTEX -sz,  sz, -sz, 0, 1, col
X_OBJNEWGROUP
X_OBJEND

ENDFUNCTION // sz



[erico]

Oh gee, I ran your code, and definently dosen´t seem like anything remotely close to what I was bragging about.  
It actually behaves really weird, I will try to find anything that helps the issue.

[matchy]

The obstacle is hitting the lens because the field of view is too wide. Here's my modified FOV and matching speed demonstration code:

Code: (glbasic) [Select]


GLOBAL fov = 90
GLOBAL cam_offset = 0
GLOBAL speed = 1

//Mainloop     
        WHILE TRUE
IF NOT KEY(57) // spacebar (new)
cam_offset = -200
fov = 15
speed = 4
ELSE // (old)
cam_offset = 0
fov = 90
speed = 1
ENDIF
                X_MAKE3D 1, 2000, fov
                X_CAMERAUP 0,0,1
                X_CAMERA cam.x + cam_offset, cam.y, cam.z, pl.x, pl.y, pl.z
                //Draw skybox



[matchy]

I hope this helps. ( A,B,C, 1,2,3... )

aine ?