Lost in the triangles

Blog moved

2007-03-25T20:02:00.000+03:00

I moved my blog to my own website. It is now at a new URL: aras-p.info/blog. If you have used FeedBurner feed to read it, everything should point to new blog now. If you've been just browsing the website, or have used Blogger's builtin feed, go to new URL from now on. This blog will not be updated anymore.

ARB_vertex_buffer_object is stupid

2007-03-22T23:51:00.000+02:00

OpenGL vertex buffer functionality, I mock thee too! Why couldn't they make the specification simple&clear, and then why can't the implementations work as expected?

It started out like this: converting some existing code that generates geometry on the fly. It used to generate that into in-memory arrays and then Just Draw Them. Probably not the most optimal solution, but that's fine. Of course we can optimize that, right?

So with all my knowledge how things used to work in D3D I start "I'll just do the same in OpenGL" adventure. Create a single big dynamic vertex buffer, a single big dynamic element buffer; update small portions of it with glBufferSubData, "discard" it (=glBufferData with null pointer) when the end is reached, rinse & repeat.

Now, let's for a moment ignore the fact that updating portions of index buffer does not actually work on Mac OS X... Everything else is fine and it actually works! Except for... it's quite a lot slower than just doing the old "render from memory" thing. Ok, must be some OS X specific thing... Nope, on a Windows box with GeForce 6800GT it is still slower.

Now, there are three things that could have gone wrong: 1) I did something stupid (quite likely), 2) VBOs for dynamically updated chunks of geometry suck (could be... they don't have a way to update just one chunk without one extra memory copy at least), 3) both me and VBOs are stupid. If I was me I'd bet on the third option.

What I don't get is: D3D has had a buffer model that is simple to understand and actually works for, like, 6 years now! Why ARB_vertex_buffer_object guys couldn't just copy that? The world would be a better place! No, instead they make a way to map only whole buffer; updating chunks is extra memory copy; there are confusing usage parameters (when should I use STREAM and when DYNAMIC?); performance costs are unclear (when is glBufferSubData faster than glMapBuffer?) etc. And in the end when an OpenGL noob like me tries to actually make them work - he can't! It's slow!

Back from Seattle

2007-03-17T23:13:00.000+02:00

Just got back from MVP Global Summit 2007 in Seattle. Among usual things, like watching Bill's keynote, meeting other MVPs, DirectX/XNA guys, getting a grip of some NDA information and such, here are some of the other highlights:

Amsterdam airport:

Officer: You speak English sir?
Me: Yeah.
O (takes a look at my passport): Ah, you speak Russian of course!
M: No, not really.
O: But your language is very similar to Russian, right?
M: Hm...

Well, here we know who gets the Linguist of the Year award.

Seattle-Tahoma airport, lady at checkin: "what kind of passport is that?". It also takes 5 times to enter my last name properly, from the printed letters in the passport. Each time trying to persuade me that I did change the ticket date of course!

Seattle-Tahoma airport, security: "sir, you have been selected for additional screening". Do they randomly select people for that quite involved process? Why this "selection" happens immediately after they take a look at my passport?

Random quotes:

Ten minutes walk is a long distance! Ten minutes of walking distance in the States is a very good reason to buy a car. At least SUV; preferably a Hummer.

DirectX SDK is the source of all sorts of high frequency goodness.

Sony is always good at announcements.

No? Rumours on the internet? Shock! Horror!

A day well spent (encoding floats to RGBA)

2007-03-03T18:33:00.000+02:00

Breaking news: sometimes seemingly trivial tasks take insane amounts of time! I am sure no one knew this before!

So it was yesterday - almost whole day spent fighting rounding/precision errors when encoding floating point numbers into regular 8 bit RGBA textures. You know, the trivial stuff where you start with

inline float4 EncodeFloatRGBA( float v ) {
  return frac( float4(1.0, 256.0, 65536.0, 16777216.0) * v );
}
inline float DecodeFloatRGBA( float4 rgba ) {
  return dot( rgba, float4(1.0, 1.0/256.0, 1.0/65536.0, 1.0/16777216.0) );
}

and everything is fine until sometimes, somewhere there's "something wrong". Must be rounding or quantizations errors; or maybe I should use 255 instead of 256; plus optionally add or subtract 0.5/256.0 (or would that be 0.5/255.0?). Or maybe the error is entirely somewhere else, and I'm just chasing ghosts here!

What would you do then? Why, of course, build an Encoding Floats Into Textures Studio 2007! (don't tell me it's not a great idea for a commercial software package! game studios would pay insane amounts of money for a tool like this!) The images here are exactly that - render into a texture, encoding UV coordinate as RGBA, then read from that texture, displaying RGBA and error from the expected value in some weird way. Turns out image postprocessing filters in Unity are a pretty good tool to do all this. Yay!

Sometimes in situations like this I figure out that graphics hardware still leaves a lot to be desired. This last image shows some calculations that depend only on the horizontal UV coordinate, so they should produce some purely vertical pattern (sans the part at the bottom, that is expected to be different). Heh, you wish!

There's more than one me out there!

2007-02-18T16:23:00.000+02:00

I had an interesting story recently, but was waiting for gamedev.net to be back up&running again. So...

One day I got an email like "Hey Aras, where are you we need to finish up our project soon". Ok, I don't know who is the sender, know nothing about any project I should be "in", and the sender's email address does not match the signature, so I just marked it as spam and forgot about it.

A couple of days later Paulius forwards me a message from the same sender, saying that he can't reach me, the project has a deadline soon, so he started looking through nesnausk.org and write to other people out there.

I still thought this is some advanced new form of phishing!

I check the website from the signature of the sender. It's a real website; a bunch of people developing (or trying to develop) a MMO game. In the "technology" section of the website was a link to in.out.side demo: "this is a techdemo of the engine we developed". WTF!?

Contacting the original email sender revealed all the story, which is quite simple in fact. They were looking for a programmer and found someone posting on gamedev.net forums, saying he has done in.out.side demo that won Imagine Cup 2005. He presented himself as me (with a slightly altered name) and agreed to work with them. How is this thing called by the way? Identity theft? Some time passed, in my understanding they haven't ever seen any code from that guy, and then he just disappeared.

What makes it funny though that the guy never received any money from the job he was supposed to do either. I could understand reasoning behind presenting oneself as some other guy, taking the money and then running fast - but presenting oneself as someone else, doing nothing and getting nothing in return? Does not strike me as a viable "business plan"...

The moral? Never trust anyone online, especially if they are from Lithuania :)

Getting political (Iraq)...

2007-02-18T14:49:00.000+02:00

Watch this now. 'nuff said.

What's wrong with this code?

2007-02-01T11:49:00.000+02:00

Here's a short function:

inline int SecondsToEnergy( float time )
{
return FastFloorfToInt( time * (float)(1 << kEnergyFixedPoint) );
}

It's used in the particle system, and converts particle lifetime to an internal fixed point representation (10 bits for fractional part, i.e. kEnergyFixedPoint=10).

Some of the emitted particles are okay on a Mac, but completely not visible on Windows. This function is to blame.

Of course, what's wrong is the possible overflow in float-to-int conversion. Whenever someone tries to use lifetime longer than about 2097151, the conversion to signed 32 bit integer is undefined. It seems to clamp result in gcc and produce something like -1 in msvc.

Using multiple compilers can be hard, but it can also help in finding obscure bugs. Ha!

Wii or spirit of evil

2006-10-04T13:56:00.000+03:00

Watched an old Russian film Viy yesterday. Is it just me, or is the pronunciation strikingly similar to one console that is coming out soon? Wii or Spirit of Evil!

Quote of the month

2006-10-01T18:41:00.000+03:00

At work the other day:

Jesus says: use the debugger!

A steam of random things

2006-08-14T00:24:00.000+03:00

Awards: Hey, we've got a "runner up" award in Apple Design Awards 2006, Best Use of Graphics category! Yeah, a runner up is more like "the first of the losers", but oh well. Got beaten by modo 201, which probably is a fair trade. It's just that we thought we'd be in Best Developer Tool category, but that is apparently for text editors and scripting languages :)

Demos: In the other news, fellow ReJ with TBL just won Assembly 2006 demo competition with an Amiga demo, putting all PC demos faces' to dust. Check it out. Art direction over hardware capabilities, one more time.

Drivers: why oh why the graphics drivers must be so bad? The other day I was thinking why can't they auto-update themselves (with an option to turn it off for corporate users etc.). Now you've got a (not so recent!) driver that is able to parse vertex programs wrong, and a user who does not have a clue that he should update it. It's bad enough to have a bug in the first place, but auto-update at least would fix...

Or you have a driver that says "I'm OpenGL 1.2!" but the 3D texture functions are null. And it's the most recent driver for a particular graphics card that you can buy today! And it's not even a hard problem! What the developers are thinking - they go over the required GL 1.2 functionality, see that some is actually missing and decide "ah, screw it, we'll say it's 1.2 anyways"?!

I just don't get it. I could use some enlightenment on this.

Painting and wallpapering

2006-07-27T16:08:00.000+03:00

We repainted our living room and did one wall in wallpaper (real actual ones, not for the desktop). This is fun but takes a couple of days to get done, half of that time spent moving stuff outside the room and moving it back afterwards.

