Baby's First Performance Issue

A couple days ago I decided to jump the gun a bit, and now I'm glad I did because it's taught me something new and caught a huge mistake early enough that it can be fixed.

One of the downsides to working alone and self-teaching is that it's incredibly easy to miss things, big and small. What I missed was that there's an inherent limit to the amount of "stuff" that can be rendered at any one time. And that makes sense to me, computer power isn't infinite. What I did was grossly overestimate how much stuff I've actually been making. Take for example the following:

Cue the circus music.

That's the first vehicle, made over one single night. It's not textured or properly shaded yet, but that's ok because it'll be easier to do in Unity. Since I'm all about efficiency, I can take parts from this and use it for the bicycle model I have planned and save a fair amount of time. Looking back, I still maintain these are good ideas in the right direction, but I was slightly wrong because I didn't have enough knowledge. Here's another look at the same unicycle:

POLYGONS!

That's the 3d mesh version, and if you zoom far enough in you can manipulate each individual vertex, line segment, or polygon. This unicycle is made of a little over 32000 vertices making nearly 27000 polygons. To put that in perspective, the models Capcom did for RE5's cutscenes only have about 20000 polys. Of course I only just now looked that number up, but maybe you can see where the problem is. At the time though, I'm still proud about making a pretty nice looking model. Charged by this excitement I wanted to drop it into Unity right away, put some basic movement scripts on it and see how it looked.

It didn't go well. To be honest, it didn't go at all. It took minutes to render, and when it finally did, the fps dropped to about 0.2. This was from only 1 (relatively simple) vehicle and 1 plane (4 vertices and 1 face). If I go through with making this an 8-player simultaneous game, then adding the the level and all the decorations, I can only think about my computer melting because of it. I was disappointed that this great job I did turned out to be not great, but more disappointed that I'd have to go back and redo a lot.

Optimization is mandatory. It's not something I wanted to do at first, but it's necessary and it's given me more ideas on how to streamline things for later. Looking around on Google for a while, I came to realize the following:

* It's not so much about the polygons as it's about the vertices.
* For each mesh, take into account the number of materials and shaders applied, the complexity of the physics applied, and the number of attached scripts. Each of these gets refreshed on each redraw for each frame and can tank performance.
* Redundancy is a bitch. If an asset (a tire, a seat) can be reused more than once, save it to a separate file and rebuild the object(s) in Unity later.
* Baking is something I need to learn. Yes, I'm well aware of the irony.
* A sense of scale is important. There's no sense in making ridiculously detailed models if it's too small to be seen. Those tire treads above? 23k vertices and they wont hardly be seen by the time you scale the model down to fit in the level.
* Similarly, there's no reason to render things that can't be seen. Any "invisible" polygons are just wasting time and power.


Baking (as mentioned above)... I don't know hardly anything about this. From what I gather, you can break meshes down into flat files to make thing render easier later, or something? I'm supposed to use it on high-res models to apply to a low-poly model to make it look really high-res, but Blender doesn't make it easy to figure out.


All of this leads to me cleaning up my models, redoing a few of them yet again, and trying to build them "differently". As mentioned above, redundancy can be worked around but you have to have each piece separate from the whole. With the Unicycle above, almost all of it can be reused for the bicycle later, so the Seat, Pedals and Assembly, Wheel, Spokes and Metal Rim, and Y-Frame have to be separated to be imported later. Once I get to Unity, I can import each individual object, put the pieces together and save the schematic as a Unicycle GameObject. After I finish making the bicycle frame in Blender, I can add that too, use the other imported parts, and make a bike with only one new asset. It's a bit disjointed to think about, but if it's going to make things run better than I'm all for it. Here's a preview:

Look at all of those vivid colours.

It still has a long way to go, but it's going alright so far. You can see the reused Unicycle assets here, but it's the "unoptimized" assets. Since making that bike, I've cleaned up the Unicycle a bit. I've reduced the vertices from 32k to just under 5k just by cleaning up unnecessary things. Rebuilding the bike wont take much time, and the only new asset to clean up will be the bike-frame and I'm not even done making that.

After the bike, I'm working on the next vehicle. I'm making a pogo stick.

Book learnin'

I burned through one of two books already. I'm going to try to keep this from turning into a book report, but it was definitely a good read, and very necessary. It's given me a ton to think about, new ways to think about things, and pointed out a billion things I had completely missed. (see edit at bottom)

Armed with all this new knowledge, I stopped playing around with Blender and Unity and started writing and brainstorming instead. In just a couple days, I've scribbled out a dozen or so pages worth of ideas. Notes, maps, screens, sketches, half-assed ideas, lists, really bad ideas, all sorts of things. Now I'm refining them all and sorting them into coherence by typing them up. I can't type maps and sketches, but that's probably just as well. There's something fun and calming just writing up a bunch of bizarre ideas and seeing where they go.

