Source compiling issues AGAIN

So I recently tried to compile a model for source and received a semi-cryptic error in the form of:

WARNING: *** Encountered VTF file with an invalid minor version!
WARNING: *** Encountered VTF file with an invalid full header!

I also had two materials on my model. The materials were in separate directories. I don't think either of those points were the problem. Considering it said the vtf file has issues I figured it was the vtf at fault. I had been using vtfedit to convert my png's to vtf's and I guess I hit a flag somewhere or something.

I fixed the problem by exporting my vtf from GIMP instead of converting it with vtfedit. I get the feeling I did something else too though. If that doesn't work for you, read on.

Blend textures to add subtle wear and tear

I want to talk about tiles. Tiles are a nice texture to use because they have a lot of innate detail. They have grout, which provides opportunities for nice normal maps and variations in phong/envmap specularity, they can have cracks on them which looks cool, and the tiles themselves can have cool designs or just alternating colours. The problem with tiles though is that this inherent detail is misinterpreted for ease of use. As nice as it is to slap a tile texture down and give yourself a pat on the back as you sip you freshly prepared congratulatory cognac on the rocks, it's not at all that simple - as usual, como siempre.

Tiles are actually a pain in the ass to lay down in real life. I tiled my toilet and bathroom once. It was horrible. You have to cut here, lay there, measure this, and it's all such work. This experience led me to look at game tiles in a different light. No longer can I drop a tile texture down, rotate it 45 degrees and think no one will look twice.

Blackford Stormington's Canine Pedestrial Assistolumundus!

Not enough time in the day to take your best friend for a rigorous constitutional? Stresses of ultra-modern life weighing you down? Overweight and lazy? Then look no further than the latest in Assistolumundus™ technology!

From the brains behind the Terry Toilsworth Tarry-no-more and the Automatronic Runcible Spoon comes the finest in modern lifestyle-augmentation design! A brand new approach to canine walking, the CPA ensures that old Rover gets the exercise he needs. With the newest Assistolumundus apparatus you'll find more hours in the day for your scholarly pursuits! The finest machining guarantees longevity of service and minimal parts-replacment, as you can see in the following demonstratory motion image reel:

Order yours today!

Benchmarking Models

For a while I have been wondering how to find out just how resource-hungry any model is. Obviously the more details in a model the harder it will run the PC, but exactly how much, and what is the hungriest, is somewhat of a grey area for me. I was hoping that perhaps someone had made a program into which you could load a model and it would tell you how much cpu it takes to load, how much ram it requires, etc. Unfortunately it doesn't appear that this exists. This is understandable considering the different needs of engines, the different PC environments and I assume a whole range of other crap. But I still want to have something to benchmark my models against, dammit!

New York Garbage Truck

So I'm pretty proud of this

Another model made for ModelsfortheMasses. This one is supposed to be for a L4D map so it had to have a bit of detail in the underside and man was it a mission.

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.

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.

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.