Denrei's Blog

Authoring grass using normal mapping tools

denrei — Sun, 21 Jan 2007 07:54:35 +0000

I’ve been working more or less consistently on the project our main page so sparingly alludes to.

The main bits of the game come from one of Tony’s wildly elaborate and fascinating dreams mixed with Willow (the movie), Zelda64 and a mis-communication of one my brainstorm ideas at our initial design meeting.

Environments have been my focus lately. The persisting lack of an animation system makes character design feel kind of cramped and lackluster.

I once read an article about the creature fur in Black and White 2. I remember thinking it would be a nice technique for things like plants and grass and I’ve since noticed it used in games like Shadow of the Colossus in those very situations. I’m not sure what kind of workflow those guys used to create their fur and grass, but I’ve wondered about using normal mapping tools and some by-hand work to acheive the same results. Recently I went ahead and tried it out, and I think the results are pretty good for a first attempt.

The technique is plotting dots of color on many layers of transparent polygon planes. When you get enough layers and view it from a proper radius, it looks like strands of whatever. The pictures will better describe what I mean:

To create this, I started by using Maya’s PaintFX tools to quickly generate some polygonal blades of grass. I converted these to geometry shapes, and then created 18 rectangular faces of equal size stacked upon one another and evenly spaced out. The planes created a box that encapsulated the blades of grass. After laying out the UVs of the planes, I merged them into a single shape and calculated a normal map with the grass as the source mesh and the planes as the target mesh. Because I kept the search radius very very low for each face, the normal map came up empty besides where the blades of grass had intersected the faces. I then colored the UVs for each face in photoshop by had to get a gradient of dark green to white as the planes go from bottom to top. Anywhere the normal mapping tool wasn’t able to get a result I made transparent. I hope this makes sense, I kind of feel like it won’t as I compose this. Usually in the game, you’ll only see this grass from the top, so the side angles that get all split apart will be avoided.

We’ve become very elaborate and official with our project management. We use a system called “SCRUM”, perhaps you’ll be able to read up about it in Gavin or some one’s blog… I don’t understand it all too well, really. I’m just there because I have good (maybe I should just say “better”) handwriting for the index cards. I think its meant for much bigger groups working on much bigger projects, but it helps us communicate and stay disciplined about exactly what we are doing so we don’t work on all kinds of randomness forever.

RockinOutMan has been Rockin the drift trank on the PS3 demo of GranTurismo using a Logitec MOMO via USB the entire time our current project has been in development. There was a breif period where I could bank scores higher than his, but lately he has been getting REALLY good, and has hopes for the top spot on the online rankings. Currently a man named SlighteyCyrus dominates the drift boards. We hate this man, but are quite sure he lives in the apartment down the hall from us. Note the spare MOMO in the lower right.

Musculature and FF12

denrei — Mon, 06 Nov 2006 21:07:24 +0000

Chris is changing things around with how stuff gets from my screen to the game. Its all very wonderful. We have a meeting today where I get to hear it described in detail.
I’ve stopped working on Lithium stuff for the time being, and have started up a new character model. I can feel elements I’ve been learning from my drawing classes seeping into the work.
Also, I’ve found that working out at the gym has really helped my understanding of musculature, which is kind of odd to me - but I suppose it shouldn’t be. They have big mirrors on the walls and I pretty much stare at my arms contracting and expanding several hours a week. I was looking through some old torso/shoulder/arm models and found myself solving many of the reoccurring problems within minutes.

The rest of this post is about me playing FF12 and you can probably skip it.

I got Final Fantasy 12 the day it came out, but haven’t had time to play it too much yet. The characters and the look of the world arn’t really to my taste. I much prefer Tetsuya Nomura’s FF7 or FFX style. Last night I put in some solid time, and I’m warming up to it. The battle system is exactly that of an MMO, and I hate MMOs. The persistant world navigation/combat system setup is already something FFX should have done (imho), but I wish they could have wandered even a bit further from classic FF combat. Grandia III’s battle system was really cool, I wish they had taken some ideas from there.

Anyway, this is the first Final Fantasy game that I’ve actually bought even reasonably close to it’s release date, and its the first FF that I haven’t had all the plot points spoiled by friends before even touching the controller. I’m taking this very seriously. I went to my friend’s place to hang out Saturday afternoon. Knowing he had bought the game recently and had probably put in more time than I, I waited outside his door while I called him and demanded he save and turned off the machine so as not to spoil anything for me. The only sure way to do this is to just play the hell out of it as fast as I can. Which is what I suspect I’ll do.

Also, most of the music isn’t done by Nobuo Uematsu, and I feel very aware of this. Once I’ve completed the game and my self-enforced ban on consuming FF12 info outside of actually playing the game is lifted, I want to verify which songs he actually did and see if my suspicions are correct.

And I really wish I could play the game in Japanese. The trailer I saw at E3 had japanese voice actors, and they were splendid. While the english one’s arn’t BAD, every cutscene I end up thinking to myself “that probably worked better in the original”.

Lithium

denrei — Sat, 21 Oct 2006 18:25:59 +0000

Allow me to give you a short tour of Lithium’s current capabilities. The tool operates out of a main window, which can be embedded in the interface, or free floating. There are 3 sections, one for each node type (SceneNode, BoundingVolumeNode, ScriptNode). A row of buttons at the top of the window is used to create these nodes. Their initial parent, names, positions and attribute values are based on your current selection and the values you have set in the options window. For example, if nothing is selected, the BV button will create a BV at the origin using the sizes and offsets you provided in the window. If one or more SceneNodes are selected, each SceneNode will get a BV as a child, which is positioned relative to the SceneNode. If the SceneNode has geometry under it, the BV will try to adjust it’s size to this geometry. I hope to infer as much information as possible from the user, so that using the tool can be very powerful and flexible without needing tons of random buttons and options to explicitly specify.

