.... then it's err.... more than one thing.
So exporting a road system or town enmass (or either in fairly large sections) came to a juddering halt, or more, the model format was the juddering halt.
Meshes don't fog correctly (I knew that anyhow), they fog along total model size rather than individual plane, but I wasn't too concerned about that or the lack of lightmaps (in hindsight I was probably looking to create too much work for myself). But when the far side of the bounding box hits the max visibility - *piff*paff*poof* the whole model vanishes. It's called pop-up, bane of games since 3D appeared - or in this case pop-off.
How much trouble can a square mile of town cause? Errr ... loads.
Pop-up occurs when things suddenly come into view, out in the distance. Unless you want a fairly low visible draw distance. Like fog or night, anything other than a clear day. It's all the more noticeable then, especially if your models are fairly large.
So, back to Binary Space Partition. It fogs correctly (or at least by per plane), it has lightmaps (yay, correct shadowing), per plane collision, and to be honest it's not that much of a processor load. But it is Old School (no, I'm not spelling it with a K) BSP, and it likes it's straight polygons (tweaking vertexes annoys it) and there's no bezzier meshes - which essentailly was what I was using the model mesh for (nice curves).
BSP FTW!
It's a bit temperamental --- or more the exporter is a bit temperatmental (*crash*bang*wallop* emphasis on crash). Like all things the exporter is a WIP (apart from human evolution allegedly, which I read somewhere might have stopped - that means this is as good as it gets, folks! I want a refund! And the prehensile tail back!)
But the good news is that Blender can export as an old Quake3 dotmap, so all the work done in modelling roads is not lost. A bit of tinkering to make my meshes a little more BSP friendly and then pass it on to Constructor for exporting (fingers crossed whilst it takes it time to work out lightmaps for 8000 surfaces without crashing) to a BSP format (with a reduction in scale to 34% for some reason). And it all seems to work fairly nicely.
'Ave it!
And the framerate is good. For one huge BSP it runs at well over 200+ frame per second --- with a whopping visible distance of 1000 metres. And of course it self culls when visibility is reduced, thus eliminating unseen surfaces.
With a road network sorted out, I started to add a few basic buildings to my source file in Blender. And the fps was still fine, so I worked out it'd be better to model all my static buildings (one's you can't go inside) enmass (that word again) with my road network.
Buildings that can be entered will have to sperate BSPs, slotted carefully into place in-game. This is because of portalling (culling via line-of-sight view) and the need to prevent portals from one side of the dotmap being able to see into others - thus nullifying the portals and the extra fps gain.
Whilst I'm still sorting out the town and it's buildings, I do have a 1600 metre square area accessible to the player as a single BSP. The textures are all still placeholders and are just a little difference for testing purposes. For a further quick test, I threw in 4 varities of 350 trees (with basic LODs) and found the fps was still a good 170-250 with 800 metres visibility.
Bad guy at 200m: the realistic size of the target is an explanation of why I'm such a cack shot in real life
To be honest it's the urban environments that have been causing all the problems recently. For rural environments I've already come up with a working design solution.
So, yet another problem (hopefully) solved. Finish off my town basics, then sort out a few interactive buildings, throw in some models, knock up some working textures (still umming-and-ahhing about the art style a bit), and I should have a proper environment. The just to script it into a playable level.
All this whilst suffering from the dreaded lurgy. (that's flu to most people --- and that's a common cold to women)
;P
No comments:
Post a Comment