One thing i forgot to post (doh!) while working on the reflection setups in my engine for shadowracer was the reflectance tests i had done. I had typed an incorrect value and ended up with a super low res reflection - This and something Blindside had mentioned to me before about trying that as a trick got me into messing around with ambient color and reflectance under the diffuse layer, based on the realtime environment around the car itself. i attempted to layer the lighting setup in such a way to have a diffuse map + ambient surrounding reflectance + the realtime reflection and it looked really nice - but within certain parameters was not giving what i expected due to the nature of the reflection im using. After a lot of messing around and tweaking i reimplemented the layer for ambient reflectance but pre diffuse texture in the pipeline. This means i ran the low pass reflection on the white/blank slate car instead of the diffuse texture. This gave me even better underlying results for the reflectance and i already had an ambient texture attached to the map (a baked AO map) in the 4th slot. Multiplying adding and trying different combinations gave some cool results, so i tried using the abient map as a falloff of reflectance and fresnel and who knows what else i added for the testing phase, but a lot of really interesting results came about. Below is only one of the stages i had reached and i realised i hadnt shown any of this progress so i figured what the hell. The amount of time its taken to finish this small post in between the rest of the fun things that im working on (work side) and the fact that i had an image set already screencapped means you get one bunch of pictures. Enjoy! [caption id="" align="alignleft" width="840" caption="Reflectance of ambient scene lighting and surrounding objects"] [/caption] Some notes : the reflection and base shaders are based on my own work, but the original point i started at was BLindsides great DP realtime reflectance in irrliche engine. All shots realtime, +- 300 fps, 16x16 RTT per pass (2 passes per object) on a ATI thats not immense All images are overly exaggerated to demonstrate the effects here, a low level ambient reflectance works really well with any material, wood, metal, concrete etc etc. More sometime, i think!

OK so i fixed the wrong orientation in the reflections while i had a spare bit of time. They definitely look a lot better now, theres ONE tiny little thing left to do. Theres seaming from this technique which is normal, but for some reason theres a wrong seam elsewhere. I know where, just will take some more time to fix. For now, some better images :

Thanks to SteelStyle who write a nice HDR Image format loader i was able to throw in a quick HDR lit environment map, which i can test with and adapt easily for use in the game. Some other cool things is i keep going round in circles with the reflection. First its upside down, but the right way round. Then its the right way but horizontally wrong etc. I only tried a couple brute force values but ill fix it whenever i get around to thinking on it again. For now, some more in game eye candy.

So i went through some tests to see what was going down and i have a few conclusions. The distance the camera is from the reflection is not adhered to (i must test this in other DP examples i have) but its obvious to see below. First image was rendered in blender with raytracing, and the other 3 are in game (the reflection is not changing size at all). Ill fix this later, amusing as it is.

So i was using a modified version of blindsides realtime dual parabloid reflections for shadowracer, and it was looking quite decent while i was testing and was enjoying the look i managed to achieve. I then decided to actually take a screenshot with some other objects in the scene (this is quite a few months later) and realised that the reflection was infact completely wrong??! Something im doing is wrong but ill fix it later and ill have something new to show soon. In other areas the level art isn't going too badly, more work to be done. The reflection below shows just how wacked it is : The moral of the story is test your stuff extensively and often . Dont rely on the hope that it works in all cases.

