This week I have been finishing off ( hopefully ) tweaks to the main player and getting rid of any errors that have popped up. One of the main ones was obvious seams where the character had been split apart. Previously I had hand edited the normals anywhere the player mesh was split which would often get rid of anything visible, but was very time consuming and left us with a mesh that was fragile, with them sometimes resetting when moving between max and maya.
This week I’ve been having heaps of fun doing stuff like this:
The motorbike and the vehicle refactor are coming together well, I think I’ve found a good balance between realism and fun given the relatively limited control scheme (it’s hard to handle turning and leaning well without an analogue input like a thumbstick). I’ve put a early build together that we’re going to be testing internally and we’ve been talking about pushing out the vehicle changes before the itemv2 update so watch this space!
I’ve also been doing some more work in itemv2 working on the backend of our baking system pooling groups of datatypes used by meshes. This allows us to preallocate the memory the baking system is going to use rather than request it at runtime. When working with high level programming languages like C#, systems like this are essential for good performance as the garbage collector (named because it turns no longer used objects back into free memory) isn’t fast enough to work smoothly in real time and frequently leads to framerate spikes. If we preallocate all (or at least most) of the memory we need on start up and don’t release it we can massively reduce garbage collector use.
I’ve also developed a system for turning static meshes into basic skinned meshes by binding them 100% to one bone.
This should help modders out creating items like hats and masks easily, I used this horse mask from the asset store, bound to the head bone to test it out.
Hiya everyone. This week I optimised a lot of the city assets, and played with a new map-making tool.
One of the big challenges with the city, as we’ve mentioned before, is getting it to perform well. It’s a complex problem with some distinctions from optimising an open terrain like Diemensland. We get a lot more out of aggressively culling objects, and it’s much less noticeable due to the amount if culling we get from the buildings. We started of as you can see at around 30fps in most scenarios, and up to 3 million polys.
The first thing I did was write a tool to find the objects hogging up the render time – where were we spending these polys? Well, it turned out we were spending a lot on very small amounts of texels at a distance – that is, lots of polygons were making up very few pixels. I put on my 3D modelling hat and made some quick and dirty LODs for the worst offenders. Thanks to Mils’ modular design of the city, this meant I only had to make a few before we got some real dividends.
You can see a before/after performance comparison below.
I’ve also been playing around with Map Magic, a recently released procedural terrain composition tool. Hopefully we should be able to streamline our map making process using middleware tools like this in the future. As worthwhile as Shigi Tools was, and probably will be for some niche procedural generation, the more tools we can outsource, the faster we can make content. I’m working on reproducing some of the basic microstructure that we ended up with in Diemensland. Think the hills, rock placement, tree placement. These were all iterated over a lot to try and get a good feeling of scale and place. Reproducing this in an entirely procedural way will really allow us to lock in the micro and start playing around more easily with the macro. This has meant I’ve gotten to right some cool procedural heightmap generators – check out this custom warp generator I whipped up!