dx lighting and tris
Blitz3D Forums/Blitz3D Programming/dx lighting and tris
| ||
| Hi, just playing with some code here and stumbled unto a problem. Creating a mesh in blitz then adding tris/quads to it - is there a way to update dx lighting on the tris as they are being rotated? Im not rotating the Mesh itself, just the triangles/quads... Thanks. |
| ||
| I am not sure what you are asking, but 2 commands immediately sounds familiar. UpdateNormals VertexNormal Andy |
| ||
| UpdateNormals VertexNormal Neither of which help the problem.. Okay, im creating a blitz mesh (createmesh), adding a surface to it (createsurface), adding the verts and building the tris (quads)... Now i set a dx light into my scene (createlight())... The mesh only updates the lighting if i rotate the parent mesh. (as it should do).. But im not rotating the parent (mesh)... im rotating the triangles/quads... Doing so I get no lighting on the surfaces (as I shouldnt)... My question is can i force the mesh to update dx lighting on the surfaces even though im not rotating the mesh.. Err i know this sounds confusing.. sorry. [edit] just added a bit more detail and some shots of the problem in this post http://www.blitzbasic.com/Community/posts.php?topic=30320 [edit] |
| ||
| Are you saying that you're rotating the quads away from the light source, but the lighting on them is not changing? But that the lighting DOES change if you rotate the tree mesh? AND you are using updatenormals() on the mesh after each update of the quads, OR are updating the normals manually with vertexnormal()? "im rotating the triangles/quads... Doing so I get no lighting on the surfaces (as I shouldnt)" Why do you think that the quads should NOT change their brightness when you rotate them? They SHOULD change their brightness when you rotate them. UNLESS you're not updating the normals... There is only one suggestion I can offer without knowing more about the problem, and that is that you should try redicing the radius of your light. Note that the radius of a light is the distance at which the light BEGINS to fall off, not the distance at which it finishes falling off. As such, any light with a radius that is very large will cause light glitches where rotating an object will cause the surfaces to very suddenly go from dark to light instead of having a smooth transition. |
| ||
| Yeah, agree with swift, the light should update as the quads in a mesh rotate. I think you might need to use one of the EntityFx commands.... or somthing. |
| ||
| Hmm I thought it should update too.. But seeing as the quads are being moved and not the actual mesh handle; I had to wonder if that was preventing it. At any rate, they do not update... light shows from all angles or in most cases - none at all. When applying updatenormals to the mesh I get a funky 1970's disco like effect ... the quads flash all diffrent shades of grey... Its quite pyschodelic! but not the effect I'm after :( If I rotate the mesh handle then the quads update perfectly.. but obvisously thats not what I want to do here. |
| ||
| Send me a verison of the demo with lighting and I'll make it work. :-) |
| ||
hey , this works fine, Just need to call updatenormals, and the mesh name. The camera is turning at the same speed as the quad, and you can see the light changing :)Graphics3D 800,600 SetBuffer BackBuffer() light=CreateLight() piv=CreatePivot() cam=CreateCamera(piv) PositionEntity cam,0,2,10 PointEntity cam,piv Global mesh=CreateMesh() Global surf=CreateSurface(mesh) Global angle#=0 v0 = AddVertex(surf,-1 , 1 , 0 , 0 ,0 ) v1 = AddVertex(surf, 1 , 1 , 0 , 0 ,0 ) v2 = AddVertex(surf,-1 , -1 , 0 , 0 ,0 ) v3 = AddVertex(surf, 1 , -1 , 0 , 0 ,0 ) tri = AddTriangle(surf,v0,v1,v2) tri1= AddTriangle(surf,v1,v3,v2) UpdateNormals(mesh) While Not KeyHit(1) angle=angle+1 TurnEntity piv,0,1,0 rotate() UpdateWorld RenderWorld Flip Wend End Function rotate() VertexCoords(surf,0, Cos(angle), 1, Sin(angle) ) VertexCoords(surf,1, Cos(angle+180), 1, Sin(angle+180) ) VertexCoords(surf,2, Cos(angle) , -1, Sin(angle) ) VertexCoords(surf,3, Cos(angle+180), -1, Sin(angle+180)) UpdateNormals(mesh) End Function |
| ||
| Heh nice example ross.. hmmm sadly though i get quite a diffrent effect when using this approach.. This is odd... Gonna strip out some stuff until it works then start adding back in until i find out whats causing it.. Also, im sure this has been covered... EntityAlpha() on meshes set to use vertex coloring (entityfx mesh,2) dosent work.. its either all the way on or all the way off. Im sure its because setting fx 2 truns off alphablending ? Try ross's example with enityfx command remed out, then try it on.. Graphics3D 800,600 SetBuffer BackBuffer() light=CreateLight() piv=CreatePivot() cam=CreateCamera(piv): CameraClsColor cam,255,0,0 PositionEntity cam,0,2,10 PointEntity cam,piv Global mesh=CreateMesh() Global surf=CreateSurface(mesh) Global angle#=0 EntityFX mesh,2 EntityAlpha mesh,.5 v0 = AddVertex(surf,-1 , 1 , 0 , 0 ,0 ) v1 = AddVertex(surf, 1 , 1 , 0 , 0 ,0 ) v2 = AddVertex(surf,-1 , -1 , 0 , 0 ,0 ) v3 = AddVertex(surf, 1 , -1 , 0 , 0 ,0 ) tri = AddTriangle(surf,v0,v1,v2) tri1= AddTriangle(surf,v1,v3,v2) UpdateNormals(mesh) While Not KeyHit(1) angle=angle+1 TurnEntity piv,0,1,0 rotate() UpdateWorld RenderWorld Flip Wend End Function rotate() VertexCoords(surf,0, Cos(angle), 1, Sin(angle) ) VertexCoords(surf,1, Cos(angle+180), 1, Sin(angle+180) ) VertexCoords(surf,2, Cos(angle) , -1, Sin(angle) ) VertexCoords(surf,3, Cos(angle+180), -1, Sin(angle+180)) UpdateNormals(mesh) End Function Ross, thanks. Sswift, thanks. |
| ||
| Good news! I found the problem! Better news! I dramatically increased the speed of the rendering! Aren't I great? I'm so great. I postively wonderful. You owe me big time! Good now that that's settled maybe you won't kill me. :-) Remember that Quad function I wrote for you? Well I kiiinda forgot that when testing I added FOUR triangles, two wound clockwise and two wound counterclockwise. Go into "addquadtosurface" and delete the two addtriangles at the end under the counterclockwise header. And here's a weird thing. When I deleted those two and ran the program, the black quads went away. But they shouldn't have been there in the first place cause those are back faces. They should have been invisible. And if I only add the back faces, the trees have no foliage at all, so they clearly are not visible. Yet they were cuasing graphical glitches somehow. And now for the really weird thing. After I commented out those lines, I uncommented them and ran the program again. The black stuff was gone. But it should have been there. AND, if I install a completely new copy of the one you sent me where the black glitches were appearing in the first place, they're still gone. I think this is a bug in Blitz. I think that Blitz somehow set something on the video card wrong in the first place cuaisng the black glitches because of the back faces which should have been invisible but were not... Perhaps a zbuffer issue... And then when I fixed it it toggled something on the card driver and things are now normal, but I bet if I rebooted it would go back to not working. This might have something to do with the zbuffer and transparency... It migth be interesting to see what would have happened if I took out the CLS from your main loop. which btw, you don't need. That may lose you a bit of speed. So there you have it. I think it was the backfaces causing the problem, but they should not have done anyhting worse than just make the scene a little slower. Try remvoign them from your code and let me know if that solves it. |
| ||
| Aha... I rebooted and the black tris were still gone so I now realise why the black tris were there when using updatenormals! The reason the black tris were there is because the corner vertcies of the quad were connected to both the front and the back faces. Because these face in exact opposite directions, it is impossible to calculate a normal for them which is halfway between the two. So all attempts to clauclate the normals ended up getting screwed up. It should also be noted that even if the two sides had used individual vertcies, if you'd used Mark's updatenormals function you would have seen the same results, because MArks' updatenormals function looks for vertcies which occupy the same space and smooths across them. This sometimes leads to graphical glitches when you have geometry arranged in weird ways. So that's what was going on. No zbuffer problem or bug in Blitz' rendering. Just normals that were impossible to calculate because of one tiny bit of debugging code I'd mistakenly left in the quad function. :-) |
| ||
| !! thats great news Sswift!, thought I may had stumbled upon something that 'couldn't be done'.. :) I actually thought those 2 additional triangles were left in for tform rotation calcs... good to know! :) Nice research... Thanks. |
   |