I just playtested 2.5b9. Excellent work with the bump mapping and specular.
However -and this is pretty funky- firing the ray gun lights up the entire map regardless of raytracing or distance.
Brian, how many FPS do you get in my demo scene with b9 and b8 - and on what hardware?
Bradamante Wrote:Brian, how many FPS do you get in my demo scene with b9 and b8 - and on what hardware?
I'm going to put up another version in a little bit -- there's a bug that makes it overdraw all the models so the FPS right now are a little bit dodgy. Also, after that, I have some further optimizations I want to try.
For the next couple versions, the frame rate is going to go up and down and not represent the final thing; I'm trying to get all the proper math in place first and then optimize after that.
[>] Brian
One important note -- I'm looking at a scheme of pre-calculating visibility of meshes against one another -- this will be like automatic and much more fine portals, and will actually make drawing faster.
For this to work, though, importing your map as one big mesh will actually make things slower, so it's better to have your map as separate meshes taped together. I'm still working this over, but if you think about the "brush" type games, this is basically what they are up to.
[>] Brian
So... if I have one huge map, it will be really slow, but if say... every two or three rooms of a whole level are one obj, then it will be faster?
Bink Wrote:So... if I have one huge map, it will be really slow, but if say... every two or three rooms of a whole level are one obj, then it will be faster?
Sort of. Basically, the more meshes your map consist of, the faster it will be. You can have a massive map that uses 500 meshes, and it will run fine, and also have a small map that uses 30, and it will run fine. But it will run badly if you have a massive map with 3 meshes, and a small map with 1 mesh.
Alexander Smith Wrote:Bink Wrote:So... if I have one huge map, it will be really slow, but if say... every two or three rooms of a whole level are one obj, then it will be faster?
Sort of. Basically, the more meshes your map consist of, the faster it will be. You can have a massive map that uses 500 meshes, and it will run fine, and also have a small map that uses 30, and it will run fine. But it will run badly if you have a massive map with 3 meshes, and a small map with 1 mesh.
How massive is massive?
I can't think of creating a map that has 500 meshes. wtf.
Bink Wrote:Alexander Smith Wrote:Bink Wrote:So... if I have one huge map, it will be really slow, but if say... every two or three rooms of a whole level are one obj, then it will be faster?
Sort of. Basically, the more meshes your map consist of, the faster it will be. You can have a massive map that uses 500 meshes, and it will run fine, and also have a small map that uses 30, and it will run fine. But it will run badly if you have a massive map with 3 meshes, and a small map with 1 mesh.
How massive is massive?
I can't think of creating a map that has 500 meshes. wtf.
No, not at all. One large mesh = slower. Many smaller meshes = faster. It doesn't have anything to do with the # of meshes.
Think about it like this -- what I'm working on is that every mesh will know what meshes can be seen from it (but it'll be automatic, you won't have to set this up.) So, whatever mesh the camera is in, all other meshes that are obscured will automatically be eliminated.
So, you can have a map with a million meshes, and if they are setup properly, it'll be fast because it'll only act like a map with a few meshes.
This is sort of how the quake/ut stuff works, but it's at a "brush" level instead of a "mesh" level.
[>] Brian
You should make sure the height is settable for the mesh elimination. I'd hate to see this implemented and then lose the ability to get high up in the air. Or maybe have it calculate the visible meshes at varying heights and remember where that status changes...
Is this a new sort of portal system?