One thing I learned is that painting with semi-glossy paint is very different from painting with matte one. Semi-glossy is very sensitive to paint strokes, pressure and a lot of other things, and if you're not extremely careful you'll get a wall that looks like with a varying gloss or specular power. Of course, varying specular exponent would be cool in a shader demo of 2001, but it's not a cool thing to have on your room wall. And it's not 2001 anymore either!

After that we just went for a week to Crete. Here's an assortment of small random pictures. Now back to work!

A day in the life...

2006-07-06T01:38:00.000+03:00

Ok, as mcpunky asked to say something in more detail, I have no choice but to log a day of my work. Bear with me.

10:30 - I come to work. Peter is already here and wants to show me the shader-related project he's working on. It is becoming really cool by now, we discuss the projects, shaders, lighting, BRDFs and all the other stuff that graphics programmers always talk about.

10:55 - I turn on my work machines, read mail, check our forums, bugtracker and sales statistics :) Update code/website from Subversion. Review website changes of yesterday.

11:35 - Checkout new bugs reported to me. This day we have three of them. Some shaders don't display correctly for one user on his laptop; checking it, replied asking for log files now. Webplayer crashed on win2000. Checkout the crash dump, it's in Mono initialization; flag the bug for later review on actual win2000. One more: windows build loses the very first keystroke. Launch Visual Studio, build debug player. By 12:10 I have this bug found, fixed and checked (was an error in handling lost DirectInput devices). Commit into svn, merge into Unity 1.5.1 branch as well.

12:15 - Launch build of 1.5.1 branch on my PC, meanwhile I'll install more RAM on the windows build machine (it clearly needs it). Fifteen minutes later the release build is done and I have the RAM installed. Start debug build, do some small stuff on the laptop.

12:40 - Nicholas comes to discuss our strategy for handling per-vertex lighting with custom shaders of Peter's project. Fixed function T&L and custom shaders that don't care about vertices or pixels just don't merge well together. Maybe we'll have to reimplement the fixed-function vertex pipeline equivalent in vertex shader(s). Might be hard to get right, especially on some lower hardware.

13:05 - Lunchtime! At this time of year it's almost mandatory to eat outside. So nice. After lunch I watch a demo deities by mfx for some inspiration. Ah, I so want to do that.

13:45 - Joe comes in, shows some cool stuff one customer is working on. We discuss some glow filter issues.

14:00 - Philosophical talk about our unit/functional testing strategy. We do quite some functional tests now, and a tiny amount of unit tests. I'd like to try some unit tests on shader parser (which I'll have to refactor someday soon, and without unit tests I'm scared). Agreed that unittests are probably a good thing if you strike the right balance (now THAT was a surprise, huh?). Will try.

14:30 - Checkout a whitepaper from ATI about fixed function emulation in HLSL, playing with their shader. Instruction counts are scary! Talk with Nich about glow improvements, he has some good tips.

15:15 - Put a GeForce into my PC - will try to figure out why in some cases graphics looks too dark on them.

15:25 - Again comes Nicholas, more talk about this shader thingy, regular additive pixel passes vs. ambient passes vs. vertex lighting and how the actual end user should not care about these details. We found a nice solution it seems; this way shader authoring seems intuitive (or at least much more intuitive than the other alternatives we considered).

15:50 - Back to darkness-on-geforces issue. On the way I found out that motion blur filter no longer works on a PC! Reverting to older versions from svn to find out where I did introduce it. Ok, that was a stupid typo by me from several days ago, fixed.

16:35 - David opens a shoe box - and surprise surprise - there's a cake and cookies inside! Good stuff. Me loves anything that's sweet.

16:45 - The darkness-on-geforces is only the motion blur filter going wrong. That's good. Debugging with glIntercept, something's wrong with blur accumulation texture.

17:10 - D'oh! The motion blur had a pretty crappy implementation; was trying to render into the texture while using itself as the input. Obviously the results can be undefined, which just happened on geforces. Rewriting the filter to do it properly. Testing it, integrating into standard assets.

17:45 - Discuss our (i.e. company) roadmap and which parts of it can be announced publicly :) Then the talk went downhill about memory management, fragmentation, per frame allocations, porting Mono to some exotic architectures, whether porting runtime to Direct3D or kind-of-OpenGL-but-not-quite would be easier (my take is that porting to D3D would be easier) etc. Did something else which I don't quite remember because we couldn't have talked for an hour, right?

18:50 - Making some tweaks to the glow filter to look nicer in some cases. Done except the Radeon9000 path. I guess that's enough for today, now again check our forums, email and will go home.

19:30 - I actually leave home, it's some 20 minutes away on a bike. The plan is to eat lots of grapes and watch a movie tonight. What turned out is that I read some papers and then did the plan.

Overtall, it has been a day with quite much talks. Not exactly the day where you feel "hey, I've done a lot of stuff today", but not bad either. Will be ok for blog purposes I guess.

On work and clean code

2006-07-01T15:28:00.000+03:00

It's been like 6 months of me working on Unity. So far so good. We've done a big new release recently, so after some pre-release insanity we're a bit more relaxed. I guess not for very long though, we have more stuff planned than we can handle :)

It sure feels nice to work on an actual software product. I think it's probably the first time in my carreer that I know people are using my work and I do care about that. Having worked on projects before, it's very different - a project just comes and goes, and once it's finished you never think about it again. And most of the time you don't care about "the clients" that much either. Working on a product is much more rewarding (especially if the users seem to like it).

Another interesting here is that we are a very small software shop. So everyone has to be a one-man-army (the others certainly are, not sure about myself). Design, program, fix bugs, decide on features, do support, write docs and even do html tweaks for the website. Of course, it could be Jack of all trades, master of none (*), but somehow I feel that we are managing pretty well. And I like to be involved in various aspects of making a product.

(*) though wikipedia says that the full saying is Jack of all trades, master of none, though ofttimes better than master of one - which looks like a positive thing to me.

A completely different theme: when programming, it's always good to massage the code you're working with a bit. Remove unneccessary #includes. Write a comment on tricky code block. Fix warnings. Do small refactorings. Remove unused code paths. It does not take much time and helps to keep the codebase clean. Removing unused code is especially good - for some reason I love removing code. Could do that all day long; probably I'm some kind of anti-programmer :)

Windows on a Mac experience

2006-06-01T21:47:00.000+03:00

A post on GrammerJack blog made me post similar impressions about Mac vs Windows etc. So:

I was the evil guy to install Windows on my MacBookPro (via BootCamp) as well. That was like a month ago. The thing is, I think I haven't booted into windows for like 20 days on this machine. At first I though gee, I'll use VisualStudio on this machine, will watch demos and have a proper Subversion client! But I use VisualStudio, watch demos and have a proper Subversion client on my work PC, so there are not that many reasons to boot windows on the laptop...

Plus BootCamp has small annoyances that GrammerJack mentions: no two finger scrolling (it's the best thing in laptops I've ever seen), no backspace key, function key not supported, the machine never seems to come to proper sleep (i.e. it's always hot to touch), trackpad sensitivity and precision much worse than on OSX etc.

And in general, I must admit that I kinda like OSX. "It feels nice" would be my best attempt at explanation, for I can't think of any serious reasons why I like it. Well, yeah, the UI is nice etc. Mind you, I like Windows as well, but at least on this laptop, OSX "feels much nicer".

Now if only Apple could throw the bunch of crap called XCode away and make something like VisualStudio+VisualAssist; and if only OpenGL would be so sweet to use as D3D! I'd jump on OSX bandwagon immediately and be a happy man. Alas, XCode is just lighyears behind (*).

(*) Though Apple has some really cool development tools as well (Shark etc.)

Back to some shader programming

2006-05-24T20:14:00.000+03:00

There is something magic in programming shaders. Like, when you edit one of our standard shaders and save, say, nine instructions in it - the feeling is really good. Maybe because, well, it's a standard shader - so that means everyone's graphics will actually render faster. Nice!

Maybe it's because shaders are such a short piece of code, without too complex dependencies... I'm sure anyone who knows graphics hardware will corect me here, but let's oversimplify and pretend that shaders actually execute in a simple way... So when you make a shader shorter, you pretty much know it's going to be faster. When you make it "look better", it almost certainly will look better. Try doing that in your regular big codebase - by optimizing something you may break something else; and in general you have no clue what to optimize unless you do your profiling homework. So, my take is that shaders are much simpler, so the joys of looking at assembly output actually make sense.

So, yeah, I'm back to some shader programming.

It's always unexpected

2006-04-20T19:22:00.000+03:00

I have a MacBook Pro now and slowly am getting used to it. It's quite hard, considering that I've never had a laptop before; and actually used any Mac for the first time just a couple of months ago. My daughter thinks the best part about it are the weird image effects in PhotoBooth. I just can't disagree.

On the unrelated note, now I am a Microsoft DirectX MVP. Just about the time when I almost stopped using it! I'd love to, but we're making a product that primarily runs on the Macs... quite hard to use D3D there. But almost every day I wish I could, and every second day I'm annoying my coworkers by saying that D3D is lightyears ahead of TheOtherAPI!

The MVP award just came out of nowhere. It's one of the things that you never expect - but hey, it feels good anyway. And now I have a MVP laptop case for my MacBook :)

OOP and other things now and then

2006-04-20T12:49:00.000+03:00

Approximate conversation at work the other day:

Yeah, I split this into separate files, removed this and made these classes to make it actually work.
Ok, but don't go too fancy with objects here.
Sure! I think it's the only place where I actually use inheritance!

Heh. I'd imagine how that would have looked back some 5 years ago. "What design patterns did you use here?" etc. Funny how things change.

I think I've got it by now - took me way too much time for such a trivial thing - there is no silver bullet. OOP or any other buzzword is just a means to do something; sometimes it fits, sometimes it does not. Regarding OOP, I highly recommend Execution in the Kingdom of Nouns essay - it's way exaggerated, but has the point. The best part:

advocating Object-Oriented Programming is like advocating Pants-Oriented Clothing

There is one thing about the codebase that we have at work that I love: it does not use any particular design/programming technique. A bit of OO, a bit of metaprogramming, a bit of plain C style, a bit of preprocessor macros, etc. I like to think that we're using the best of those worlds, of course :)

Threading woes

2006-03-27T11:20:00.000+03:00

Getting multithreaded code right is just so damn hard. Reasoning about it's behavior or correctness is even harder! We'll be doomed until we get something of much higher level than threads and locks.

Why I'm writing this? Because my head hurts from trying to make the renderer run in one thread, and the containing application in the other. With added spice that most (win32) GUI stuff must happen in one thread, OpenGL contexts can only be active in a single thread, simple functions must be split into complex chains of inter-threading calls, etc. etc. The result is a mess that nobody can understand.

I hope I'm not missing something obvious (well, aside from the suggestion "just don't use threads").

Why doesn't this feature exist?

2006-02-27T18:08:00.000+02:00

Found this quote from Raymond Chen today (here):

The answer to "Why doesn't this feature exist?" is usually "By default features don't exist. Somebody has to implement them."

It's not like every feature you can think of comes out of your brain fully tested and implemented, and then some PM somewhere files a bug to have your feature removed. Features start out nonexistent and somebody has to make them happen.

So brilliant.

The holy grail of shadows

2006-02-18T22:45:00.000+02:00

It just occurred to me: it seems that noone has ever made a shadowing system that does shadows from anything onto anything, with zero artifacts, with no corner cases, always looking good, running fast and on any sensible hardware.

Hm... sounds like a challenge! ;)

