Tuesday, December 27, 2011

UDK's inverted normal maps, and how to fix them

I have been modelling for UDK

For a little while now and I came across a hitch. The normal maps on my models were apparently inverted. This was odd because they looked fine in blender. As you can see in the picture, it looks like my bricks are concave, rather than convex.

The bricks are accepting light opposite to the direction from which it is being cast.

A short jaunt in google brought me to this thread. A bit of fiddling and I have found a workaround. The short version: invert the green channel of your normal map. The long version? Read on...

Monday, December 26, 2011

Graphics vs Imagination

I've been playing a bit of Project Zomboid recently, which has me thinking about the nature of graphics, and our brains way of interpreting presented information. Anyone who has read a book and then watched the movie knows how much of the experience is lost purely by having the visual input catered for. Characters on screen are vastly different to the ones in our heads. I think it's the same with computer graphics and our experience of them.

Friday, December 2, 2011

Reserved words in Mysql

Here's a quick one for anyone who has a query that just won't work (insert and update in particular). Mysql reserves certain words for its own uses. One such word (and the reason for this post) is 'desc'. An oft used abbreviation for 'description', 'desc' recently caused me three hours of confusing, frustrating code rewrites and function restructuring. Turns out naming a column 'desc' is a right reserved for mysql, and if you try it mysql will not tell you about it, just imply a syntax error. Mysql hogs 'desc' and other common names. Seems a bit selfish to me.

Just out of interest, here's a list of mysql reserved words that you should keep handy in case of an insolvable refusal of your query.

I fucking hate mysql.

Thursday, December 1, 2011

Website visual design vs function design

You'd think that as a modeller I'd have a good grasp on the visual side of web design, or at least enjoy it. Well I don't. I find designing the look of a site tiresome and unrewarding. It's like playing tennis. I'm shithouse at tennis and, as a direct product, I hate the game. You need to have a certain amount of success to enjoy an activity. I find more enjoyment in coding functionalities and subsequently wearing out my f5 button testing my multitude of minimal modifications. There's a lot to think about with visual web design. Page lines, unifying texts, colour balance, information weighting and heaps more. This all goes sailing over my head as I tap away at php and jquery functions, so my web designs are inevitably un intuitive, uninspired and ugly.

Friday, November 25, 2011

Breaks vs burnouts

I have recently taken

Somewhat of a compulsory break from all things art related. I went to Vanuatu with my girlfriend! It was my first overseas trip. Without boring the readers with an analogous diatribe of my personal exploits and adventures (of which many were had), it will suffice to say that I had a good time.

Saturday, November 5, 2011

Local Dining in Vanuatu

I hadn't been overseas before. At the age of 22 I had not stepped foot outside my home country. That was a big deal for me. I had the travel bug long before I travelled, and I had to stop putting it off and just pop the cherry. The trip was with my girlfriend and we discovered we both have different travelling styles. We met some fellow Australians, some Ni-Vanuatu (that's what you call people from Vanuatu) and not many other people. Believe it or not, the majority of tourists in Vanuatu are Australian.

Thursday, October 13, 2011

Lunchtime with Melonhead and The Thumb

"So you're just handing over all your work to this random internet guy?" Melonhead leaned back in his corner-booth seat and raised a quizzical eyebrow. The bustle of the restaurant was muffled by the plush cushioned backs and the privacy of the booth often led to long boozy conversations.

"Well it's not that bad, we're using an SVN" I retorted.

"Wo wo wo, enough with the mysterious acronyms" The Thumb stopped slurping her wonton soup to interject. "we're all friends here, ok?"

Tuesday, October 4, 2011

All awesome and no skill

I have heaps of pictures

In my head that look awesome. Amazing accomplishments of artistic grandeur. Unfortunately my hands don't share the vision. I have pieces of art meticulously planned but I just don't have the wacom skillz to make them a reality.

Or so I have convinced myself

Recently I have had projects that require more marathon work than I am used to. I have been working on my current model for almost 180 hours spread over the last month. And it has taught me quite a lot about how liquid a piece of art actually is. I used to (and by used to I mean had done up until the model before this one) be scared of changing anything for fear of ruining what I had so far. In some cases this has definitely been the outcome, but a well planned ctrl+s has saved my skin.

Thursday, September 22, 2011

An Itty Bitty Combine Soldier

Rawr! After a suggestion from PlanetPhillip for a combine-manufactured headcrab, I couldn't stop myself. It was originally meant to be a reskin, but I am a little girl who has lost her mummy at Cronulla beach when it comes to texturing (that means I cry), so I modelled instead. Luckily I have been fiddling with compiling animations onto existing rigs with custom meshes over the last few weeks and it was all fresh in my mind. This was also designed to slip straight onto the headcrab rig, so it was pretty smooth sailing in general. I think I might do a tutorial on this sometime soon.

