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() {
$('#slider'+arg).toggleSlide();
});
});

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() {
$('#slider'+arg).toggleSlide();
$('#button').unbind('click');
});
});

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.

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!

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...

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.

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.

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.

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.

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.

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.