CG Sketchbook , notes and tutorials

Top Hand Rodeo

I worked from july to october 2010 on this project by PerpetualFX for PS3 network .

I did some of the environment art (the 3 full environments below )

The engine was Gamebryo , i worked mostly in Blender (base modelling and texturing , some background animation)

Then assembled the scene in 3dsMax, made the gamebryo shaders there , baked light in vray , exported , set up realtime lights and some postfx in editor.

W.I.P. PICTURES AND NOTES :

.

.

.

.

.

_

It all started with blocking out the envs :  we had realworld refs this time , but no env. concept art (as in previous Galactic Bowling titles)

That meant quite a bit of planning and designing , below are some images i made to coordinate with the team and get feedback.

.

.

.

.

.

_

This was my first project with ‘modern’ shaders: and current gen consoles , Wii and Iphone games had many limits on shaders , and even PC versions of Galactic Bowling did not use anything more than diffuse color.

So i did some test objects to practice with normalmaps and speculars ,  mostly done in Blender GE using the GLSL shaders: that gave a good preview , i only checked the finals in Gamebryo Viewer.

More of these test objects are covered in last years posts  here

Right image is a BI still render , with notes and questions to the team to get right the design of a realworld cattle chute.

.

.

.

.

.

._

Ground and fences : those 2 required a lot of attention : they’re always seen close up , and take most of the screen.

The arena fences:  UV reusing / space economy was quite important… i made a somewhat extreme decision to set up a texture with fairly few ‘patches’ of worn metal :

These are used for the panels (and fit those exactly) and all tubing and frames (those ‘fit’ only partially with scratches and weathering only on some corners and the ends), with only a small patch for special pieces (hinges).

This means a lot of discontinuous seams,  but the uv space economy is huge, so the final resolution of the map is very high.

That meant getting a sharp and detailed fence , and nobody would really see or care the seams on the back or inside of tubing.

The ground shader: was initially done with blendmaps : 1x 1k control map using rgb channels to blend 3 heavily tiled textures with different sands and dirts .

Worked beautifully: high detail , lots of variations , small texture size , but we couldn’t get that custom shader on ps3 , and the workaround took some time : The final shader took many iterations both technically and on the artistic / texture paint side.

Fortunately the base game material had many slots to multiply and overlay maps , with different tilings to get detail while keeping mapsize low.

The hardest aspect was that realworld arenas look varied and detailed (of course..) but it’s basically all just the same kind of sand !

So you need to be quite accurate to reproduce that in cg , it’s much easier to reproduce a terrain with some pebbles , rocks , grass , plants..

It took quite a few attempts : At some point, i translated our bump map (used for normal or parallax in game ) to a mesh sculpt in blender to get the shape of the dunes nice and realistic.

Seemed an exageration at first .. thinking that wouldn’t make things better , but it did .. sometimes the solution is not a new method or better idea ..it’s just going crazy on the details and polishing what you have..

We used baked lightmaps: (from Vray , with GI ) set to multiply , using a secondary uv channel.

Needless to say , that was much better than baking the light in the diffuse (as in Galactic Bowling), since we could resue uv space heavily and use generic tileable textures while keeping the lightmap unique for almost every point in the scene.

This was a sports game so the env were not too big :  an arena , a fixed env  , and not i.e. a fps where you move through many rooms in a sequence. (that simply means bigger, heavier envs..)

That meant that the lighmaps could be quite detailed : enough to contain GI (blurry low frequency detail ), direct light (average) , but also AO.

By  ‘AO’ in lightmaps i don’t mean  the basic self-occlusion AO you can put in diffuse maps , i mean  highly detailed GI maps , done in Vray  , where all scene objects are considered.

Here it was possible ,but after all i don’t think it is a good practice : if you limit the lightmap to GI and shadows , much lower frequency details,  you can get away with much smaller maps.

Then you can use realtime SSAO , and i think that would prove more efficient and performing (..if the hardware is modern enough)

In the end ..a very complicate subject : the lighting quality you can get today in lightmaps is incredible (though it depends a lot on hw texture memory)

But on the other side, nowadays there are more and more realtime shading options , of which SSAO is already proven and reliable .. and maybe soon GI will be too.

And if you think realtime GI is a huge waste of performance : indeed it is , really huge : but a huge time gain for developers :  baking takes a lot of time to setup ..

And even then .. you have env artists jumping in terror at every design change  🙂 sorry .. can’t help with that : at some point when bakes are done even a small change implies hours of rendering and updating assets )

All in all , making games is hard : in particular moving from low-specs hardware to all the possibilities of a high-end hardware , wasn’t that much fun .

Sure, first thing you think of the fancy stuff you can make and the artistic possibilities , but it takes complex pipelines , technical people setting up not just the build of the game but also scripts for the art tools , it takes time to test and experiment with performance issues .. which aren’t at all simple and predictable as in low-specs hardware.

Advertisements

Comments are closed.