Overall the model took me about four or five hours, the texture took maybe 12 hours and the source-related stuff took under two hours. It took me three days from first vert to finish, and that was working in my spare time between other more important models (more on them later perhaps). If anyone happens to read this and has any idea about how to package it so anyone can download it and plonk it in their map without overwriting the old headcrab, please leave a comment, I am really struggling to code this in.

Monday, September 12, 2011

Models? On my modelling blog?

That's right!

I finally have something to put up here! I have recently started up Modelsforthemasses.com, a prop modelling on-demand commission site dealy for source engine props. I was actually still coding the backend of the site when I got my first job request! Since then they have been coming through steadily, and I am on my way to being a self made freelance artist! That makes me so happy in warm fuzzy ways! Anyway, onto the pictures!

The first one is a Makarov pistol, a Russian weapon designed to propel balls of metal at high speeds with intent to harm, using a system of sliding metal parts and small amounts of pre-packaged explosives, all set off right in the palm of the wielders hand. It's an out there concept I know, probably won't catch on. Anyway I made it all from scratch and handpainted all the textures. It's the first ever weapon model I have made from start to finish, and I gotta say it was a bit of fun. As usual, loops and poles swung into action, even on this very inorganic model.

After the model was handed over to the dude, I needed to make some pictures to showcase it for the site so I quickly replaced the existing pistola in HL2 and recompiled. After some very quick adjustments and minimal changes, it used the existing pistol animations seamlessly, like it was made for it. Faaaaantastic. here's a picture of it reloading:

The next one was an SKS rifle, another russian weapon, but this time the dude had a highpoly model already made. After adjusting it to suit blender a bit I modelled the lowpoly out and baked the details on then textured it. Again, I compiled it just to showcase:

So, after making these and getting them to work in engine, I see now that I baked out way too many details. There are a lot of parts that I could have left on with no detriment to budget, since I could have deleted all the backfaces. You don't see the backfaces on viewmodels, but the engine renders them anyway, so you're better off baleting them. If I were to do it again I would leave a whole lot more poly details in since source is where normal maps go to die.

I have more requests coming in and I am currently working on one that I am excited to show here. Soon... very soon...

Chase that feeling

It's a pretty common misdemeanor

In the modding community to announce a project long before any concrete work has been done on it. All too often we will see threads requesting feedback for a project that hasn't even been started on. These are often met with a mix of disdain and helpful advice, in varying proportions.

I think the reason for these underproduced projects isn't completely from lack of skill or motivation, as one would assume. I think it comes from the same reason that I don't like posting WIPs. When someone has a brainstorm for a project (especially ADHD 12 year olds from FPSBanana) it's not the finished product they are striving for. It's not the experience gained from working on a mod nor the relationships created between mod team members. It's the feeling they are chasing. The chemical reaction in their heads that tells them they are or have been a part of something.

I think everyone can relate back to their first modding idea. It was going to take the scene by storm, the internet was going to love it and it would have the biggest mod community out there. People would line up around the block for your every blog post, just like you had been for the mods you were watching. These thoughts would fill your 12 year old brain and make you feel elated. You would imagine every outcome, have conversations with yourself about your mod, plan what you would say when people would beg to join your team, and start designing logos before even opening hammer.

Now while you are thinking these thoughts, your brain is releasing the chemicals (enzymes and endorphins and shit, I guess) that you would feel if you actually were in that situation. This makes you feel like you have already accomplished all these things. It's the same reason that people who hang around distinguished martial artists and watch heaps of kung fu videos but have never raised a finger assume they could kick a palm tree in half, Van Damme style.

Once that post requesting for help is up there, the experience is over. Those chemicals have done their rounds and your pancreas is all out of ammo. People may find your idea interesting, but anyone with the nous or tenacity to see a mod through knows better than to pledge allegiance to your over thought out, under media providing, catchword using fanboy speech. This is the part where the thread dies with a measly 7 replies, 4 of which are yours.

The proper way to release or announce a mod

Can be viewed here, here, or here. Notice the provision of media, the unassuming thread starter and the "yeah, we made it, so what" attitude. These are hallmark signs of a productive mod team. They are busy actually making the mod, not telling everyone how great it will be when they make it. Now I'm not saying that in order to glean a good following and public interest in your mod you have to be side on to your audience, but approaching a project with an "anything and everything" acceptance is a terribad solution to a simple problem. That problem being that you are 12, have ADHD, play CS:S for 90% of your spare time, and have little modding skills but want someone to make a mod "with" you.

