Large Mesh Problem
Blitz3D Forums/Blitz3D Beginners Area/Large Mesh Problem
| ||
| Hi! Please could someone help a newbie? I have imported a mesh (consisting of about 280 polygons)in .b3d format, but it looks terrible on screen due to massive artifacting along the polygon edges. I suspect the problem is due to the fact that the polygons are very, very large in size (the mesh is about 20,000 'metres' wide) as the artifacting seems to decrease in proportion with the polygon size (i.e. it doesn't occur with much smaller meshes). Is this a limitation of blitz3d (or directx itself?). EDIT - Or my engine? :} |
| ||
| How do you know it's 'metres'? Do you mean units? Why don't you make a smaller version then? Scale everything in your game by 1/10 or 1/100. |
| ||
| possibly a problem with the camera range? If your mesh is 20,000 units wide, part of it might be out of the camera's range and therefore causing the mesh to be rendered incorrectly. |
| ||
| Cheers guys! WolRon, It's in 'metres' because thats the unit size selected in the modelling package! Scaling the mesh by any factor in the engine doesn't make a difference... besides that, the FOV then reches from one side to the other (imagine this mesh is supposed to be a country!) It doesn't occur however with the entity below the troublesome mesh, which is of about the same size, but is only 12 polys.... TomToad, The artifacting does seem to worsten the further afield from the mesh, but this doesn't seem to be affected by the maximum range of the camera (as long as the mesh is visible, obviously!) Upon further observation, it appears to be a z-order problem, as it doesn't occur on the big mesh if I remove the 'box' mesh from contact with it... WBuffer doesn't solve it either :( Thinking back, I first noticed a this problem a few weeks back, but was (in that case) able to scale everything down. BUT, the problem only manifiested itself on my new GFX card - a Geforce 6800GT. It never occurred on my old geforce3, 2mx or an ati card I also tested on. All my drivers are up to date... perhaps it's a driver problem? |
| ||
| Well, I tried creating a 20,000 unit cube in Blitz and it worked fine without artifacting. I have a GeForce FX 5200, possibly a driver issue or maybe your modeling program is doing something weird to your model. |
| ||
| TomToad, The problem doesn't occur with a cube (the 12 poly cube I mentioned I created), only with a mesh which has many more polys. Thinking about WolRon's earlier suggestion, I will try scaling the mesh down inside the modelling package, rather than using scaleEntity in the engine itself (as this didn't stop the artifacting).... my reply that scaling it down causing the FOV to appear too big was (in retrospect) a load of tosh (it was 2:00AM GMT, and I'd had a long day!) ... obviously the camera's altitude would need to be reduced by the same factor, and that should (in theory) appear the same. I will try when I get back from work tonight! |
| ||
| Yep, scaling down the mesh in the modelling package does the trick... quite why scaling it down in blitz3d doesn't have the same effect is puzzling! Anyway, cheers guys for your help! |
| ||
| why scaling it down in blitz3d doesn't have the same effect is puzzling If the modelling program doesn't show the errors you see in Blitz, then the modelling program also cannot scale these errors. If you loaded the model into Blitz and it has visual errors, then scaling it will also scale the errors. Then after zooming in (scaling everything in Blitz) will show the same errors as the ones you were seeing when you didn't scale the models. It's just like having a number in a certain programming language (float) with 50 digits (behind the comma), e.g.: 1.12345678901234567890... If you divided that very accurate number by 100, it will now have also 50 digits, where the last 2 digits are gone, which isn't that bad, because the number is too accurate to visually show a difference. Let's take a number with only 2 digits (in a certain language which isn't as accurate as the other one): 100.23 Divide this by 100 and keep the number of digits, then this will become 1.00. Here you see that you've caused a significant error. So your modelling program could be able to store vertex positions and other stuff more accurately then Blitz, that's why scaling (and viewing) the model in the modeler doesn't show such errors. |
| ||
| Anyway, cheers guys for your help! Thanks for the Thanks. |
   |