Back to reading.

Pair programming / animations

2006-02-15T11:40:00.000+02:00

Tried out pair programming the other day. I can definitely see it working, especially on hard topics (i.e. where you spend lots of time thinking, explaining, arguing and brainstorming that just typing in code). I am still not sure whether it really suits for "ordinary" day-to-day programming though.

The topic I and Joe tried it on was a pretty hard one - related to the core animation system. Now, of course I don't know anything about animation systems, but my impression is that there is just no "universal" way of designing it. The ones that are floating around inside free/open engines/libraries (cal3d, nebula2) are quite fine, but not much more impressive than my own very simplistic attempts at doing animations. There is nothing wrong with that of course - its simple, it gets the job done, and its okay in most of the cases when you're doing simple stuff.

But then, if you want something more advanced, you either have to go and get the big serious libraries, or just... well... not do it.

So, back to pair programming - making the core animation system that would have transitions, continuous blends, animation layers, bone masks and whatnot (and the kitchen sink of course!) is just not very easy. We paired basically on writing the pseudocode of the system, or some sort of outline; changed the implementation several times along the way, and in the end we're left with a really nice and fast system and the code is actually quite simple. Much of the credit for that goes to Joe, as he found out some really cool ways to optimize the expensive things away (at that time we were not doing pair programming anymore - I went to do some research on shadows!)

But to reiterate - pairing can definitely work. I guess mostly because the other person just keeps asking "why you're doing this?" or "this is wrong" or "we're in a deep shit now" or "that's awesome" :)

Switched jobs - (almost) back in this crazy industry

2006-01-10T20:55:00.000+02:00

Switched to the new job recently. So here I am, sitting in OTEE office in Copenhagen, working on Unity game development tool. Not exactly game development, but quite related. So far so good, will see how it goes. If you haven't yet - take a look at Unity, it is good and will only get better.

Zen bondage!

2006-01-03T10:52:00.000+02:00

Check out a small game by demogroup Moppi: Zen Bondage.

Zen Bondage is a puzzle game about control. The
motivation was to try to make a puzzle game which
evokes adult emotions.

However, it fails to evoke any "adult emotions" in me. Maybe I'm just not into this bondage thing :)

I like the simplicity/pureness of the idea, and it's executed very well.

64k coding continued

2005-12-23T18:58:00.000+02:00

I'm making a steady, but very slow progress on "my" 64k intro. Over the last week I couldn't get over 13 kilobytes, so you can see that the progress is really slow. Not because I don't code anything, but all code increase was cancelled by data size optimizations.

So far coding and data design for small sizes is not that much pain at all. Just, well, code and, well, keep your data small :) We're only talking about the size of initial data, not the runtime size though.

A few obvious or new notes:

Code to construct a cylinder is more complex than the one to construct a sphere. That's what I expected. However, code to construct a box with multiple segments per side is the most complex of all!
Dropping last byte from floats is usually okay. And instant 25% save! For some of the numbers, I plan to switch to half-style float (2 bytes) if space becomes a concern.
Storing quaternions in 4 bytes (byte per component) is good. Actually, now that I think of it, it makes more sense to store three components at 10 bits each, and just store the sign of 4th component - better precision for the same size.
This intro literally has the most complex and most automated "art pipeline" of any demo/game I (directly) worked on! I've got maxscripts generating C++ sources, custom commandline tools preprocessing C++ sources (mostly floats packing - due to lack of maxscript functionality), lua scripts for batch-compiling HLSL shaders, "development code" generating .obj models for import back into max, etc. It's wacky, weird and cool!
Compiling HLSL in two steps (HLSL->asm and asm->bytecode) instead of direct (HLSL->bytecode) gets rid of the constant table, some copyright strings and hence is good. (thanks blackpawn!)
Getting FFD code to behave remotely similar to how 3dsmax does FFD is hard :)

The best thing so far is that I've got the music track from x_dynamics - it's already done in V2 synth, takes small amount of space and is really good. Now I "just" have to finish the intro...

Speculation: pipelining geometry shaders

2005-12-22T14:06:00.000+02:00

A followup to the older "discussion" about how/why geometry shaders would be okay/slow:

The graphics hardware has been quite successful so far at hiding memory latencies (i.e. when sampling textures). It does so (according to my understanding) by having a looong pixel pipeline, where hundreds (or thousands) pixels might be at one or another processing stage. ATI talks about this in big letters (R520 dispatch processor) and speculations suggest that GeForceFX had something like that (article). I have no idea about the older cards, but presumably they did something similar as well.

I am not sure how the vertex texture fetches are pipelined - pretty slow performance on GeForce6/7 suggest that they aren't :) Probably vertex shaders in current cards operate in a simpler way - just fetch the vertices and run whole shaders on them (in contrast to pixel shaders, which seem to run just several instructions, then go to another pixels, return back, etc.).

With DX10, we have arbitrary memory fetches in any stage of the pipeline. Even the boundary between different fetch types is somewhat blurry (constant buffers vs. arbitrary buffers vs. textures) - perhaps they will differ only in bandwidth/latency (e.g. constant buffers live near the GPU while textures live in video memory).

So, with arbitrary memory fetches anywhere (and some of them being high latency), everything needs to have long pipelines (again, just my guess). This is all great, but the longer the pipeline, the worse it performs in non-friendly scenarios: pipeline flush is more expensive, drawing just a couple of "things" (primitives, vertices, pixels) is inefficient, etc.

I guess we'll just learn a new set of performance rules for tomorrow's hardware!

Back to GS pipelining: I imagine that the "slow" scenarios would be like this: vertices have shaders with dynamic branches or memory fetches differing vastly in execution lengths - so GS has to wait for all vertex shaders of the current primitive (optional: plus topology) to finish; and then each GS has dynamic branches or memory fetches, and outputs different number of primitives to the rasterizer. If I'd were hardware, I'd be scared :)

Reading DX10 docs...

2005-12-16T19:58:00.000+02:00

Reading DirectX10 preview documentation right now (you know, it's released with Dec2005 SDK). It is pretty impressive, I must say! Seems like a huge leap forward. Back to reading!

Pakimono!

2005-12-10T14:01:00.000+02:00

(the lack of updates recently is because I have lots of stuff here going on)

I few weeks ago I was visiting OTEE and over the weekend we were jamming on a small game called Pakimono! The idea of the game was pretty cool - you're the naked guy and have to ruin tourists' photos :)

The whole experience was great. It was my first time using a Mac, first time working with Unity (their game development tool) etc. I coded&tuned most of the bullet-time character controller, where you drag your limbs with a mouse, trying to cover as much of the sight as possible.

The coding was a bit unusual - most of my coding life I was doing pretty low-level C++ programming. This time it was completely different - I'd setup "the game" directly in the editor, write some short C# scripts and boom! - everything works, without me having to worry about any of the low-level stuff. No recompiling or any of that stuff. Cool.

Ironically, I did not see the final Pakimono build yet. I left earlier than the others and do not have a Mac anywhere nearby. But the guys promised me a windows build!

Lost Garden

2005-11-08T09:21:00.000+02:00

Lost Garden is good - about game design and related things from (ex) Anark guy (hi Chris!). E.g. this one (a practical definition of innovation in game design):

And if you ever hear an indie game developer talking about level design, either shoot them in the head now to help them avoid their future misery, or direct them towards this essay.

A crazy thought: 64k intro

2005-11-03T19:49:00.000+02:00