My point here is not "lurk moar noob" nor is it "no media no recruits". No amount of cajoling, namecalling or rageposting is going to change the fact that everyone has to be a jellybean before they can be a jaguar. My point here is that they aren't seeking a mod team, community or even any real success. They are chasing the feeling they would get if they had all those things, without the large amount of work required to gain them, and the mere act of posting a thread gives it to them.

Or maybe it's just that they're 12, from FPSBanana and skinned a crate from CS:S once with a texture they found on the first page of google images.

Monday, August 29, 2011

UDK or Source?

bear with me in this post folks, I have had a lot of chocolate

As you may have spotted

I'm a pretty entrenched source modder/modeler. I think I only did this because I saw some of the awesome stuff people were making on Interlopers and because I wanted to make models and maps for L4D when it was booming. That and the fact that the SDK was free pretty much tipped my hand.

I have worked with other engines briefly in my earlier days when I was modeling really bad models for really bad games being made by really bad dev teams. One project took me through 3D Game Studio (HORRIBLE), Torque3D (AWESOME) and a few others I forgot about. Recently I have also worked with Wolfire's phoenix engine which was awesome and I plan on using it exclusively if they release it.

This week I decided to try out the UDK after seeing all the pretty screenshots people have managed to get out of it, and after hammer and studiomdl.exe combined forces to send me into an uncontrollable fit of rage. Well folks, god damn. God. Damn. I can't even think of a witty caption to describe just how much more I like UDK. Just to be clear, Hammer hates me and the feeling is mutual. Every time I try to learn how to use hammer, I come out the other side with blood pressure like a hyperbaric chamber and a desire to defenestrate my monitor. We do not get along.

The UDK map editor, however,

Made me want to explore it. I watched some tutorials (which were a: easy to find, b: mostly up to date and c: maintained by the developers of the engine. All features you won't find in valves documentation. And don't VDC me, the VDC is about as understandable as the poo smears of a demented monkey on smack.) and I immediately started to make a map that looked nicer than anything I ever created in source.

I also decided to make a model to see how the blender pipeline would work.

Just to put this in perspective, it took me somewhere between a week and ten days to get my first model into source. Granted I was pretty new to engine modding then, but this model took me about an hour. The learning curve was so slight solid helium would hardly slide down it. The material editor is nothing short of awesome, considering I used to use MapZone for textures and blenders node compositor, the layout was easy to grasp, albeit the node names are kinda wierd.

Drag and drop!

I think it was about the late nineties when drag and drop became the norm for interface accessibility. Source SDK has **no** drag and drop. Everything is imported and exported using backdoor and commandline tools that may or may not break your asset, mod or even themselves if you aren't the dude who programmed them. UDK is just drag-and-drop-a-licious.

So anyway enough gushing, I could hate on source all day, hell I have spent the last two years hating on source, but it won't get me anywhere. In my dream of being an indie art developer, modding has very little chance of turning a profit. Mods were a good stepping stone to help me learn how models need to be made for actual games, but I think I'm ready to kick that rock over and jump in the mud now. I'm moving to UDK, fuck source.

Saturday, August 13, 2011

Don't blame it on the boogie.

I tend to get a lot of work done

But not a lot of projects finished. I think this is a pretty common habitual mishap for young artists. The projects I have followed to total completion are usually a product of a few days of hammering away excitedly and having ideas pouring out my ears. I have created a few websites, a few paintings and a lot of models this way. It's a pretty effective workflow because the ideas are all fresh in my mind, the skills are polished up and the time taken is minimal. I can easily smash out a heap of small props, a couple of medium scale projects, or a few highrollers in the space of a few days.

But what about when I can't afford the hard and fast approach?

Sometimes the weekend comes to an end and my mega explodey starburst funtime model of awesomeness didn't quite make it to completion. I go to work and come back to an easel of half finished strokes and a muse that has taken off in her lightspeed warpdrive spaceship in a direction exactly opposite to mine.

What do I do now? This is often the make or break point for budding artists. I've lost the groove and subsequently blamed it on the boogie. I think this is the point that weeds out the successful modellers from the happy ragtime blendernewbies permanents (not that there is anything wrong with blendernewbies, but people should only really be there for two years at the MOST). It's around this stage that my mentality needs to change from fast and hard to slow and steady. I need to re-analyse my creation, externalise my internal criticism and objectify my actions. Yeah that's a lot of flashy catchwords but they're about as succinct as I can be.

Re-analysing my creation

When I started my happy go funbang model of solidified amazing I had ideas bubbling from my eyeballs. Now I'm all out. The ideas may still be there, but they aren't as awesome and achievable anymore. I don't really have a strong direction to work towards. I need to look at my art so far and decide what I want to do with it. Come up with an overall goal for the final product. Sometimes it's monumental. That's fine. I strongly urge everyone to set their goals beyond their skills. Arnie never got massive from lifting comfortable weights.