Here we see BV nodes created on 2 SceneNodes.

Most of my work has gone into creating a system which can reference objects from other maya files. It should be tailored to level creation type work, so these imported objects need to be instanced and copied all over the place. Again, I want the user to do very little explicit specification. The interface remains somewhat primitive, but the system works just how I want it to. Rather than typing in a string for the object you want to reference, there will be a browse menu available, a “already imported” drop down thing and the like. Adding these things is relatively simple, the hardest part is deciding how to organize the information in the window set up. I think I’d like to start working hard on a game project again, and get a bearing for how I’ll end up using Lithium. Then just add things as I want them.
This is a saved maya file called “player1.mb”.

I’m going to reference things from it into a new file.

When you import an object through Lithium, it creates a reference to the requested file (should it not already exist), and hides it away. Then, it creates an instance of the elements within the file you’ve asked for, and parent constrains them to the SceneNode that requested the import. The actual instanced geometry remains hidden away from the current scene’s hierarchy, and does nothing but display itself. The idea is that when this file gets exported to the game engine, these nodes with references on them will grab objects that have been exported from other files. So if I have a city with many buildings, and each building has a ceiling fan, I can simply create a single fan and have that fan show up in all the buildings. This saves me time, and improves game performance.

Lithium makes it very fast and easy to create stuff.

Lithium makes it very flexible and easy to change stuff.

Game worlds will be built with maya files that contain basically no geometry information. There will be small files which define a specific thing, and many of those things get referenced by the level file.

ScriptNodes aren’t concerned with their world position or visual display, so this is hidden from the user. I imagine ScriptNodes will be manipulated entirely within the Lithium window. These are very game specific, so I don’t have anything besides their interface behavior defined yet.

Madison IGDA Chapter

denrei — Thu, 05 Oct 2006 17:36:49 +0000

Stolennotebook recently attended the brand new Madison chapter of the IGDA. (btw the “I” stands for International, not Independent). It felt kind of similar to our E3 visit, we gained insight into the industry and met the real flesh and blood folks behind the scenes - which ended up kind of depressing.

In some ways, it was really exciting to be able to just mill around and talk with people who do this stuff for real. At the same time, it was very apparent that many of them lacked the same… energy about making games we have here at stolennotebook. In an episode of Creating Kaos, Damon Grow has a similar meeting with other local game developers where several of the interviewed professionals refer to themselves as “paycheck programmers”. This strikes me as really lame, and completely contrary to everything I’m about with regard to game making. Paycheck programmers belong at Intel and Sun, not game studios. The crew we met with had much of this same lameness about them.

One element I had correctly predicted was the sheepish attitude of the artists. They seem to have tasks thrown at them by people who are technically proficient, and just kind of do as they are told. I was asking all kinds of questions about the creative process in their studios, and I was mostly met with confusion. “They tell me to make a box, so I make a box.” type thing. There is not much that is artistic about the artist’s job, it seems. I’ve known for a long time this is the kind of environment game makers work in (American game makers, at least) but its still kind of alarming to see someone who’s aesthetic sensibility has been consumed so completely by it.

And so my vigor as an independent game maker is renewed.

Cookin with Lithium

denrei — Mon, 18 Sep 2006 22:48:10 +0000

I’ve been making progress on my MEL level editor system. Things have been slow going for many reasons: I’m back in school now, many of my friends have returned to Madison… but more than this I’m a stinky coder. One of my strengths as a member of this team is an ability to get really consumed by a project, putting in every spare moment just because I really love what I’m doing. This current stuff is definitely interesting, edifying and worth while, but I can’t seem to get the kind of momentum which I usually depend on to allow me to work quickly. Never the less, my progress has been consistent. I’ve got a simple GUI with little icons and such to execute what I’ve written so far. The automated process of importing and cataloging external files is complete, with a small particular problem I have yet to resolve.

Most of my time is spent exploring and testing many different ways of approaching the same task, to find the one which is most suitable. Maya is extremely open ended and forgiving in terms of allowing you to tackle a problem however you are most comfortable. This is excellent when you just want to automate a single task (which is how I’m used to using MEL). However, when your system gets deeper, it becomes imperative to do things in ways which are more or less harmonious with Maya’s core design philosophies. By this I mean storing particular types of information in the ways Maya likes it to be stored, organizing things how Maya likes things to be organized. MEL has tons of tools and functionality available, and its important to keep your work compatible with what already exists. I have a pretty solid idea of what I want to end up with, which has been very helpful for planning how things should work now.
As I mentioned, this work is edifying and an important step, but I am already very much itching to get back to just modeling and making stuff.

Oh, I named the system “Lithium”. I hope nothing similar is already named that. A few quick google searches suggest not. Wikipedia explains that lithium can be used to fight mania, depression and bipolar disorder (I’ll mention here that I personally have strong problems with any kind of mind/mood altering supplement such as anti-psychotics in all but the most extreme cases). It can be a component in channeling/harnessing large amounts of power, as in lithium batteries or thermonuclear weaponry. It is also a catalyst for chemical reactions.

Lithium does not create simplicity out of complexity, but offers a different way of experiencing complexity which is easier for a mind to deal with. When given the proper situation it can take silent, dorment forces and empower them to many times their original potential. This is all rather dramatic for a couple of amature MEL scripts, but with Maya as my katamari, I intend to keep it rolling and growing as my tools change, and will eventually collect all the elements of my workflow.