I was planning to do a demo this year; all by myself (except music). However, after playing with Blender a bit it became clear that I am really not a 3D artist (not Blender's fault, of course) - what a surprise :)

Now a crazy thought: do a 64 kilobyte intro instead?

Yeah, I know, one pretty unsuccessful try already was there 3+ years ago... But still: I need a musician that could use Farbrausch's V2 synth, some clever ideas/design/code and there it is. There's a hope that I have actually learned something in these 3 years, you know :)

By the way, this bzhykt intro produces really abstract visuals on my computer right now. Something was messed up in there...

HDR with MSAA demo

2005-11-02T13:52:00.000+02:00

Released this HDR with MSAA demo I was talking about earlier. Here it is: nesnausk.org/nearaz/projHDR.html. I can also add that this St. Anne's Church is a pretty complex beast :)

More HDR woes

2005-11-02T11:09:00.000+02:00

I'm still spending an occasional minute on my HDR demo. Now, everything is fine so far, except one thing: I can't get MSAA working on some Radeons (and I don't have a Radeon right now, which makes debugging a lot harder). The main point of my demo is to have MSAA on ordinary hw, so this is bad.

The reason seems to be that on older Radeons MSAA does not resolve alpha channel, which obsiously messes things up in my case. I'm using RGBE8 encoding for the main rendertarget, and it RGB gets MSAA'd and exponent not - then oh well, no good anti aliasing most of the time.

Of course I could always manually supersample everything, but this would defeat the whole point of the demo. Or I could render everything in two passes, one for RGB and one for exponent - but this also is not very nice...

Probably I'll just release the demo as it is now and wait for possible feedback. Or dig up an old Radeon somewhere and debug more - but replacing the video card in my Shuttle XPC is not an easy task :)

Debugging plus

2005-10-26T08:30:00.000+03:00

Yesterday I had a cool debugging session while working on my HDR demo. One of postprocessing filters produced weird results and I went off to investigate that. The usual tricks: debugging in Visual Studio to make sure right sample offsets are generated; D3D debug runtime, D3DX debug, reference rasterizer, firing up NVPerfHud and doing frame analysis, doing full capture with PIX and inspecting device state, etc.

Nothing helped.

Then I noticed that in the pixel shader, I wrote

sample = tex2D( s0, uv + vSmpOffsets[i] )

instead of

sample += tex2D( s0, uv + vSmpOffsets[i] )

Aaargh. So much for a plus sign.

How to deal with such bugs? Why some bugs are trivial to find, and some are hard? Why sometimes (often?) the time required to find the bug does not correlate with bug's "trickiness"? Why sometimes I can find a tricky bug in big unknown codebase in a couple of minutes; yet spend two hours on the plus sign in my own small code?

I've got no answers to the above.

By the way: PIX is a great tool, but D3D guys should really polish the UI :)

Jumped onto HDR bandwagon

2005-10-23T19:54:00.000+03:00

I'm doing a small HDR demo for fun. Nothing fancy - linear gamma, Reinhard's tone mapping and whatnot - everyone does that. But the thing I made so far does not even look good! :)

I'm trying to support both HDR and FSAA at the same time on ordinary DX9 hardware (no Radeons 1k) by using RGBE8 rendertarget for the main scene. It's all okay so far.

The most difficult task right now is making it look good. Once I have that I'll post the results.

Bought Rag Doll Kung Fu

2005-10-13T18:52:00.000+03:00

Like I promised :)

It ownz, period.

Listening

2005-10-06T11:36:00.000+03:00

Headphones on, winamp alternatively playing The Jupiter Sound and Four Themes and a Masterplan by Little Bitchard. Just the right kind of music for asp.net coding. At least the music is good :)

An article on efficient D3DX Effects state management

2005-10-03T12:38:00.000+03:00

I wrote an article on the subject I was talking about recently - an auto-magical system that manages device states in the effects. The article and links to implementation are on my homepage here: nesnausk.org/nearaz/texts/d3dx_fx_states.html

Rag Doll Kung Fu

2005-09-27T18:52:00.000+03:00

I saw Rag Doll Kung Fu website already a while ago. However, only today I saw the video of it's presentation at GDC. It's awesome! Will buy the game as soon as it appears on Steam (even if I don't play games).

Go to downloads section at the site and get this large video presentation. It's really good.

State management in D3DX Effects #2

2005-09-27T18:46:00.000+03:00

I've written down the basic idea here. Done some tests and it really seems to work!

That required tiny 700 lines of hacky C++ code in the engine; but in exchange there's no longer a need to write state restoring passes by hand. Maybe such effect usage scheme would even be useable in RealWorld!

Too bad I didn't think it up a couple of months ago. My ShaderX4 article about this subject would have been much better...

Ok, still got to test this stuff on real world data (i.e. trying it on our demos)

State management in D3DX Effects

2005-09-24T18:45:00.000+03:00

In my projects I've been using D3DX Effects with no device state saving/restoring. Instead, each effect contained a dummy "last pass" that restores "needed" state (see here; more lengthy article coming in ShaderX4).

I always wrote this "state restore" by hand. This is obviously very error-prone; it's ok if I'm the only one writing effects but would be unusable in any real world scenario.

I think I could automatically generate the "state restore" pass. Somehow the engine knows which states need to be restored; which must be set in every effect etc. (this could be read from some file). It first loads each effect file and examines what states it touches. This can be done by supplying a custom ID3DXEffectStateManager and "executing" the effect - the state manager then would remember all states (left-hand sides of state assignments) touched by the effect.

Then the engine generates the "state restore" pass and loads the effect again. I'd image it would do it like this: each effect has to contain a macro RESTORE_PASS:

technique Foo {
 pass P1 { ... }
 pass P2 { ... }
 RESTORE_PASS
}

Which would be empty during first load and which would expand to the generated restore pass on the second load (you can supply generated macro definitions when loading the effect). The engine can check whether the generated pass exists after second load (if it doesn't then RESTORE_PASS is missing from the effect - an error).

The downside of this scheme is that each effect file has to be loaded twice - first time for examining its state assignments and second time for actually loading it with the generated restore pass. It's not a problem for me, I guess, because effect loading doesn't take much time anyway... And if it would become really slow, all this stuff can be done as a preprocess (e.g. during a build).

There are many upsides of this scheme, I think: the whole system is robust and error-proof again (no longer depends on the effect writer to remember all the details about states). And as far as I can see, no performance would be lost at all (performance was the main point why I'm using this "restore pass").

Gotta go and implement all this!

Dingus redux at Pilgrimage'05

2005-09-21T09:11:00.000+03:00

Richard "legalize" Thomson (the organizer of Pilgrimage demoparty and DirectX MVP) just told me: he has done a 2-minute analysis of our demo engine dingus as a "wild demo". It took 3rd place in wild demo competition at Pilgrimage'05!

That is pretty funny. I never knew it has so much sourcecode inside! :)

C++ clunkiness

2005-09-19T20:42:00.000+03:00

Here I am coding various things and it suddenly struck me: C++ is pretty clunky. Now, I knew this to some extent for quite a time already, but the more I code C++ the more clunky it feels.

I admire it as a low-level language; it's very powerful and there's lots of unbelievable things you can do with it (think templates).

But still, it feels like a low-level one. I really want to code by "next project" (whatever that might be) in Lua, for example (especially now that LuaJIT is out).

InteraMotion closes offices

2005-09-14T19:57:00.000+03:00

The company I was working at for some three years, closed it's offices in Kaunas recently. Well, it was almost a year when both intera and motion parts of the name didn't already make any sense... At start we were doing computer vision, various game/graphics/entertainment stuff, but in the last year all development was about some computer networks management system. A couple of programmers will stay for some time to support existing systems, but afaik any new development is suspended.

I feel kinda sad, even if I blame the management for the failures mostly (we programmers never blame ourselves, you know :)). Yes, I/we could have worked harder, done better etc., but all the way I (and probably 'we') felt that the ambitions were too unrealistic^*, the business plans were too non-existant, the management was just a bit too poor, and some forward-thinking was 'just a bit missing'.

I guess that's just my attempt to transfer blame to someone else :)

That said, it's still sad. Oh well, just keep going on.

* Ambitions: "by that time Sony, Nintendo and Konami will be years behind us" doesn't sound very realistic, does it? :)

Project Hoshimi 2006

2005-09-01T20:54:00.000+03:00

Work has really started on the next version of Project Hoshimi for Microsoft. We've got to:

Add eye candy, whatever that may be. They say we can ditch some old harware (DX6 level), but methinks we can't go really wild ("minimum ps2.0" would be cool, but not in this real world). We've got to add some particles, transparent blood cells, lighting fx etc. Anyone has some ideas what could be easy to implement and look extremely cool? :)
I can't say much, but it's about network, client-server etc. Time to learn some network programming for me!
The guys behind whole this thing have some really insane plans that would rock the christ child if they would really happen. Not a high probability of them happening though...

Ok, back to thinking about possible eye candy and the network protocol.

The Escapist

2005-08-31T11:04:00.000+03:00

The Escapist is a good read from time to time. This time, it's Greg Costikyan:

And actually, EA tried to kill The Sims many times before it was finally released. From what I've heard (and this is definitely hearsay), Bing Gordon's comment at the meeting where publishing was approved was: "Well, it'll only sell a hundred thousand copies, but it'll get Will off our backs."

We're only talking about the best-selling PC title of all fucking time.

Gee, I'd want all magazines to be like this. Focused, to the point and without trivial crap that most of them are 99% full of.