The point of this step is to create a specific end goal so that I will have a better idea of when my project is complete, as well as how I am progressing in my workflow.

Externalising my Internal Criticism

This is a pretty simple concept, but can be elusive to get right. I see internal criticism as when I notice a colour is too saturated, or a quads' diagonal midline is running the wrong way. External criticism is when I post my work on a forum and get advice and opinions from community members. I find that providing my own external criticism helps to develop a style, since I am re-inferring my own opinion onto my own work.

By looking at my work as if it had been posted on a forum and I am telling Old Matey McForum Member what I think of it, I find lots of potential improvements and catch some prominent mistakes. I like to do this after any significant change, or a significant amount of insignificant changes.

Objectifying my Actions

It's about this point where I realise that I have just committed myself to the equivalent of painting the roof of the sistine chapel with my armpit hairs while blindfolded, concussed and covered in sandflies. But that's ok! Alan Turing never created the computer by studying 10th grade maths! I'm a big fan of setting small achievable goals and that is exactly what I do at this point. I'll look at what my creation is now and what I want it to be, and I'll break it down into steps. Ok so I know I want him to have a wrinkly ass forehead and big dimples, so I need to move some loops around. I know I want that bit to be shiny so I need to make a nice specular map. I'll break it down and down until I have something that I can do right now, and will only take half an hour at the most. The hardest step of any journey is always the first, and it seems that once I have started work, my muse comes a-knockin'. All of a sudden I need to fix this and improve that, which makes this look out of place so I correct the other to fix that and that improves this. And so on.

The point is that if I have a nice easy job to do I'll be more inclined to do it, and once I am wrist deep in a whizpop whoopee smileface sunray batch of liquefied goddamn, it's much easier, and way more fun, to tackle the more complicated problems.

By this stage

It's about 2 in the morning and I have roughly 5 hours till I have to be at work but I don't want to go to bed because my muse is starting to play with her spaceship keys in her pocket and I don't know if she'll be back again. So I crunch and go to work trashed and come home with less inspiration than the night before, then run through these steps and do it all again till my eyes are poking out on stalks and I look like a junkie who has been pilling for weeks.

And that's how I rediscover my groove and apologise to the boogie.

Tuesday, August 2, 2011

Why I'm not posting WIPS

I decided that for this site

I won't be posting up work in progress shots, and only put up finished models. The reason for this is because on all the places I post and all the other sites I have had I have put up WIPs for critique and because I was proud of my meagre accomplishments. It was ok while I was learning because I needed the feedback. I think I have got to a point now that I know enough about the layout of my mesh and the modelling process to be able to effectively critique my own work, and I know enough people that I can talk to individually to get valued feedback.

WIP shots also look very unprofessional and messy. It's a whole lot harder to look at someone else's WIP and see what it could turn into. It just looks like an unfinished model, and it's pretty boring looking at a blog full of unfinished models. I have found recently that WIP shots demotivate me as well. It's like I subconsciously tell myself "well, it's on the net, I don't have to work on it so much now". And that leads to projects dragging out longer than they should.

Besides those good reasons, I'm hoping this blog will have some impressive models on it in the coming months and I don't want to clutter it up with bad WIP shots. No one wants to have to wade through a river of crap to get to a couple of shiny dimes.

That means less models on the blog, but higher quality of entries, which I am very comfortable with.

My affair with loops and poles

Goddamn I love loops and poles

If you don't know what loops and poles are, google for 'loops and poles blenderartists thread'. You are cutting your own arm off if you model without this awesome bit of education.

Loop flow isn't just an organic modelling consideration, I was modelling a gun recently and I had to pay attention to the loop flow of the mesh every step of the way. When baking down high resolution meshes it's vital that you avoid any smoothing artefacts, and knowing about the flow of your mesh and being able to use poles to target and direct the flow is a paramount. If you need a smooth crease in your mesh ie for a wrinkle in a face or a fold in the handgrip of a gun, you put a loop there.

Loops are one of those concepts that just miraculously work every time and make everything better. They're like the midas touch for your meshes. It's like a missingno cheat to get rare candies for your modelling skills. I cannot count the amount of times I have had a particularly problematic area on a mesh and one well placed loop has fixed it. Or the amount of times I have put in a fresh loop only to have the other end of the loop fix up a spot that I wasn't happy with.

Poles make my pole pole up