Anyway, all of this has helped me get together some new ideas and a more focused direction for where I want to go with the game. My next big push is actually going to be going back to Blender to work on more vehicles. On the idea list, I'm up to 17 vehicles (and counting!). I have no idea how many are going to make the final cut, but I'm aiming for a minimum of 10. A bigger constraint on the number of vehicles isn't so much about making them visually different, but more about making them handle differently in the game.

I've come up with 4 basic modifiers for each vehicle, being Top Speed, Acceleration, Jumping Height, and Rotational Velocity (specifically, how fast they can turn around any 1 axis to perform tricks). It'd be frivolous and a waste of time to have 3 vehicles with otherwise identical stats, though I may circumvent this by adding special abilities per each vehicle. I've been toying with the idea, and while I like it, I'm currently a bit stuck trying to figure out what some of these things could do without completely shattering the balance of the game.   In the short term it may not be much of a problem, but later I want to (eventually) add competitive multiplayer, and if everyone only picks 1 specific vehicle all the time then everything else is just a waste.

I'm sure eventually it'll all get figured and sorted out. First thing's first though, need to get back to modelling. Not going to lie, it's not a fun gig for me. Ever since Mario 64 came out I've had problems with manipulating 3d objects in otherwise 2d space. The clunky ui in Blender doesn't make it easier, but at least I'm finally starting to get the basic concepts enough to do something worthwhile. Slow going, but it's picking up some speed. Will post pictures of new models/concepts in a week or so.



edit - The book in question is this one. I'm not trying to advertise or anything like that, but it's well worth it's price; more so since it's discounted. It's a bit cheesy at times and aimed towards beginners, but it's amazingly thorough, comprehensive, and easy to understand. I highly recommend it if you're starting out in gaming. It's mostly oriented towards wide-appeal adventure games, but the information is broken down far enough that you can apply it to almost any genre.

edit 2 - What the hell was the formatting error all about?

Filler.

I'm afraid that this is more an update of reassurance. Yes, this is still a thing, and yes I'm still working on it. It's just been very short going lately, with a lot of setbacks.

The first major setback was finding out that the vehicle model I spent so much time on was broken. Specifically, some of the meshes had randomly missing faces, so that when rendered in Unity everything looked horrible. Not only did I have to make a new one, but I had to learn a new method to prevent against this happening again. The silver lining is that regardless of how annoying these setbacks are, it forces me to learn and actually gets easier each time. This will be a big help later.

In the interest of time (and perceived progress) I decided to skip designing an entire vehicle and instead opted for the simplest of vehicles; a single tire. No hubcap, no axle, no calipers or discs or anything else; just 1 object that can rotate around 1 axis and move in 1 direction. Simple enough, and exactly the thing I need to start learning to script in Unity.

This offers a new issue though. For all of it's greatness and ease-of-use and compatibility, it's really strange that you don't have direct control over the actual core of the code. If I'm using a standard IDE like VisStudio or Eclipse, you're working with something that's little more than Notepad++*. You type in everything (with some helpful auto-completion), compile, link, build, and run. You write functions, create classes, set up case-switches and if/else conditions and do/while loops. The contrast is that Unity attaches scripts directly to Objects. There is no int main() that governs everything. There's no source files to look at or change. While I had some idea of this before, it never occurred to me how counter-productive it would be. Each object gets a class script that manages how it works, but everything else is done through the ambiguated Unity interface. 


Don't get me wrong though. It's definitely a very clever system. Whenever you attach a script to an object, all of the public declarations are shown in Unity. Want to change a string? There's a text-box right there! Is there a double that you have set to be true only between values X and Y? Not only can you change the number on demand (with safety checks to make sure it's within bounds) but if applicable it gives you a slider for the specified range. These might sound like little things, but I have to appreciate it. It's unobtrusive, automatic, and as far as I can tell it can't screw it up. At worst, it wont bring the values in, which generally means you messed up and have to fix something anyway. 


So, where does this leave things? 


Realizing now that I'm struggling to grasp the basic concepts of what I'm trying to do, I've had to make concessions. The most important is that I broke down and spent money on the project. I'm not thrilled about it, nor do I like making excuses, but it had to be done. I ended up buying 2 books to help me through this. One of this is a reference book for Unity, inside and out. The other is more about game designing in general, encompassing all parts of game making. It sounds a little hokey, but it's actually a good read from a guy who's worked on several recognized titles. I'm not even a quarter-way through the book and it's pointing out a lot more things for me to think about.


The short-term plan is to read the entirety of the second book, the majority of the first book, and then pick up scripting again. By then, I should have a better understanding of this stuff. In the meantime, I'm coming up with a list of details to eventually work out, though I know most are not important right now. 


Also, the official working title for the racer project is now Omniracer. Or possible Omni-Racer.