Doing something

2005-08-30T16:09:00.000+03:00

After taking a break, I already want to do something programming-related in my free time. What should I?

The standard thing: do a demo. I have some ideas (LT) for that, but for various reasons I'm not in the mood right now to start a big/long project.
Read some books. I'm doing this a bit.
Learn something. Do something with wxWidgets or some Lua-only programming, but didn't start anything yet.
I already should do something related to the next version of Project Hoshimi for Imagine Cup 2006. I'm trying to!

On the unrelated note, I'm doing a Oracle and XSLT related project at work. While Oracle stuff I'm dealing with really sucks, XSLT isn't bad at all. Sure, it's not "programming" that I'd love very much, but the whole concept is very powerful.

Maybe XML isn't such a bad thing afterall, especially once you start doing funky things with XSLT and XPath. I still love the quote "XML is a giant step in no direction at all" though :)

Software of the week

2005-08-23T18:45:00.000+03:00

It's never too early for Software Of The Week awards, even if it's only Tuesday. Ladies and gentlement, Aras' picks are:

Software That Rocks award goes to TortoiseSVN and PmWiki. Both are slick, sexy and do not try to annoy you. They actually work (that's already something!), they do not crash whenever I do just-a-bit-non-usual action, they do not corrupt my files behind my back.
Software That Sucks award this week goes to Oracle Reports and Designer 10g. Sorry dear Oracle, but the best description I have for those is "Ugh". For a longer description, just invert everything that's written in the first point.

See you later!

Guns & games

2005-08-11T10:25:00.000+03:00

The comment on the blog entry here is great:

38% of Americans own game consoles. Around 40% of Americans own guns. The gun lobby is damn powerful. We shouldn't need anywhere near as much money as the gun lobby, because unlike games, we are absolutely, 100% sure that guns actually do kill people.

What's in the engine?

2005-08-09T15:53:00.000+03:00

As always, here's a thought that's more about demo-engines than about game-engines; and mostly dealing with graphics stuff.

Some folks add whatever gfx effects/techniques they use to "the engine". Quote from Plastic:

We've also added a couple of new features like <...> wireframe/particle shader.

Now, I don't have a problem with that, but what strikes me is that for whatever reason our engine doesn't have any effect/technique in it. Zero shaders, no shadowmaps/PRT/refractions/whatever.

The obvious disadvantage of our approach is that for each demo I basically write the shaders and "effects" from scratch (ok, copying them is also fine). There's no central place where, for example, a Gaussian blur postprocessing filter or shadowmaps rendering code is stored.

On the other hand, that means (nearly) complete freedom for each demo. In each prod I can tweak whatever I want and implement completely different rendering techniques. For example, in.out.side demo is quite different from Visual Gaming viewer or Xplodar FEM demo, yet they all share the same underlying "engine" (read: bunch of code).

Still, what I'd like to do is have "somewhat stable" stuff gathered in one place. I don't tweak my basic lighting functions, standard postprocessing effects or shadowmap sampling patterns that often :)

Back #2 - tiny photos from Japan

2005-08-07T16:54:00.000+03:00

Left to right, top to bottom: The fractal house on our way from Narita Airport to Yokohama. Visual Gaming competition in action - hey, it's the 3D viewer I wrote! Paulius in the ferri wheel - demo or die. Me showing our demo before the dinner. The wistful photo - me looking at the horizon. Yokohama - we were here.

Back!

2005-07-26T22:27:00.000+03:00

I'm back from Turkey. That's me somewhere in the Mediterranean sea, practically showing that refraction really works - note the double hand and the mermaid-like legs :)

Right now - finishing my ShaderX4 article and preparing for Japan.

One totally insane 64 kilobyte intro: 195/95/256 by rgba. Of course, first you have to see the original 195/95 demo by Plastic. The 64k intro copies the (party version) of the demo almost perfectly, while squeezing everything in less than 64 kilobytes. Ok, the music sucks, the loading time is nearly infinite and it has lots of bugs/glitches, but I must say that rgba guys are insane anyway.

Vacation!

2005-07-13T21:43:00.000+03:00

I'm going off to Turkey for a week (vacation). Then, I'll go to Japan for a week (ImagineCup finals). Will see how it goes; should be pretty cool I guess (well, the air will most likely be hot, not cool).

Press releases and other noise

2005-07-08T12:18:00.000+03:00

Ok, seems like Microsoft Lithuania issues some PR about ImagineCup and our demo in there, and now every news portal in Lithuania catched it.

Now, its pretty standard in a sense that from the PR itself noone could understand what it's about. The "rendering competition" is translated into something that means "the competition of presenting ideas"; and the demo is described as a "CG short film". And, of course, the usual press-like exaggerations: "competed with 17000 students and took 1/2 place" - which is obviously wrong as 17k is the total number of students; in the rendering compo there was probably something like 100.

I don't like it (the press); it's just a noise that distracts you. Meh.

One funny thing: yesterday I received a call into work phone from one local PR agency. How the hell do they get this information? They know my name and university (it's in the press release) - how do they find out where I work and more, how do they get my phone number? I mean, even I don't know my work phone number (ok, I could find it out if I needed)!

Immediate mode GUI

2005-07-08T09:59:00.000+03:00

It's already advertised somewhere else, but I'll add it as well: Casey Muratori has an amazing lecture on Immediate Mode GUI. I like the idea, and while I think IMGUI mostly applies to realtime UIs (in-game, editors etc.), this is a good read (er... watch) for any UI programmer.

I was subconsciously heading towards that UI style as well; drawing and processing some UI "immediately", though not at the level Casey does.

Some new books

2005-07-07T14:49:00.000+03:00

Received GPU Gems 2 and A Theory of Fun from amazon today. The first one I bought because hey, I need it; and the second one because it's (relatively) cheap and seemed like a good read. Indeed it is - it's a great thing to read!

Reading Siggraph 2005 papers...

2005-07-04T11:28:00.000+03:00

I'm reading Siggraph 2005 preprint papers that are nicely gathered here. Some of them are really amazing! What I'm impressed with so far:

Texture Montage: looks cool. Just made me realize how primitive the "usual" texturing tools are... It makes me want to create some texturing tool...

LDPRT and Local PRT are steps in the needed direction for precomputed radiance transfer. Though Ignacio says that CPCA compression of SH is patented my M$... Bah!

Relational Debugging for the Graphics Pipeline is like NVPerfHud on steroids!

Reading on...

Mesh seamless texturing tool released

2005-07-01T20:11:00.000+03:00

Finally I've put the MeshTexer tool online, with some documentation, the tool itself and some sample data. Basically, it takes a mesh with unique UV mapping, a normalmap and a tileable texture, and "wraps" the texture (nearly) seamlessly onto the given model. Well, the truth is that it just projects the texture onto the model from several sides, weighting by normal.

However, it worked like a charm during in.out.side demo production. Paulius has written whole texturing workflow here - the tool was used to generate base material textures, material blend maps, gloss maps etc. Later these were hand-painted in "strategic" places and combined into final textures.

Enjoy!

On some demos

2005-07-01T15:59:00.000+03:00

Watched some new&old demos in the last couple of days. Here (when there's a link to Lithuanian page, the 'download' looks like 'parsisiųsti'):

Rapid Eye Movement by Matt Current. Now that's unreal; technically simple but excellent composition and creates a very strong feeling. The similar feeling I only remember from The Planet by mfx. Also, I think the concept of "rapid eye movement" (i.e. the phase of the sleep) is done very well. I want to (be able to) do this!

Aether by mfx. The first time it didn't leave me very impressed. However, I recommend watching it for the second time. Fascinating, though I can't say what exactly.

Old ones with a very strong music: A Significant Deformation Near the Cranium by kewlers and Coma (on the dance floor) by Cocoon. I want that music :)

Japan, here we come

2005-06-29T10:08:00.000+03:00

The results of ImagineCup05 rendering compo were finally announced!

The best thing of course is that our demo in.out.side: the shell took the 1st/2nd place (a tie). That means that both winning teams will go to the finals in Japan at the start of August. The final winner will be somehow decided there.

That's going to be pretty interesting, methinks. We've got the 2nd place last year; the other winning team got the 1st place last year. This year, the same teams meet again, but it's still not clear which one will win. Cool.

I wonder how the winner will be decided. Will we need to to some "presentation" (techniques/algorithms/workflow/hacks used)? Maybe there will be an additional "fast demo" competition (e.g. make a new demo in 1 day)? Interesting. Waiting...

While waiting for ImagineCup results...

2005-06-27T16:09:00.000+03:00

Aargh, the ImagineCup crew postponed the results announcement again (that is, 3rd time already)! First it had to be on June 13th, now it's scheduled for Real Soon Now, Really!

Meanwhile, I'm doing a game that surely will revolutionize the whole gaming industry, blah blah etc. That is, a letter learning game for my daughter; in Lithuanian. There are lots of these (example), but the problem is that they're in all languages except the one you need.

Now, the most obvious implementation would be in Flash. Alas, I don't have Flash authoring tools nor do I want to learn them and it's ActionScript. I thought about going Lua+SDL all the way, without C++ at all. Guess what - SDL doesn't have any high level audio playing stuff; I'm too lazy to bind it's sdl_mixer to lua; there's no nice IDE and there were lots of other obstacles. So I just went and am doing this in C++, abusing our demo engine. Oh well, I'm just lazy.

While implementing it I found out that I have no good tool to pack lots of arbitrary images into nice power-of-2 texture atlases. nVidia's Texture Atlas Tools do almost that, but they rescale textures to be power-of-2 (which is usually ok, but not for my case). So I just had to fork the AtlasCreationTool (just SVN link for now) to do what I want. While at it, I removed it's dependency on D3D sample framework (hey, removing code is always good!), forced it to support non-pow-2 textures and to pack them better. It's probably not that good for the usual case (where you want to place textures at block boundaries in the atlas to minimize mipmap artifacts), but packs arbitrary sized images pretty nicely. Yay!

Various

2005-06-25T10:39:00.000+03:00

I've got my Master's diploma. I feel like nothing has changed, probably so it is.

We have a pretty unreal orchid in our house. I bought it 8 months ago, and it's been blooming all the time. It's even getting bigger and bigger!

Casey Muratori:

God, no wonder games are so hard to make. The tools are such complete crap. Some day there's going to be a tools revolution and one guy will be able to make the equivalent of today's $10 million games. There's no doubt in my mind.

Demo engine to game engine

2005-06-13T15:56:00.000+03:00

A Pilgrimage 2004 talk by Tom Forsyth. Good points captured.

How to be creative

2005-06-13T15:41:00.000+03:00

Another day I stumbled upon this: how to be creative. Overall it's good; although a bit too long and most of the content is quite common-sense. A good read anyway.

That reminds me: the other day I was thinking about a strange feeling in the town where I live (Kaunas, Lithuania). Basically, whenever I see a group (three or more) of young guys (20-25), most of the time they seem to be aggressive and angry. I don't get this feeling in the other towns/cities; I don't really know what's causing it. Maybe it's several bad experiences I had. Some of my friends have this feeling also, so it can't be just my problem.

I wonder why people are agressive at all. I mean, what's the point in insulting/pushing/beating a random walker-by? Is that the only way they can express or "feel" themselves - through invoking fear or pain on the others? Maybe; another day I read Jean-Paul Sartre's "The Childhood of the Leader" (L'enfance d'un chef) and maybe that's the case - when a person can't find "himself" he starts doing weird things.

Still, why there seems to be so many of them?

Demo engine website

2005-06-08T16:34:00.000+03:00

Ok, I've released sourcecode for our demo engine/tools and the demo itself a while ago, now time to actually put up at least a minimal website, with some articles, download/build instructions and whatnot.

So, here it is: http://dingus.berlios.de (oh, and it has an rss feed of the recent changes, yay!).

Currently it's half empty; I expect to write some more short articles soon. Maybe even put up some standalone tools... I know that the sourcecode is useless, but I thought "maybe the articles would be good". Or maybe not, who knows.

3D engine design redux

2005-06-03T19:26:00.000+03:00

On the other hand - maybe it's the way to go. You're designing the engine around some specific technologies and approaches, to be used in some 2-3 years.

That way, when fancy water reflections go out of fashion and are replaced by fancy waxed floor reflections, you'd throw everything out and restart from scratch. Predicting that this moment will occur only in the next console transition (hey, cur-gen can't handle fancy waxed floors!).