Starting out in maxscript is easy, for programmers. Sometimes. Knowing 3d is obviously helpful, having an artist who knows about programming helps. But a hybrid, the technical artist, an artist that programs his own tools, but has enough skill to move forward with the programmers as code changes and adapts. Get learning.Some things to note : italics are programming terms. Bold is code examples, and other stuff should make sense automatically. The artist programmer, a beginning. Well lets start somewhere simple. There are some cool things you can do with max, literally, anything. Starting out can be difficult so im gonna explain piece by piece. One thing that you will use a lot of : VARIABLES. A variable stores things. Simple right? A sock drawer holds socks, a fridge holds refridgeratable (lol) objects. It makes sense that a variable has a type. There is text, numbers, and "objects","items","collections","maps". All these things are really easy to understand when its broken down. For example, a string holds text. Most strings in maxscript are referred to by string literals right? A string literal is just a bunch of words,numbers etc wrapped in double quotes. "a string" is a string where as, a string is most likely a syntax error. Variables are relatively easy to grasp. Variable = value. name = "fuzzy". location = "\models\textures". Thats all there is to it. Numbers, pretty much the same. number = 2. age = 21. ageplustwo = age + number. See what i did there? Adding variables works most of the time. Like, variable plus variable can work most times if the types are the same, or if they can work together. Like, filename = "texture".filecount = 1.newfilename = filename + filecount. The output should be along the lines of texture1. You can add to the file count, and adjust the name of the rendered texture using a plus 1 after saving to the texture1 file. If this is all confusing so far, go back and read it again lol. But the next part will have something my colleague asked for as an artist, when learning programming, Visual aid. No i lie, the next part is about the tools max gives us in max 9 (and other max versions) to edit, run and test scripts. The maxscript tools in max. There are a few things that are invaluable while testing and figuring out maxscript. There is, the documentation. Please, read the documentation when stuck. Its gibberish at times, its hard to understand but when you start seeing patterns at each interval you get stuck you learn faster.  The maxscript listener (F11 by default). This is where you can type test code and see things on the fly, test if your functions exist, ask max wtf it is doing and what not. This is also, really really helpful. The maxscript editor in version 9 sucks, fullstop. But its faster then having to keep running scripts from the utility or the menu. So running the editor and using some damn cool shortcuts. After this bunch there are some helpful shortcuts, but for now there is also, the maxscript debugger. Its not highlighted, because i dont use it much either at first. There are other cool things you can use but for now lets use these. Quick Reference Maxscript editor - Ctrl S - Save (yes, its important) Ctrl D - Fix the coloring of the text in the editor Ctrl E - "Evaluate" the code. This means it tests it, and then shows the errors in the listener or shows "OK". Maxscript Listener - Ctrl D - Clear All (so you can see wth its doing when it places things inbetween every other line) A very small start The documentation covers some very simple stuff which is nice. Im going to do the same as well, and im going to start out by usnig the maxscript listener too. Open the maxscript listener -> Welcome to MAXScript. Now that it is open and waiting we can start coding. Is it that simple to program in max? It can be. Visual aid, lets go! Max gives us functions to use. Not a very technical term, functions do a function. They can do many functions, and ask other functions to do stuff, and even give us results. This is a later concept but for now lets remember that we need a variable, and a function that gives us something. When i say, "hey make a box, and name it pancake", i can always later tell my friend about pancake's hair. Pancake is 2m tall! Ridiculous. This is what we are going to do. Storage = ask function to do something and give me a "handle" or name to reference the object im making, or item im using. "box = make a box for me","i want to make it blue", "box.color = blue". So max wants us to be all formal and use the maxscript language so lets make a box. From the documentation : "You can draw a box in MAXScript just by entering the box() command". I can see that if i type box() into the maxscript listener and hit enter, i can see a box created with default values. The box has options i can ask it to use from before its made, so i can say i want it to be 20 units high and 20 wide, 20  long. Again from the documentation : mybox = box length:20 width:20 height:20 Type that into the listener window (on a new line) and hit enter. Do it again with different sizes and see how easy it is to do certain things. note : programming refers to a "return" of a function.This simply means that max is handing me something back.If you want to use it you can, if not ignore it. The maxscript window shows some information, this is a return in the listener only and shows that the box now exists in the engine and in the code, as well as you should see a box in the viewport. Now we can set the properties of the box using its name that we filled up with , the box itself. mybox (the variable) contains the "returned" box, inside it. So i can say mybox's name should be "ArtCodeBox" instead of "box01". There are hordes of properties you will use later on , but for now we are changing its name. mybox.name = "ArtCodeBox" There, you will see the changes immediately in the window where the object name shows (by the toolbars, where the mesh wire color picker is). Concluding It seems horribly short and, rewheeling the invention. This may be true now but i want to start really slowly, and move into more advanced things later. Starting to understand programming is not the easiest thing when you are an artist. This is by no means a demeaning statement, as most programmers know nothing of art so play fair. There are tons of resources, tons of tutorials and of course, http://area.autodesk.com for a slick forums with fast responses, there is documentation and there is also, common sense. Learning comes from seeking knowledge, not complaining that the tool isnt robust enough. For a second installment, and the coming soon third part, we are going heavy into simple, fast paced programming for artists that speeds up everyday tasks. To all the artists :  Please suggest some ideas. I have some, my colleague has some, what annoying thing would you like to automate (small things for now)? Comments welcome, and of course ideas, suggestions, flames ( i can delete those, you see ). FuzzYspo0N/Sven