If you think that sounds gay you need to start using poles. Every mesh needs them. Even a cube. Actually, a cube is all poles. By knowing how to place poles and how to move them around you have the entire world of modelling at your hands. A loop needs a pole to tell it what to do, and if you ever have a bad looking pole that means your mesh is about to fall apart. When I first started learning poles I thought I could get away with a 6 pole here or there, and my meshes fell apart too. Then when I went in to fix it up I found every time that it was the 6 poles fault. Simply by removing that pole my meshes would suddenly work again.

I absolutely love poles and loops. They make organic modelling fun, not arduous, they make my meshes neat and wonderful, not messy and convoluted. If you model anything, even if you just start with a box and sub-d your way down, you absolutely have to get in control of your loops. If poles and loops were two dudes I'd let them spit roast me and it wouldn't be gay. THAT'S how awesome they are.

Sunday, July 31, 2011

toggleSlide() and while loops.

I came across a problem tonight

That I thought I'd share a solution to. I was mysql_fetch_array()ing in a while loop to output a bunch of data in seperate divs, and since it was getting bulky and cluttered I decided to add a toggleSlide() so I could collapse them individually.

So I decided to supply an argument in the form of the entry id returned by the loop. I appended the id to the end of the divs in the loop and to the argument of my slide() function using a PHP echo. And this is where I hit a snag.

When you give toggleSlide() an argument and put it in the onclick selector, it accumulates your clicks. This must have something to do with the + sign you need to use when you add the argument. What this means is that