Pretty reasonable I think, in 2-3 years it's likely that the things will be changed in non-trivial way, so you'd need to rething and possibly remake some parts of the technology anyway.

3D engine design

2005-06-02T10:29:00.000+03:00

I'm reading API docs of one "really advanced" modern 3D engine (found them publicly available on their site, don't know if that's an error or not :)) and... it's a strange feeling. Basically, everything's hardcoded!

By 'everything' I mean that, for example, possible shadow algorithms are hardcoded in the very base classes of the engine. Same for physics, lights, scene management, culling etc. Similar like you'd have a class VeryBaseEngineObject and that would have information "what shadows are on me?", "am I physics body", "cull me against the camera" and "render me for the water reflection".

Huh? Is that how all engines are designed? You have functionality like "shadow map", "a physics crate", "a fancy reflective water" and "a fullscreen glow with light streaks Masaki Kawase style" in the core of the engine? I'd understand if that would be as helpers or some "premade" stuff on top of the core engine... but having that in the core? Why?

Is that what constitutes a "flexible" engine?

Demo released!

2005-05-30T14:23:00.000+03:00

The demo I and some friends were working on in the last 5 months (spare time) is finally released. Heck, it even has a website: www.nesnausk.org/inoutside! Now waiting for results from ImagineCup...

I've been watching it too long to have any objective opinion. Some outsider comments are here. Enjoy!

The new chair

2005-05-30T14:16:00.000+03:00

Got this new computer chair from Paulius for my birthday. The one where you're half-kneeled while sitting on it (some say it's good for your back). It's a bit strange at first, but overall pretty cool. After a week of chair-testing I'd say it's good. My daughter there doesn't sit properly :)

It all depends on the way you look

2005-05-25T16:09:00.000+03:00

Yesterday Paulius put screenshots from UE3 and our demo next to each other, wrote "right!" and "wrong!" over the corresponding shots and we realized that we're basically screwed.

In the evening, I tweaked lighting and contrast, made some lightmaps and hand-drawn the other lightmaps.

In the morning, Paulius took new screenshots and put UE3 screenshots next to them. Then he wrote "WTF?" over UE3 ones and "world domination!" over ours. Suddenly we realized that maybe it ain't that bad afterall.

Conclusion: it all depends on what's written over the screenshots :)

Demo nearly finished!

2005-05-24T16:18:00.000+03:00

(me back at work after three days of 12+ hour work on the demo)

Nearly finished the demo, gave testing builds to several people. I'm already sick with it and can't judge it objectively. My wife says that demo lacks colours (true), lacks action (partially true) and other things - but probably she's already sick with me doing the demo.

The other people say various things. Well, too late to change everything; I feel a bit bad - we've invested so much time into this and it looks pretty bland (i.e. when you compare screenshots of our demo and UnrealEngine3, one of them looks clearly better :)). Now it all depends on what demos will the other teams make.

On the efficiency side, it's doing pretty well. I didn't bother writing fallback effects for anything lower than ps2.0 hardware (that was great!). Our low-end-target (something like 1.5GHz CPU and Radeon 9500 64MB) the demo runs ok at lower resolutions (800x600). On our 'recommended' hardware that ranges from Radeon 9800s to GeForce 6800s the demo runs well; FPS counts are 60-120. Haven't tried on any of the 'top' video cards. Two people said it doesn't run on GeForceFX; one effect does not get validated - that's bad, looking at the effect I can't tell what's the problem and don't have anything from FX series at hand.

Funny enough, the demo manages to run reasonably well even when it's severely unoptimized!

Work, work, work

2005-05-22T18:38:00.000+03:00

Demo demo demo! Beware!

We still have a chance to finish it on time. I've taked a day off the work tomorrow and want it to be really finished by tomorrow evening (or night). The real deadline is after 4 days, but I've got to test it on various hardware...

It's going pretty well, I think. It works, other team members say it looks pretty good (myself - I'm not sure, I think I've been watching it for too long). Does 100-150FPS on my GeForce 6800GT at 1024x768 with some FSAA. Again, we're under-utilizing the available hardware :)

Back to work.

24 / deadline's near

2005-05-20T15:08:00.000+03:00

It's my 24th birthday today, yay!

On the other hand, I won't "celebrate" (whatver that means) it now, maybe after a week. The deadline for ImagineCup demo is just around the corner, and my todo list still contains lots of stuff...

Dilemmas

2005-05-18T09:10:00.000+03:00

Sometimes you must make decisions that clearly affect your whole foreseeable future in a significant way. Here comes the really unexpected though: making such decisions is hard! :)

Improving UV mapping skills

2005-05-16T18:09:00.000+03:00

Hey, UV mapping the second human-like figure took me much less time than the first one! This one took about 1 hour, again in Blender (and again, marking seam edges, LSCM that and just arranging resulting pieces rocks).

That said, making the low-poly mesh from the high-poly one took much longer than UV mapping; something like 4 hrs. A good artist would probably make a new mesh from scratch in shorter time, but hey, I'm not an artist :)

Ambient occlusion takes ages to compute!

2005-05-13T12:38:00.000+03:00

Really. Three hours for a model at 1024x1024 and 5x supersampling!