Using max for game development has been done time and time again. As an artist, using max is natural. As a programmer using max is powerful but hidden a lot of the time. Merging the artist and the programmer makes things simple and effective in game development. “The technical artist” is supposed to be the gap filler in this situation. In large game companies, multiple artists and multiple programmers bring a good turn around, but with the right tools the job gets easier, faster. Give an artist a functional tool and the programmer wont need to spend time a) explaining what code does, b) explaining why the tool cant perform certain tasks, and c) wasting time fixing small bugs over and over as the engine progresses. As a smaller company working together is vital. “The aspect of team comes in very handy”, is a thing of the past. The integration is crucial to making games games, and making games well. The artist, for example can flourish given the toolset he or she may require, leaving the programmer free to make the game play more game like. Keeping things tight as a team makes it fast and easy to update things. Keeping your head out of the clouds and keeping ahead of things can be difficult in the industry, but the first steps in the right direction give amazing amounts of progress, fast. This is where we have gotten to lately. An artist with a tool, that can be extended, should be given the tools he needs to make the game easier on everybody. Understanding that taking a few days to learn new things and taking a long time to figure things out comes naturally when programming, but the artist without the tool, can wait without the tool. The programmer taking 15 minutes out of the normal code to toy around with a new tool for the artists can greatly improve understanding on all levels. Once there is a familiriaty with the language, and or extension toolkits there can be massive improvements to everyones workflow . Below i outlined a couple of pointers for the two sides of the team, should it benefit you. Artist : 1) Be clear and concise. No programmer needs vague explanations and needs to figure out art jargon while programming. 2) Be reasonable. No programmer wants to spend 6 months making a tool for the game. Start small, and start simple. A toolkit is made up of many parts, massive toolkits are made from massive amounts of code. Start with automating repetive tasks. Things that will increase your workflow will slowly show you where you can grow. Show you where you can learn. 3) Be understanding. The programmer SHOULD dedicate time to you, and your workflow. In a small team this can make sense and can be easier, where as larger teams this requires perhaps dedicated technical artists but the concept remains. Give the programmer a clear, concise, simple tool addition description, and give the programmer time to work it out. Keeping in mind that the team is a team, you can do great things if you let them happen. 4) Be predictable. From the start keep things consistent. How you like things, make it clear. How you work through toolbars, make it clear. How you layout your shortcuts, make it clear. As you work further, there can be less interaction, and more working together. An understanding of who you are working with makes it easy to guess the next step. The next feature. “Working in the zone” makes it easy to program, knowing what can help and improve your artists workflow before asking, makes it faster to develop, faster to please the artist and easier to make games. Hope this helps, the next post regarding this subject will detail a few techniques in maxscript that will definately help in game development, as well as in making custom formats, or using existing formats to exploit the engine you are using. We are using torque in some cases and we use XNA for others, writing tools for Max, XSI, and other 3d apps doesnt take too long, and can make the game engine itself unbelievably easy to control content, to control art assets, to control scripting engines, to automate importing exporting, almost anything can be achieved in a short time.