Function slide(arg) {
$('document').ready(function() {
$('#button'+arg).onClick(function() {

Will have an odd and unexpected effect. The first click won't have an effect at all, the second click will slide up and then back down, the thid click will move three times and so on. The trick here is to add an unbind() command to the button element. So

Function slide(arg) {
$('document').ready(function() {
$('#button'+arg).onClick(function() {

Will have your loop returned divs sliding around nicely!

Just to clarify, the div returned by your loop would look like this:

<div id="button<?php echo $id; ?>" onclick="slide(<?php echo $id ?>)"><img src="someimage.png" /></div>
<div id="slider<?php echo $id; ?>">Some content</div>

Look at me, gettin all tutorialicious and junk.

Thursday, July 28, 2011

Prop modelling

Well this was supposed to be a modelling blog

And so far all I've done is waffle on about coding, games dev and "the industry" So I figure it's about time I actually showed some models. BUT not without waffling on a bit more, after all "blog" stands for "Batman lingers overhead gruesomely", and that means you have to type stuff AND things. In that order.

I have been spending most of my modelling time lately modelling props for a few mods, and it's ok I guess. I think I have the workflow down pat, the last models I made (the wooden pillars) only took me about two hours each from concept to finito. Which is a nice turnaround I guess. But the problem with prop modelling is it really gives you no portfolio pieces. Sure nice props can really help make a games visuals pop, and custom props seem to be in short supply for source mods, but no one is immediately impressed by a bunch of chairs and boxes. Portfolio pieces have to show really detailed intense models. Characters are portfolio killers for sure, and all of my current forays into organic character modelling are... short of the mark.

So for lack of anything worth portfolio entry

I give you "allmyprops.vmf". Well, I give you pictures of it. Luckily, this isn't literally all the props I have made, just all the ones for the current two mods I am modelling for. Without further ado:

These mods are unannounced, so consider this a sneak preview, and expect to see them in a mod soon!

Wednesday, July 27, 2011

Blender for industry work

I use blender for all my modelling

And I really like to use it. It's fully featured and exports to enough filetypes so that anything you create can be opened in any other software. The art produced from it is easily as good as the art produced from the industry standard packages. But it's having a hard time pushing in between the shoulders of the big boys.

I was looking at a few freelance boards tonight

and all the jobs had maya or max as a requirement. In fact it was almost a requirement to NOT use blender. But I'm wondering just how necessary that is. I mean, since I can export to just about any format, can't I make my stuff in blender then convert it? If I am working from my own computer in a freelance set up, they don't need to see me working in max, right? I honestly believe that working in blender would not be a burden for jobs like this.

So that's the bottom version of 'in industry' paid work, and blender could pull its weight. Perhaps it would be a good idea to have a version of max or maya to test your exports in, but who's going to spend all that money for a program you won't use?

Let's go one step up the ladder

To an in house design firm. Blender is fully featured, it's not the college project one course horse it was 5 years ago. It can do all the things you need in a design/production scenario. If a firm already uses max then I can understand that the extra step of exporting from blender to max might not look very deadline friendly. But why use max to start with? Blender doesn't require you to pay for multiple licenses, it's open source so your in house coders can modify it to do anything you need it to (ok maybe max can already do that thing you need, so tick one up there, but a day of coding would still cost less than three or five max licenses), and it would allow the firm to employ me, which is a tick off the bucket list.

So, providing some allowances, blender can cut the cheese in a small firm environment too.

What about in a high tempo, stressful, triple A games development company?

Well, blender fanboys, I'm afraid this is the break. Being a blender modeler simply would not cut it in this environment. The amount of collusion required for producing high level games on budget on time does not allow for an open source whore to hog the bandwidth and clog the pipes. BUT. Blender can make games. Blender can export to the first five game engines that pop into your head, and if it can't then all you need is a bit of python know how to make an exporter. If a high tempo games company used blender then they could be every bit as successful, AND employ me.

Luckily the story doesn't end there.

What about the indies? Indie games dev just gets bigger and bigger, I think the main reasons for this is that it's what you do when you can't get a publisher, and it grants you total freedom over your creation. This is where blender comes into its own. Indie devs live on a shoestring, it's the nature of the beast, and any free software is a likely candidate. Blender is the most logical choice here (although I'll admit I haven't looked into the other free modelling options available, but we're talking about blender vs goliath, not milkshape).

I see indie games as my best option, I love the indie games scene and the best bit is I don't need someone to choose to hire me. Simply by making a game independently, I am an indie dev. Although at my current level of coding I can't just burst onto that scene instantly. I'm still getting my head around javascript so I think java is a few steps ahead of me.

All things considered

It's probably best for someone who plans on being in the industry to brush up on their max and maya skills. It pains me to say it but blender is not a resume killer in that environment. The indie scene is the place to be for blenderheads, but even then, it's hard to be anything more than another blip on the radar.

But if your art is fantastic, why should it matter where it comes from? Damn I guess I better make some fantastic art then. Because even in the indie scene I am FAR from employable...

Tuesday, July 26, 2011

Strategies for outmanoeuvring your immobility

My biggest hurdle is myself

I have had days where I sit and stare at a blank blender screen from dawn till dusk. I have had months without a single finished piece of art. I kick myself constantly for being unproductive, and that self-kicking only serves to make me less productive, it's a negative positive feedback loop. I'm sure this is the main reason why I am not currently soaring through the skies on a magic carpet made from the shredded prints of a million amazing artwork pieces I have produced.

But I haven't had a day like that for months now and it is all thanks to me. I have successfully trained myself out of inaction and underproductivity. Well, almost. It's a constant battle that will never quite be won. But here are a few strategies that make the battle a whole lot easier.

Have you ever spent a day staring at a blank screen with a blank mind

Only to spent the entire night in bed, wide awake, ideas racing through your head, muses dancing jovially on your cerebellum? Damn right you have or you wouldn't have read all this crap. Strategy number one is to emulate that night-borne ideas rush. Find a quiet relaxing spot to sit and just let your mind run over your craft. Two of the most effective locations I have found are in nature parks (no shit, trees just make me want to model) and bed. If you happen to fall asleep that's ok, you'll wake up refreshed. And don't worry about how much time you're wasting away from your project, it's just time you would waste staring at your blank screen.

Strategy number two is to start on something small. I am easily scared by big projects, so I do a fast mini project first. For instance today I was making totem pole models and I got a little overwhelmed. There was a lot of design decisions and loops and mesh repeat points and I started to slow down a bit too much for my liking. I decided to make some vine models I had been meaning to make instead. After a few hours I had the vine models finished and looking good, which gave me the motivation to model my totem poles. Or at least, do two different concepts.

Strategy three is not so much a strategy as it is a lifestyle shift. Sleep is way underrated. I know, most programmers/modelers/textureartistes/computerdudes love to stay up late, smash coffee, pull all nighters for no apparent reason, hard resets, crunch volleys and the rest of them. But it's not a good way to go. Eight hours sleep and a well nourished bloodstream does amazing things for my art. I can make decisions faster, comprehend poorly written shorthanded tutorials better, self analyze more effectively, it's just me2point0 with a proper sleep regime.

Those are the main pillars of motivation

That I have found helped me shake my habitual inactivity. But you don't have to stop there. Whenever you have a good session, think back on what triggered it. I know that playing Red Dead Redemption makes me get a hard on for blender within half a stroke so I also use that sometimes. If you find what makes you want to produce, make a mental note of it.

By far the most effective though, is the first one. If you are having real trouble creating, stop trying to create. Daydreams are like burley for muses.

Monday, July 25, 2011

JQuery and I

I am an avid modeler,

And a not so avid coder. I don't get the same kind of relaxation and fun out of coding as I do modelling. I enjoy myself thoroughly, but it's hard to love cricket when you can't swing a bat. I think it's the learning I like. Working at my job doesn't give me too many opportunities to demonstrate intelligence, and learning stuff helps me fill that gap. So coding isn't so much a hobby as it is a means to an end.

But tonight I found jQuery

And found a reason to enjoy the shit right out of web development. I had been skeptical about using it because I have already had to teach myself php, javascript and the nuances of ajax, I didn't think I was really ready for another language just yet. Man I should have started with jQuery. I have been used to following tutorials for hours to get the basics down, and then inferring stuff and googling and whinging to psi on the wolfire irc and taking a generally monumental amount of time to make any real progress in my code. Tonight I slipped jQuery.js into my head and immediately went shooting across the galaxy on a blazing fireball of solidified awesome.

The reason I picked it up was because I wanted a nice slide effect for a div so I could hide and show it onclick. I found what I thought to be a very ominously unpromising example. 6 lines of code and assigning a few classes/id's. I copypasted it into my js.js, changed a few parameters and refreshed my page, wincing at the thought of the hours of frustration I had just resigned myself to.

It immediately worked just as planned.

Better than planned. My div slid smoothly away to its little hiding spot, and even did a little bouncy bit when it extended. I emptied the contents of my testacles straight into my pant leg. I sat there for a good half hour just opening and closing my div.

Hopefully this is the heralder of some more fantastic functionalities for my future forays into the field of javascript. I'm going to make so many slidey fadey movey divs on my site that you'll think you're watching a remake of Tron.

Sunday, July 24, 2011

Coding ecstasy

So i've been coding

In php and javascript for the past few days, and it is an alarmingly addictive process. In fact I think it harbours a lot of the hallmarks of addictive drugs. The way addictive drugs work is the first time you use them you experience a great high and have a great time, then as you use them more times you have some bad experiences as well. But then you have a good experience and it far outweighs the bad.

When I'm coding I often work for hours on one simple little function, and the code teases me by doing either nothing or crazy random stuff, and I spend more time bugsquashing than actually coding.

But that one minute when my function works

Oh man. Fantastic. I am a coding god. Javascript is a peon toiling in the infertile fields of my oppressed kingdom and must answer to my every whimsical desire. I throw my arms up in the air amd wave them around like I just don't care. This is what edison must have felt like when he invented antibiotics. This is real acheivement.

Then it's back to hours of painstaking bugchecking and confusion because I forgot to capitalise a letter somewhere. Or I used an inverted comma instead of a quotation mark. Oh man I cannot count the amount of times that has happened.

I think amyone who has coded much knows what I am talking about, even if I am only coding lowly js and php.

Saturday, July 23, 2011

Wood textures, by george!

Wood textures are a pain in the

Pooper to make look any good. They have long been the bane of the budding texturer, and are the basis of many a specialized program or photoshop plugin. They haunted my dreams for quite some time. But I think I might have found the key concept of wood texture creation.

The key to creating wood textures

Is to stop trying to make it look like wood. Hear me out.

Wood has so many intricacies and details that we don't register seeing. The more we try to make a wood texture look like its real world counterpart, the more it slips into the uncanny valley. Google it. So to combat that unfortunate inevitability just forget about making it look so real.

For starters, forget about woodgrain. That is freakin impossible to paint unless you're some sort of superhero painter. Some base colour variation is ok, but the woodiness all comes from the rest of the texture.

So I guess you want a tutorial or something

We start with a base color, some kind of brown, any shade will do, we'll have to adjust it later anyway. Then we grab a random grungy texture and dump it into the next layer and change it to overlay mode. We up the contrast of the new layer until we have a bit of stark texture variation. Then we go grab a different picture amd do it all again. And that's almost it.

The trick is in the pictures you choose and the modes you use. Have a look how it comes out when set to soft light or value mode, fiddle with the opacity and contrast and saturation. I find the best results come from photo textures that are desaturated and with the contrast hiked a touch. For better base colour variation try blurring the guts out of a texture and setting it to overlay mode.

As you can see, the texture doesn't particularly look like wood, but it doesn't look like it's not wood. At least not as much as a texture designed to be wood would. But when you apply it to a model, all the viewer sees is brown and noise, and assuming it's not a major set piece, that's all they'll need to see to see wood.

Now that's not all you need to know. Your texture may be passable as wood, but you don't want to let the viewer see a whole mess of your unconvincing wood texture. Otherwise they might notice that they have been duped. Try to populate your model with other texture materials and avoid having gigantic panels of wood.

It also helps to know the renderer you will be using, and to add some specular highlights in what would be the high spots. This model is in the HLMV (source engine for the uninitiated) and I have used a greyscale version of the diffuse with the contrast cranked and the brightness down. It is using a cubemap specular reflection and it just helps with suspension of disbelief a little. I may or may not do an actual tutorial on this later. See if the mood takes me.

Friday, July 22, 2011

Game development mindsets

Let me start this one by saying

I am not a gigantic halo fanboy. The first one was good, the subsequent ones... adequate. But it's the mindset that each installment represents that I want to talk about here.

Halo 1 was a solid game from any standpoint. The gameplay was pretty well paced, the art was pretty for the time and console, and the story was intriguing. Halo 1 was a good example of a game made by people who wanted to make the game they wanted to play. Each level was different enough from the last and introduced a gameplay mechanic that seemed like bungie wanted to explore some different aspects of level design. Bungie was a well established developer before they made Halo 1, but I think they had fun making it, which is the whole point of making games, isn't it?

Halo 2 was, in my opinion, pretty fucken horrible. The engine had some serious flaws, the renderer couldn't make up its mind for the art style, the gameplay was, well, fast and hard and kind of fun, but overall forgettable, and I don't know if it was just me or the storyline was actually just breifly glossed over. Halo 2 felt like the kind of game that a studio that has just made it big and needs to capitalise on their success by pumping out a sequel would make.

Halo 3 was a very deliberate game. The art direction was strictly adhered to, the engine was refined to a fine machine and the storyline was explored fully. This is what bigtime professional game develolment studios make. Admittedly, there was no real exploration of new exciting mechanics or strange development quirks, which is the way of big game companies, they pointedly amd tenaciously stay with the tried and true in order to satisfy fans and maximize profit. But that doesn't have to ne a bad thing, I'm looking at you, EA.

You can see the stages of growth

Bungie went through as they moved from one game to the next. The original game was made by a team of dedicated, talented team of ambitious developers, the second episode was made by a group of people struggling to reclaim the mindset that gave them such organic success, and the final installment was created after a corporate restructure redefined the company's attitude toward their craft.

The point is that the mindset of a developer

Will always have a massive impact on the work they produce. You might notice a similar concept in things you do every day. The first few weeks you spend at a new job are spent making sure you impress the boss and get it all right, and you enjoy yourself because you are experiencing new things. Fast forward to a year later and you are in automated zombie mode. It takes no concious effort to perform what once were intricate tasks and the quality of your work might not have dropped, but has changed.

In games development I think it is important to never lose sight of the fun you have creating. I have had days, weeks and months where I have all but given up on modelling because I open up blender and just stare and the empty workspace in front of me. And I create things in these moments, and they are just... different.

Thursday, July 21, 2011

Trees man, how do they work?

Working in the source engine makes making trees an expensive and painful task.

The material system in the source engine seems to rely on dirtymods and workarounds. Traditionally trees consist of a mesh based trunk with static particle leaves, a quick look at any speedtree based game will show this. Stock valve trees don't have this, which makes me question the applicability of the "sprite" shader that comes with the engine. If valve saw fit to not use this shader to make their trees, why would I want to?

I guess I'll have to have a look into the use of that shader. Using a sprite system would change the way I make trees anyway. Using static polygons means you can use simple quads to define whole branches, but with a player-view particle you would have to only render leaves and leaf bunches, not the whole branch. Otherwise you'd have rotting branches and it would be quite a fiasco.

Trees are an already resource intensive application

And I don't think it is in my capacity to change this. Particle leaves would be cheaper to render since they would have only one side but then more polygons would be used to define each leaf cluster, and more branches. Static mesh leaves can define larger branches and such, but they have to be rendered twice, with $nocull.

LOD models are definitely a must for trees, the trunks can be dropped from an 8 vertice circle to 6 and then 4, leaves can be removed and edgeloops in curved faces deleted, the final LOD can be a billboard (which also eludes me in source, so I have to make my final LOD models crossing quads) which renders very cheaply at all distances. But I think that system can be further optimised.

I plan on making not only tree models, but tree clumps, or stands. Up close these would be just a bunch of trees and simple undergrowth or whatnot, and then as you move through the LODs I can change not only the individual trees to billboards and such, but multiple trees. In a wide stand of trees I could leave the outer trees at LOD1 and have the center trees go to LOD4, drastically dropping the polycount without the difference being too noticable. I could even have all the center trees drop to one or two billboards depicting a render of the whole stand of trees, giving the illusion of bushiness and depth.

At a very far distance trees tend to bush out enough that they look like little broccoli heads, and this could be the final LOD, a very simple dome or arrangement of billboards that would look like the original clump from a distance and could be used to render on distant terrain. I think it would be a better system than most these days, especially on hills. Tree billboard LODs on hills look terribad, a few clump dome LODs would look far better, and if you take into account the amount of billboard LODs a simple forest would have at that distance, I think the clumps would be cheaper to render.

Actually, you know what? Computers are far better than I give them credit for. Current LOD systems are probably optimised plenny. No LODs, voxels everywhere.