Now I'm using ATI's NormalMapper to compute normal/AO maps (Previously was using nVidia's Melody, but switched for no obvious reason). The good thing with NormalMapper is that it comes with sourcecode; I've already sped up AO computation about 20% by capping octree traversal distances (that took less than an hour). I suspect with some thought it could be optimized even more.

Previously I was using a hacked solution - compute normal map with either tool (that doesn't take long), then use my custom small tool that does low-order GPU PRT simulation on low-poly normalmapped model with D3DX. Get the first term of results, scale it and there you have ambient occlusion. I was thinking it produces good results, but in the truth is that 'real' AO maps look somewhat better, especially for small ornaments that aren't captured in low-poly geometry.

The good thing about this hacked approach is that it takes ~10 seconds for a model (compare to 3hrs). Using it as a quick preview is great, and the differences between hacked-AO and real-AO aren't that much visible once you add textures and conventional lighting.

I'm thinking about doing GPU-based AO simulation on the high poly model, with quick-n-dirty UV parametrization; then just fetching the resulting texture in normal map computation tool (afaik, Melody can do that natively; for NormalMapper it would be easy to add I think). With recent DX9 SDK such tool should not take more than 200-300 lines of code (D3DX has both UVAtlas and GPU PRT simulation now). On the other hand, I know that nVidia guys are preparing something similar :)

Update: added image - on the left is hacked-n-fast AO, on the right is real-AO. Ornaments inside aren't present in low-poly model (only in normal map). Differences are less visible when the model is textured and other stuff is added.

Working efficiently

2005-05-12T10:36:00.000+03:00

Sometimes I work for 8 hours with almost no results. Sometimes, I can do much more in 3 hours.

Things that help me (examples from IC05 demo): write down a detailed, roughly prioretized task list. If I don't write it down and keep tasks in my head, I often spend too much time polishing not-so-important features. With task list, I update it constantly; at the same time I get sort of 'summary' of remaining work.

Another one: really concentrate. Turn off music (for some reason I can't work while music is playing... especially if the music is good, I start listening to it), close the doors, tell the child 'go play with mom instead' :), etc.

More: disconnect from the net while working :)

A translation problem

2005-05-05T17:32:00.000+03:00

An interesting problem: I'm writing my Master's thesis and have tough time translating smoothie (from Rendering Fake Soft Shadows with Smoothies) and skirt (Smooth Penumbra Transitions with Shadow Maps).

Both thanslate into weird stuff!

Master thesis weirdness

2005-04-23T22:12:00.000+03:00

Writing thesis at the university is weird, you have to write 50 pages of poo just to present 5 pages of useful information. Introductions, overviews, previous works, aims, hopes, discussions, explanations of unrelated stuff etc.

I have a temptation to put a small picture of some dragon or a naked chick :) somewhere inside just to test if anyone really reads that crap.

Engine/demo sourcecode released

2005-04-22T09:47:00.000+03:00

So I went and put the sourcecode of our engine and the current (in progress) demo at BerliOS, so far only the Subversion tree (browse it online here).

The 'engine', called dingus (don't ask me why :)), is the one that was born for LTGameJam2003, based on some previous experience and insights from people more clever than me. Variations of it were used in all 'serious' nesnausk! demos so far, and in my personal projects as well. The sourcetree at BerliOS has no exporters/tools commited in yet, that will be at some later time. Of course, no real documentation is written for the engine.

Besides the engine, there's ic2005 project that's, well, the sourcecode for our WIP demo for ImagineCup2005. No art assets in any form are committed in, sorry :)

At some later time I'll put the sourcecode for our other demos/projects as well. Maybe.

Update: mesh and animation exporters for 3dsMax added to svn. Other tools pending.

Content shoveling

2005-04-21T09:34:00.000+03:00

We're going into heavy crunch mode to finish our ImagineCup demo on time. The demo alone would be nothing, but when you add up TheRealWork, master's thesis, the demo and some sleep, you quickly run out of hours available during the day. Take one out of that, and it's manageable :)

Anyway. I feel kinda strange about the direction our demos are taking. Much like the game industry, we're going the 'content shoveling' way. Paulius' first 'serious' demo, Demo 612, was low in content amount on purpose. Our other demo, The Fly, already had some content; programming part was already the minor one.

In this demo, I project that we're putting 5x more effort than into 'The Fly', and something like 90% of the total effort goes into art content (models, textures, animations etc.). It would better look good in the end! I once thought that for some reason we 'raised the bar' so much that it's hard for ourselves to jump over it.

This kind of scares me. The overall trend is that with each demo we're doing much more content, while the 'code' part remains pretty constant in size/complexity. What's coming next? Will we need 5 artists working for 5 months just to make a demo?

After this demo, I want to take the usual 2-3 month break; and then try something different. Something more abstract, with more intelligent code and less massive art content. I admire kewlers very much - somehow they are able to make great demos 'out of nothing' :)

A demo that still fascinates me

2005-04-20T11:04:00.000+03:00

Been thinking about how we should synchronize the visuals and the music in our demo... So I went and watched some of the classic demos, paying some extra attention at how they do it.

Synchronization aside, the demo that still touches me very deeply is Gerbera by Moppi. It's old (2001) and already starting to show it's age visually, but the whole mood, 'storyline' (whatever that is), the tiny writings and the music is fascinating.

Directions makes us unable to choose our paths. Wonderful.

Animation blending for walk/run

2005-04-09T20:48:00.000+03:00

I've done some very basic walk/run animation blending. The results are pretty neat!

We have several walk animation cycles, each for different walk/run speed. Now I can smoothly move the character at any speed, and the right animations are selected, synchronized, mixed; and the walk is mixed in/out of another animations.

As a basis I've taken Tom Forsyth's talk from GameTech2004 and Charles Bloom's rambles (dated 3-13-03). Of course, our case is somewhat simpler (e.g. we don't have manpower to author all turn left/right, accelerate/decelerate, etc. anims).

Try it yourself - it's good! :)

BTW, I was thinking about putting our full engine/tools/whatever somewhere, in case anyone is interested or maybe would find it useful. Well, I know, the naked sourcecode is not useful at all in the real world, but still :)

Geoff Zatkin's essay

2005-04-05T11:19:00.000+03:00

A must read article for any game developer wannabe here:

Your industry heroes work like dogs too. Ask a Blizzard employee what their "core" hours were for the last year+ before WoW launched. Or a Bungie employee leading up to Halo shipping. And those are the lucky ones. For every studio that turned out a brilliant game, multiple other teams of equally cool people ended up wasting years of their lives working on games that never saw the light of day, came out stillborn or got pushed out early and died an ignominious screaming bug-filled death.

Don't even get me started on the core work hours for Japanese studios.

How sad, and how true...

I once wanted be a games programmer

2005-04-04T19:43:00.000+03:00

Some 6-8 years ago I'd think hey, games programming is all I want to do. Right now I'm more on the "let's see" side.

One thing is: I don't really play games. Last time I seriously played a game was, like, 7 years ago (IIRC). Some of the modern games I've see seen or tried a bit are HalfLife2, Doom3, DungeonSiege, GTA3 and... that's all! Wanting to be a game developer when you're not really interested in games would be pretty weird, right?

Right now I'd think that my main interest is (realtime) computer graphics. I know that sounds pretty familiar - everyone starts from doing rendering engine - but hey, I'm still interested in CG now, and my first attempt at it was ~9 years ago, a mosaic-drawing-program on ZX Spectrum...

Would I want to work on a game? It depends. I don't really like the current state of the industry at large; and working on something that's not directly a game (like at IHV, or middleware, or research) would probably be more interesting.

I guess that's why I'm trying not to work fulltime and leave some time for demoscene and similar stuff. Ok, my daughter has got the scissors somehow and now is trying to cut some books. Gotta go :)

Oh no, it's a banana hotel!

2005-04-04T17:16:00.000+03:00

Boring3D is back with new semi-daily images. That stuff rocks the christ child.

The phrase in emphasis is invented by Casey Muratori :)

Sleep. Repeat.

2005-03-30T02:52:00.000+03:00

3:00PM. Last 8 hours frantic game progamming, before that 6 lazy hours at work. Must submit my work tomorrow, but the result looks really bad. Perhaps it was a big mistake.

Now: sleep, get up at 7:30, eat, ciao to daughter&wife, go to the gym, go to work, work, eat, edit demo storyboard for a break, work, shop, go home, play with daughter, browse a bit, guitar a bit, eat, wife comes home after 12hrs of teaching, we're all tired, talk a bit, sleep. Repeat?

Sleep.

Not dead yet!

2005-03-29T11:33:00.000+03:00

I'm not dead yet! :)

A pretty busy time it is. Real actual work at work (!), writing "storyboard" for our ImagineCup demo (required, deadline April 1st) and that game I'm working for as a contractor. I wish there were less jobs at the same time, right now I'd sacrifice the game work...

On the good side, looks like my demogroup has won the scene.org award for "breakthrough performance" (that means "best newcommer of the year" or something like that). I wasn't at the awards ceremony in Breakpoint'05, oh well. Maybe next time :)

Why the demoscene matters / Why we suck

2005-03-17T13:41:00.000+02:00

GDC2005 is over now and everyone's crazy about Will Wright's Spore (see GameSpy or Gamasutra), it's procedural content generation etc. Heh, the demoscene still matters :)

On the other hand, we suck. Our to-be-done demo will have what: normal mapping, AO, shadowmaps, postprocessing fx; all the stuff that everyone and their grandmother has. It's like lens-flares and envmaps some years ago. We're as innovative as a coffee cup.

k, back to work...

Demo progress: I'm morphing into an "artist"

2005-03-17T13:37:00.000+02:00

I'm slowly becoming a non-programmer. I'm UV-mapping the meshes, welding the vertices, exporting and importing back and forth and computing normal/AO maps. I'll probably even go and code some procedural material shaders in the next couple of days. That's weird, nobody's doing real programming at the moment; the code part is seriously lagging behind.

We should have had (is that proper English?) the wall fracture+physics by now and some of the interactive mode character controls (animation blending etc.). Alas, none of that right now.

In the picture there's a fragment of wall decorations and it's object space normal map (just to add more colors). The texture, gloss map and some real lighting isn't there yet.

Blender: first try; UV mapping

2005-03-06T20:35:00.000+02:00

Tried Blender this weekend. Well, long story short: I'm totally impressed!

The long story is this: for our demo we need normal mapping, ambient occlusion and similar stuff. Now, these do need unique UV parametrization of the models. The sad facts are: 1) 3dsMax sucks at automatic UV unwrapping, 2) nVidia's Melody, which I use to compute normal maps, also didn't impress me with it's auto-UV calculation much, 3) our 1 and a half of the "artists" are really busy doing models and animations.

