So, I discontinued my MAX subscription a while back, because I'm still on 3DSMAX 8 and I had actually gotten 9, 10, and 2009 (11) via my subscription and I don't actually use them because they haven't managed to add anything useful or fix any of the problems that I tend to encounter (I do periodically test to see if things have improved, and they don't). But I like to keep on top of things, so I went to the Autodesk event today to see what was up in the MotionBuilder/Maya/etc. world.
Well, the answer is, really nothing is going on in the 3D layout package space. They are doing the most incremental of changes. It's really pretty sad.
But the real sadness was the 3DSMAX 2009 presentation. The first thing the guy did was kill 3dsmax.exe with the task manager. I shit you not. He opened up 3DSMAX 2009, had a demo file there, and while he was spinning the model around talking about what he was going to do, he selected something and it just locked up and wouldn't repaint. So he had to kill it.
The entirety of the MAX demo lasted about 30 minutes, and during that time, it crashed again. So even in a prescripted demo, on their controlled hardware, they can't get MAX to run for more than 15 minutes without it crashing.
On the plus side, Mudbox 2009 looks great. I was already planning on buying the upgrade, and the demo only confirmed that choice.
If it weren't for Mudbox and Maxwell, 3D would be a very dismal place :)
I did an extensive overhaul of the Sushi level gameplay over the past few weeks, and everything is in now. I went through a few revisions, and essentially everything is layered on top of the existing gameplay that was shown at PAX, so any/all of it can be removed pending evaluation.
My overall goal is to fix the remaining gameplay problems that I perceived in the game, which were fairly numerous. Most of them were in-level problems, and I've done my best to address those, but only lots of playing will determine that :) There is also one metagame problem, and that is something that I am also working on fixing, but that's a little further off.
Tomorrow will actually be an off day, because I am going to DigiPen for the AutoDesk launch event. I discontinued my 3DS MAX subscription, because I am actually still just using 8 and nothing in 9, 10, or 11 has done anything useful for me, and I am not mostly on my own pipeline anyways with very little actual work done in MAX. So why am I going to the event? Well, I like to stay current with the tools, all of which are owned by AutoDesk now :) And furthermore, I am an avid Mudbox user, and since the new Mudbox is out, I'd like to take a look at that and probably purchase a 2.0 license while I'm there, assuming it is as good as 1.0 but with texture painting (and I will praise the gods for finally giving me an alternative to painting in Modo, my texturing nemesis).
Today I added fast previewing to the art pipeline, so that you don't have to wait for a render farm distribution to use placeholder images for various scenes. I wanted to use 3D hardware acceleration to do the rendering so it would be zippy, given the high polygon counts of the scenes... even though the rendering is just basic solid-shaded polygons, it still would be quite slow at 1920x1080 in software with multi-million polygon count scenes, to be sure.
Unfortunately, it appears that you can't actually render using hardware-accelerated OpenGL without having an actual HWND. I'm not 100% clear on this, so that may be just internet misinformation. But apparently if you OpenGL rendering to a DIB section, you're probably not going to get hardware acceleration. I didn't do any testing to see if these were filthy lies, though, so maybe someone out there has more information.
No big deal, though - I just use an HWND that isn't actually displayed. This way it's basically the same as not having one at all as far as the user is concerned. But there's one nasty gotcha: if you just use the standard OpenGL buffers for drawing, you will get black, since, at least according to nVidia, OpenGL doesn't "own" those pixels if they are not displayed in an actual window, so they don't pass the "inclusion test". This happens regardless of whether or not you are using the GL_BACK or GL_FRONT buffers, or any other standard GL_ buffers. I'm sure there's some fancy spec lawyering going on here, but I try to stay clear of such things :)
The solution turns out to be using the OpenGL 2.0 framebuffer interface. If you define your own framebuffer, then you can draw to it anytime you want, regardless of whether or not it could potentially be displayed. Since this code seems hard to come by as-is on the net, I thought I'd post it. I've seen code snippets out there that almost do this, but they all rely on selecting a texture into the color channel, rather than just using renderbuffer storage. So here is the actual code that you need to use renderbuffer storage for everything:
GLsizei Width = 1920;
GLsizei Height = 1080;
GLuint Framebuffer;
glGenFramebuffers(1, &Framebuffer);
glBindFramebuffer(GL_FRAMEBUFFER, Framebuffer);
GLuint ColorBuffer, DepthBuffer;
glGenRenderbuffers(1, &ColorBuffer);
glGenRenderbuffers(1, &DepthBuffer);
glBindRenderbuffer(GL_RENDERBUFFER, DepthBuffer);
glRenderbufferStorage(GL_RENDERBUFFER, GL_DEPTH_COMPONENT16, Width, Height);
glFramebufferRenderbuffer(GL_FRAMEBUFFER, GL_DEPTH_ATTACHMENT,
GL_RENDERBUFFER, DepthBuffer);
glBindRenderbuffer(GL_RENDERBUFFER, ColorBuffer);
glRenderbufferStorage(GL_RENDERBUFFER, GL_RGBA8, Width, Height);
glFramebufferRenderbuffer(GL_FRAMEBUFFER, GL_COLOR_ATTACHMENT0,
GL_RENDERBUFFER, ColorBuffer);
GLenum Status = glCheckFramebufferStatus(GL_FRAMEBUFFER);
if(Status == GL_FRAMEBUFFER_COMPLETE)
{
// You have succeeded!
}
else
{
// You are all about failure.
}
Once you've done that, you're good to go. You can render all you want, and then do a glReadPixels to recover the rendered image, no visible window necessary.
But one word to the wise: at least on my driver, you need to do a smidgen of cleanup before exiting the app, even if it's just a hacky app:
glBindFramebuffer(GL_FRAMEBUFFER, 0); glDeleteFramebuffers(1, &Framebuffer);
If I didn't delete the framebuffer, I got faults in the nVidia driver on app shutdown. So AFAICT, leaving a bound framebuffer is not something that the nVidia driver cleans up properly.
As I've mentioned multiple times before, the content load for this game is probably about two orders of magnitude larger than what I was planning to do when I first started :) I don't really have any excuse for this.
What quickly became clear, however, is that it was intractable to manage the large number of explorable backgrounds with the way I had been doing them previously - namely that each individual shot in a scene was a separate frame of animation in a MAX file, and that frame was marked up with an identifier. Then later, in a code (or data file, depending on how you look at it), I would have to manually specify the linkages between identifiers to connect up the scenes. With scene counts over 100, this becomes somewhat ridiculous, especially for one person to manage when they're already doing everything else on the game as well.
So today I switched to using individual camera objects placed in the MAX scene, and then parented them to their appropriate connected parent. Since the scene layout in Sushi is a tree, not a graph (due to the pre-rendered nature, it would have to introduce Myst-like "rotate around" kinds of controls in order to be a graph and not be supremely confusing), this works OK, and gets around the fact that a custom plugin to do this sort of thing would be very difficult to do in MAXScript, and I'm trying to keep as little as possible in compiled plugins due to the fragility of upgrading MAX versions when such things are involved.
I then wrote some MAXScript to allow me to navigate through the scene by hopping from camera to camera using a forward/back/next/prev kind of system, which works quite well and approximates the navigation as the player actually does it in the game.
I still have a fair bit of work ahead before the new pipeline is totally operational and rendering complete scenes at the new massive polygon counts, but at least everything is more or less outside of MAX now, which is the only way the bigger scenes were ever going to get rendered. Scene assembly inside MAX has always been pretty much a non-starter, and I suffered mightily through it for the previous builds of the game. So I'm happy to be closing in on a fully running pipeline that can handle arbitrary polygon loads.
I noticed a frame-rate problem in the game today, and after checking I found that in fact 20% of the CPU time on my machine was being spent in DPCs. After exiting the game, I found that 20% of the time was still being spent in DPCs, so clearly it wasn't me.
Since nothing in particular was running on the system, I decided to chalk it up to Windows voodoo and reboot the machine. Unfortunately, when I rebooted the machine, I found that my startup script didn't work because the command line parser couldn't find the command "subst". Never a good sign.
Fortunately, it turned out that nothing malicious was at work. Yesterday I had attempted to install the update to Pinnacle Studio DV (one of the worst pieces of software ever written by humans, but unfortunately a must-use app for my video camera's obscure video format), but the installation couldn't complete because the installer was also one of the worst pieces of software ever written by humans. So it "rolled back" the attempted installation.
But still, it managed to fuck up the environment variable settings such that the system path was no longer set properly, leading to the missing subst.
It's days like this when I really appreciate the stable environment Microsoft provides for developing and deploying software.
Fresh back to work after my Japan vacation, I was doing some gameplay additions today when I noticed that my compile times seemed too long. Normally builds run from about 5 seconds to about 25 seconds, depending on whether you're building one or two files or the whole project. But suddenly, if recompiling a single file was taking more like 15 seconds.
Looking into the matter, I discovered that somehow, the executable responsible for code generation had ballooned to 48 megabytes. The executable, mind you. So merely the act of executing the code generator was actually eating up the extra 10 seconds, as Windows laboriously processed a ridiculous amount of code.
It turned out to be a simple case of overzealous array sizing. Since it's just a bunch of hack code that doesn't need to ship or anything, there's a bunch of hard-coded arrays in there that got a little out of hand with their maximum dimensions :) The ten-second fix of changing it to an allocation instead of a static variable eliminated the problem completely.
So, no harm done, but it was still quite the unusual experience for me to happen upon a 48 megabyte executable!
This is my first time ever working with printed t-shirts, so I was very nervous, but I'm delighted to say that everything worked out quite well!
I wanted to have a special t-shirt to give away at PAX to commemorate the event, since I was so happy that Sushi was selected and I wanted to have something really cool that only PAX attendees could get. Unfortunately there's 50,000 people who go to PAX, and so I think it would have cost... hmm... over a half million dollars to print that many t-shirts? So shirts will only be going to folks who beat the conference best, daily best, or hourly best versus score for each of the versus stage rounds!
Of course, I might also give out a few at my own discretion :)
So, I wanted to do something special in honor of being selected for the PAX 10. So as a special addition to the game for the PAX build I have added a head-to-head competitive multiplayer mode for the show floor. I think it will be a lot of fun! After folks have warmed up a bit and learned how to play a little of the game, they can play against each other on a few special head-to-head levels. And maybe if people like the mode a lot, I'll figure out a good way to include it in the final game as well.
I put together a new machine today to use as the PAX demo machine. It was $400, and it's a quad-core.
Since at $400, I could replace my very aged render farm for less than $2500, I decided to do a test to see how much faster this thing could render.
The results were shocking. As an example, on the P4's I left a poster-sized render (approx. 4k x 6k) on for 10 hours and it came back at SL 0.6. That's like unusable - it basically means that you haven't even gotten to the first tier of light collection. On the quad-core, it's at 20 minutes right now and it's at SL 4. It probably would have taken the P4 a week to get to SL 4.
In the best of all possible worlds, I could just swap out the motherboard, CPU, and memory on the farm and it would cost even less (something like $1500), and would save a ton of time wrt reinstalling. But I'm assuming that XP will just totally lose its shit if you drive to plug an old install into a new motherboard. Re-authorization requirements aside, I'm guessing it will have all the wrong INFs or something.
But regardless, I think I will probably replace the farm after PAX, because a 20x-at-minimum speed boost is kind of impossible to ignore. It means the exterior shot renders would go from a day to 30 minutes.
One of the nice things about my custom rendering distribution system is that it saves all of the images that have been rendered. This allows me to easily go back through time and collect all of the renderings of a character during the various stages of development. I thought it might be interesting to post one such series for people who aren't familiar with the kind of process I use for getting the "look" of the characters in Sushi Bar Samurai.
I've posted them in chronological order, which may seem counter-intuitive because you will have to go back to earlier items to "start at the beginning"... but, I thought it would be best to do it this way so that the actual timestamps on the images go in the order in which they were actually rendered. Plus, it gives me some incentive to add a button in Nebula for switching the sort order :)