That leaves me, the humble programmer, at the task of calculating normal maps / ambient occlusion, with the "minor" task of getting good UV parametrization from wherever it's possible.

I knew that Blender has got LSCM unwrapping some time ago (does any of the "real" 3D packages has got it yet? Hellooo? :)) and decided to give it a try.

And I must say it rocks. 3dsMax keeps irritating me all the time (it's good that most of my tasks are/were writing exporters). Blender is small, slick and the workflow seems to be much more efficient.

Given my nearly non-existent "UV mapping skills" I've unwrapped a pretty tough character model (see images - mapping such fingers ain't easy) in something like 4 hours. I guess with a little practice, I could get that to 1-2 hours. This probably isn't impressive for a real artist, but hey, I've been doing nothing but writing keywords, identifiers and semicolons for the last 8 years :)

Ambient occlusion

2005-03-02T21:21:00.000+02:00

Ambient occlusion is really cool. Yeah, precalculated occlusion for animating objects is fake, but with some hacks it's still very cool. Why I didn't use it before? :)

Here, a small shot comparing no-AO with AO (super small because it's still work-in-progress, I'm not sure if my teammates would be very happy with me showing big screens :)).

Ah, at the bottom there are "my" soft shadows that I've written about earlier, but nothing can be seen in such a small shot. Oh well; shadows will be the story for another day.

Code dependencies

2005-02-26T16:17:00.000+02:00

They suck! Well, this probably isn't fresh news to anyone, but right now I'm working with code where basically everything includes everything else. The code is template-heavy so that makes things even worse. Try changing that file without 20 minute rebuild later - good luck!

Yeah, I know, the code is a product of 2 years of wandering in the darkness :) - prototyping, adding something and removing something, and when you constantly have to actually produce "working demos" in short timeframes, it ain't easy to actually sit down and refactor whole thing. Oh well, the reality...

Still, code with lots of dependencies does suck of course.

On the other hand, I'm pretty happy with the module I'm writing. All the outside just needs one header file that's right now 76 lines long and that includes only very basic "resource id" header file. The insides of my module also need some of the outside functionality; I've written some "outside interface" for that - a header file with something like 50 lines and also absolutely no includes.

That's what I consider to be a low-dependency interface. That's good. That doesn't suck :)

[EDIT] The code I was referring to isn't so bad (e.g. it really doesn't "includes everything else", but "includes quite large amount of stuff"). I'm just somewhat frustrated at the moment, and anything that's not very ideal in the codebase irritates me.

Software usability

2005-02-25T16:58:00.000+02:00

Some time ago I thought that 3dsMax had pretty bad usability (hey, it doesn't even do real hit testing :)). 3dsMax is nothing compared to one certain CAD package that I'm writing customizations for at work!

White stuff

2005-02-22T08:55:00.000+02:00

There's one conceptual problem that Paulius told me the other day: imagine that you have a white sheet of paper and a black pencil. How would you draw an object that emits light?

It's puzzling at first, but surely it can be done :)

I'm facing with the same problem in our next demo: we have a white character in a white, brightly lit room. Even more, there will be some light emitting "stuff" in there. Now, how to render all this so that it's not "washed out", too bright and with no contrast?

I'm not happy with the way it looks right now, but we're heading there.

Scene.org awards

2005-02-17T16:37:00.000+02:00

Woohoo! My demogroup is nominated to scene.org awards 2004, in 'breakthrough performance'! Pretty cool, considering that Syntonic Dentiforms, which we got nominated for, is my first 'real' attempt at making a demo... Well, there were other attempts before, but they were really lame and childish :)

I was pretty happy with my demo-related performance last year. Three demos in half a year (ok, one of them was crappy). Now it's already half a year with no demos, and I already want to make one. Well, I'm already trying to make one, but so far there's lots of higher priority stuff surrounding me.

Smooth shadows idea (not)

2005-02-14T12:44:00.000+02:00

So, I had this smooth shadows idea recently. Turns out that it's not an idea, Willem de Boer already has done a very similar thing (Smooth Penumbra Transitions with Shadow Maps). Now, the only way to have my idea back is to 'optimize' (i.e. hack/cheat) this method. Specifically, if we target projected shadows (not real shadowmaps), and can do some approximations, then we can get it working faster. I've done some experiments, right now it involves rendering to shadow map once, then Gaussian blurring it (two separable passes), then Poisson-blurring it. Works pretty fast :) I need to experiment some more and see if I can get anything.

Things to try

2005-02-11T14:10:00.000+02:00

I want to implement automatic mesh unwrapper (for normalmapping, lightmapping or similar). Not that I need it much, just so, for it's own purpose. The most recent thing I've read is Bounded Distortion Piecewise Mesh Parametrization; now I only need to find some time to actually do something. Ain't an easy task!

The other thing to try is: take ATI's NormalMapper and take a look at their octree implementation. Try replacing it with several regular grids, or tweak the octree. Fun project, also without any real purpose... (again, the reason I don't do this is "no time" :))

Finally, I have one really stupid&simple soft-shadows idea for oldskool projected shadows. It's something between Mitchell's 'Poisson Shadow Blur' and Valient & de Boer's 'Fractional Disk Soft Shadows' in ShaderX3. I think actually trying to implement it (instead of just an idea that came up while taking a bath) would be only several hours...

I must sound like a loser complaining about lack of time. The truth is, I could get that time probably, if I'd were more organized.

A bunch of hacks

2005-02-10T22:24:00.000+02:00

And I though my own freetime projects were coded like a bunch of hacks, with no clear structure, with lots of code duplication etc... These are nothing compared to the code I now work with!

Precalculated 2D fracture

2005-02-10T13:21:00.000+02:00

I'm working on ImagineCup2005 realtime rendering demo now, and one thing we are planning to do is fracturing/exploding walls of some room (in realtime of course). I've been thinking how to implement all this, and together with Paulius Liekis we came up with half-precomputed, half-cheated solution.

Our 'walls' are perfectly flat, so all fracture process is 2D, just the pieces that fly/fall out turn into 3D simulation. In the demo, some things will hit the walls, and the fracture must start there.

The first cheat we thought is to have some precomputed 'fracture patterns' (bunch of connected lines in 2D). Choose one pattern, 'put' that onto wall and there you go. Now, the problem is that the pattern has to be 'clipped' to the existing patterns, the falling out pieces and the remaining wall has to be triangulated, etc. I think it's not 'slow' process (i.e. suitable for realtime), but pretty tedious to implement.

The next idea was: why not precompute the fracture pattern for the whole wall, and make it pretty detailed? When something hits the wall, you take out some elements from it and let them fly/fall. Now, the fracture pattern is always fixed for the whole wall, so this isn't entirely 'correct' fracture, but I think it's ok for our needs. I coded up some lame 'fracture pattern generator' (tree-like, nodes either branch or not, branches are at some nearly random angles, and terminate when they hit existing branch), and the patterns do look pretty cool.

The only problem with this is when I tried calculating how many fractured pieces our walls will contain. I get half a million or so for the whole room; that's certainly a bit too much.

One idea to cope with this is: have a (sort of) quadtree for the wall, and each cell 'combines' the pieces it contains entirely into one 'super piece' (what a term!). Some of the internal nodes vanish, hence the super-piece contains less triangles, and it gets better when we walk up the quadtree. Now, when a wall is hit somewhere, only a small portion of it 'fractures out', so most of the wall can still be displayed as super-pieces, and it gets detailed only around the fractured area.

So, in the end there's almost no computations performed for the fracture. The fracture pattern and the super-piece hierarchy is precomputed once, and at runtime we just use it. Of course, we still need to simulate the physics of flying/falling pieces, but that's another story.

In one moment, we'll have most of the walls 'exploded' at once, I think for that case we'll just use larger fractured elements, and everything will be ok :)

What makes me an awful team member

2005-02-08T13:02:00.000+02:00

If I ever see code that I think could be written in 'much better' way, I have a really big temptation to rewrite/refactor it. Sometimes this can be good, eg. when I spot buggy code. Sometimes it depends, as I often spot the code that is (or I think is) 'sub-obtimal'.

The worst situation is when the code is buggy, but some other part of the codebase depends on that code being buggy. If you find one, and not the other, it's bad.

Working on some big unknown codebase remotely (I'm a contractor for one game in development) makes this worse. I must resist the temptation to alter the code, no matter how bad it looks...

ShaderX3

2005-02-07T18:47:00.000+02:00

Today received my 'contributor copy' of ShaderX³. Pretty sad that the authors themselves receive the book only now, when it has been released in November. Well, maybe that's because for some reason my shipping address contained city 'Kannas' instead of 'Kaunas', and an obsolete postal index (we've got 'refactoring' of postal indices recently here :)). Anyway.

Like with most similar books, half of this one is old, well known or pretty basic stuff. At a first glance, Generating Shaders from HLSL Fragments by Shawn Hargreaves is really good; Dean Calver's stuff (Accessing and Modifying Topology on the GPU and Deferred Lighting on PS3.0 with HDR) also looks very cool. Probably these alone are worth the book; much like Kozlov's article on PSMs in GPU Gems was. My own articles - oh well; one (Shaderey...) is really useless; the other (Fake Soft Shadows...) is maybe 'interesting', but of unknown practical purpose :)

Ok, back to reading...