Archives
Jan-Mar 2003
Oct-Dec 2002
Jul-Sep 2002
May-Jun 2002
All work and no play makes things pretty dull, so I thought I'd combine entertainment with education (mine) and do something I've always wanted: recreate the classic Williams Electronics game Defender using C++. You can download the prototype or click on the image below to see a full-size screenshot.
It's harder than it looks. I have a new-found respect for what the original videogame developers had to go through, especially considering the computing environment at the time.
What level the game ultimately reaches depends on time and interest. I have some ideas, mostly centered around a mission-based style of gameplay. I know, Midway has already done it for the PS2 and the XBox, but those are 3D games, and I prefer the timeless elegance of the 2D version. It's like chess -- the spartan imagery reduces the game to its fundamental essence, which is to blow the crap out of things.
July 23, 2003
Plimus has been signed on as a new distributor for Leveller. The volume discounts for Leveller are also available through them.
July 15, 2003
The Leveller demo now has the Finnish version of the QuickStart docs.
Worked out in some detail how Leveller's improved Undo system will work. Since bitmap editors have been out for a while, it's not exactly rocket science; they pretty much use journaling mechansisms that keep a stack of edits, similar to the edit decision lists used in film editing software. The memory required to remember the details of a particular edit are a fraction of the bitmap itself, therefore many edits can be stored and played back to literally recreate the bitmap at any desired earlier point in time.
One problem, of course, is edits that take considerable time to compute, even with today's hardware. A good example is a deep erosion filter; on even a moderate sized heightfield, that can take several minutes to run.
The other annoyance is implementation: every command or action that can modify the heightfield has to record its editing parameters so that the Undo system can reapply them during Undo and Redo operations. Leveller currently has tens of dozens of such actions, so the bulk of the work involves a lot of turn-the-crank style coding.
A nice side benefit, however, is that other actions will be included as well, such as changes to the selection mask, the markers, the gridlines, etc. It's always been a little confusing otherwise.
Ironically, change might not be good. I remember an old MacWorld article bemoaning the arrival of multiple-level Undo in graphics apps. The fear was that people would spend all their time endlessly experimenting, desperate to get that "perfect" result, as if suddenly all the old reasons for imperfection, for (ugh) compromising one's artistic vision -- had been beaten back.
To some extent, that concern is valid. Even without Undo, computers in general are special machines in that by virtualizing the part of reality that corresponds to a finished physical result (e.g., a Word document as compared to its printed form), they make endless editing inherently possible. Even on old PCs, one could save a document to disk and immediately reuse it as the basis for a different version.
Reporters stuck with typewriters envied PCs, but they also found a certain comfort in that, whatever they managed to type up by the end of the day, that was the version that was going to press. By being forced to accept the typewriter's limitations, they didn't suffer the angst of wondering if they could have done the job any better. The limitations of physical reality made it acceptable to be pragmatic. Not surprisingly, early PC users discovered that it was all too easy to "get lost" in an ocean of possibilities, and had to learn to manage time using their own willpower. Most programmers know the problem all too well as the hard choice between coding elegantly and getting a product (even a mediocre one) out to market in order to pay the bills. Our tools may no longer stifle our creative genius, that's true, but we are still mortal beings trapped on a unidirectional river of time. Besides, if it were different, we could remake ourselves endlessly and thus become Protean and meaningless; it is our limits that define us.
A weird extreme conclusion would be the virtualizing of all of reality. If you made a mistake -- say, going to the prom with Mary instead of Betty -- you could simply undo your own life and roll back time to before the decision was made. You could shift back and forth, undoing and redoing along the timeline you've built so far, endlessly nitpicking and refining your past choices, trying out different futures to see how they compare against each other.
To be fair, however, a true "Undo" would have to include your own state of mind, so after rolling back time, you wouldn't remember having done so. And you probably wouldn't want or need to remember everything that happened after that point, anyway -- the future tends to diverge rapidly from what it was after only a few minutes, after all. Then again, how can you compare alternate futures if you don't remember all of them?
The point I'm making here is, our current Undo facilities are like virtual reality in miniature. Your work, your documents; they have a future. In the ultimate scheme of things, they have only one particular future. But by using Undo, you can temporarily defeat the old maxim that making a choice inherently means denying all other choices. You can force a document to show some of its multiple futures before you "collapse its waveform" into the final one.
July 11, 2003
Finally spec'ed out the way the next TER file format (version 6) is going to work, which will allow me to elegantly fold in those cumbersome LVW (Leveller View) files. Explicitly persisting view information seperately from the heightfield will be a thing of the past.
To avoid bloating Leveller, it won't support legacy TER formats. Instead, a standalone translation utility will be made available to migrate legacy files.
Leveller 3.0 will have at least seven extra tools for the vector layer support. That, combined with other things (heightfield layers, multilayered texturing and texture editing) will complicate the package beyond what many people need. So the best course of action appears to be to offer two versions. The new file format makes forward compatibility possible, so it can be used by both versions. i.e., you can edit a Leveller 3.0 document with Leveller Lite and have it open safely back in 3.0 with all the 3.0-specific data intact.
There will be a 2.4. In addition to TER 6, I absolutely have to improve the Undo system before tackling 3.0.
July 10, 2003
Vectre 1.2 is out. You can get it directly from here. In addition to the 3D object viewing, it has a few editing-related fixes.
One of my Finnish relatives, Juha Hietanen, did me a big favor and made a Finnish version of the Leveller webpage, or at least the best part of it. He also translated the Leveller Quick Start documentation, but I'm still working on getting it installed.
July 9, 2003
Since Vectre edits splines pretty well, and I'm familiar with OpenGL, I figured I'd add previewing for 3D spline-based objects such as lathes.
July 7, 2003
Finally got some work done on Vectre. It had some problems with path selecting, and path segments couldn't be bent by dragging them. Both of these issues are now resolved, and I think Vectre's tools are now good enough to consider moving into Leveller 3.0. Vectre 1.2 should be out in a few days.
June 24, 2003
What a week. I'm still coughing now and then; that cold is like the gift that just keeps on giving. This had also happened to me fifteen years ago when I was working in Montreal, just getting caught in this vicious circle of perpetual throat irritation, what the doctors call "non-productive cough". I took so much cough syrup with codeine that I was buzzed pretty solid for a week or two (way back then, that is, not now).
But life goes on, and work with it. Besides, at least the timing is good -- everyone is on holidays so things are quiet anyway. I added more tesselators to the OpenGL POV-Ray patch and am now adding solid OpenGL rendering. Couldn't get specular lighting to work until I realized that OpenGL's modelview matrix likes to transform surface normals.
Speaking of the OpenGL patch, yesterday out of the blue that particular page got hit an absurd number of times, downloads as well, totally shattering the previous visitation record for the site. I thought it was because the Leveller 2.3 demo had been released, but that didn't even come close. Despite whatever the purists think about mixing OpenGL with POV-Ray, somebody's interested. The TER format patch is popular too. Which makes sense -- POV-Ray is popular with both Terragen and Leveller users.
What else? I started a thread on the comp.ai.philosophy newsgroup asking if making human-level AI would be redundant. The thing branched off into a discussion of quantum mind effects and the like, as these things are wont to do. All very interesting if you like that sort of stuff. Some of the posts are harsh or flamebait, and at first I thought it was going to be the typical Usenet crap, but then it got quite good.
June 13, 2003
Developed a TER format patch for POV-Ray. It lets you use TER files directly in POV-Ray scenes, instead of having to first convert them to TGA or some other POV-friendly format. Binaries and source are available here.
June 11, 2003
Looks like my cold is finally winding down. Turns out it was some sort of strep throat. Everyone in town seems to have it too. It wasn't totally devestating, so I worked on a new OpenGL wireframing patch for POV-Ray. Why bother? Well, why not? The world's most popular scanline rendering API meets the world's most popular raytracer. It's two great tastes that go great together. :)
I also finally got around to fixing the Terragen import/export plug-in. It now spans 100% properly and doesn't bother asking about mapping the span at all.
I should be able to get back to working on Leveller soon, the only question is... what did I have on the plate? I guess it's high time to start on 3.0 and bring over the vector editing tools from Vectre. I need to update the demo and the viewer as well.
Leveller 2.3 appears to be a hit. Over 95% of newsletter recipients immediately requested the update, making it the most popular one ever. A lot of people who hadn't updated before also decided they had to have this version.
June 2, 2003
Caught the absolute wickedest sore throat on Friday. Every time I swallowed it felt like molten lava was flowing down. I kid you not. Didn't get one single wink of sleep that night. Then suddenly it upped and vanished, and today I'm just coughing now and then. Bizarre. For a moment I thought SARS or that West Nile stuff had finally caught up to me.
Sitting at home slightly sick is boring, so I sent out Leveller 2.3 updates and pondered the nature of scanline rendering in POV-Ray with a somewhat lively discussion on their news server. People love POV-Ray, that much is certain. Although I'm prototyping the idea locally here, I was told that the odds are good it's a waste of time. But I'm game. The best way to find out for sure is to just try it. If you want to see how it all works out, visit the new web page which logs the action for you.
May 26, 2003
Can't believe I had the backface culling of part of my scanline shader reversed. But now that that's fixed, the results are looking much better. Below is a screenshot showing Leveller with a finished rendering along with some statistics.
The renderer will most likely be a standalone app that Leveller calls. Even if I have the renderer run on a separate thread, it's cumbersome to model while it runs, and if Leveller should crash, there go both tasks. It's easier to enjoy protected memory if the jobs run as their own applications.
Like the raytracer, the renderer also has a lighting cache. When a rendering finishes, you can move the light source and have the scene redraw instantly. It takes a bit of extra memory, but it beats having to re-render just because the light was in the wrong place. And yes, the light cache works if the renderer used antialiasing.
May 25, 2003
Getting closer. Got the heightfield cell normals smoothing again, added 2x oversampled antialiasing, and added a fractal cube to the shader. Looks like a coral reef I saw once.
As for rendering time, slow is not the word; crawling is more like it. The triangle count can easily go into the billions as other subdividing geometry is added.
May 23, 2003
Finally got around to developing a scanline renderer. It makes implementing displacement shaders easy, because one can rasterize additional geometry on the fly. Here are some gallery pics:
I had smooth normals interpolation working across heightfield cells, but I had to break it to get the shader's surface normals lighting properly. It'll be fixed later. The shader is a fractal subdivider similar to that in Terragen and WCS/VNS. For hard rock surfaces and harsh, pebbly sand, it's very convincing. I also have to get it to displace along the heightfield's surface normals instead of the Y axis, and then do material maps so that the shader doesn't apply everywhere.
The speed is pretty good. The pics above took an average of a minute or two at 600 Mhz. The heightfield size tends not to matter because the LOD manager will emit subcells depending on the display size of a heightfield cell. If you put the camera really close to the ground, you'll get zillions of triangles and a scene might take five or more minutes, but those are rare cases.
For a test, I had the shaderless renderer mimic OpenGL, to make sure the base triangle rasterizer was working properly, and I discovered that, under the same quality settings, the OpenGL software renderer is often slower than mine. Considering I haven't done any optimizations yet, that's disappointing. Then again, most people accelerate OpenGL. I should also have the renderer pass its triangles to OpenGL to see how well acceleration improves it.
The fog is a straight linear attenuation with the sky. Since Leveller is a modeler, the primary goal for the renderer is (like the raytracer) to show colormaps at full detail and to render UV mapped heightfields, which the raytracer can't do. Getting a quick preview of a rendition is one thing, matching standalone renderers is another. On the other hand, there's no reason a plug-in facility (again, like the raytracer) can't be provided. Ideally, the renderer would accept Renderman shaders.
May 18, 2003
The beat goes on. Turns out the OpenGL renderer creates triangle strips one column at a time, so I switched it to do it row by row so that memory accesses will be closer together. Large heightfields may show an increase in rendering speed.
Made a new gallery pic. Since Leveller can generate rock meshes I figured I'd try a rocky landscape. It doesn't quite follow the laws of physics -- a lot of thin rocks are pointing straight up -- but then again, that makes it a more original scene. I would have used radiosity, but the thing took an hour to render even without it.
I dumped YahooGroups (or eGroups, before Yahoo bought them) as the Leveller mailing list host and switched to FreeLists.org. I couldn't find my old registration info, and Yahoo's password retrieval system can't find it, and at any rate, Yahoo drops subscribers too often whenever any mail servers can't be reached. To try the new mailing list, just click here.
May 16, 2003
The Wavefront OBJ export plug-in was updated to support UV-mapped meshes. The DXF plug-in was updated as well, because it was doing world scaling on each vertex twice, causing serious mesh distortion when exporting with a non-1.0 world scale. Both plug-ins also slightly miscentered the exported mesh around the origin.
Caught the first showing of "The Matrix Reloaded" down at the local theatre. The meeting with the Oracle, the highway chase, the chat with the crime boss, and the scene with the Architect guy were cool; everything else could have used a little more editing. Still, it was well done.
I was hoping they would have held the camera forward longer during Trinity's highway bike ride, to see people throw up in the audience, but it was too much to hope for. I think the movie industry has a certain rule about not competing with rollercoasters. A pity, because that was truly the finest moment. I hope they make an IMAX flick or one of those hydraulic motion-simulator rides out of it. Or better yet, just give me the uncut version on DVD. Only a total idiot would mount a camera on that bike and not record tons of forward-facing footage.
May 15, 2003
Well, it's been forty-eight hours, and I haven't heard any computers blowing up or customers screaming, so I guess another long beta test period paid off. Speaking of which, I'm not sure if I can let most users participate next time, because 99% of them didn't say anything. It's just not cost-effective to provide beta copies for nothing.
The more I write code, the more I appreciate just how brittle the stuff is. It takes astonishingly little to make it fail. I have this private joke where a magician offers a programmer immortality, and he accepts. Not because the programmer wants to live longer, but because now he'll finally be able, in the absence of time pressures, to write his programs as he always wanted to, with full elegance and zero defects.
Just imagine if computer technology had been available in Columbus' time (15th century) when the average lifespan was around forty years. By the time a programmer got really good, he'd have to pack it in. He wouldn't even have decent time to train others. By a happy coincidence, people live twice as long today, enabling careers that require the accumulation, learning, and passing on of considerable knowledge.
May 13, 2003
Leveller 2.3 is released. For the first time, I've got the full installer and the 2.x updater available simultaneously. It's never any fun to wait, after all. The updater for 1.x users, however, is still in progress. They can always update to 2.2 and then to 2.3, however.
May 12, 2003
Looks like build 450 is the one. If the final test results are okay, then 2.3 is done, and it's just a matter of releasing to distribution.
The splash motif was done with 2.3's UV mapping feature and POV-Ray. There are only two rocks, but POV-Ray was instructed to repeat them over a thousand times with a different transform for each. The actual source picture is available here in the gallery.
On the subject of themes, 2.3 is probably directed at people who export scenes for external rendering. Both the UV displacement mapping and extensive scene exporter modifications (particularly for Renderman) all play to that audience. The vertical pane stacking lets one get a more panaromic "true landscape" feel inside Leveller as well. And thanks to Thomas de Groot's last-minute suggestion, the POV-Ray export includes the "look_at" statement in the camera object.
2.3 turned out to be seven months in production, over twice as long as the two earlier updates. There were three main reasons: developing Vectre/Life/XaoS/multiplatform code, overhauling the scene exporters, and the ever-continuing job search.
Writing decent scene exports is more involved than I thought. One starts by poring over the renderer's specifications and understanding them correctly. This, of course, demands experimenting with the renderer software itself, because specifications (especially for complex programs) are rarely implemented precisely as written, and no amount of reading can match the understanding gained from actual experience. One must also test exported files.
So the process becomes a great repeating circle of a) modify the code, b) export a scene description, c) render the scene, and d) understand what failed. I must have done enough test renders to wallpaper the inside of a mansion.
It's alright except when you can't easily do (d). It happens, and it's no one's fault. We're talking about taking a complex program and trying to make it work with other big, complex programs. If this stuff was easy, people wouldn't be paying other people to write software for them.
May 9, 2003
Well, now the docs for 2.3 are done. Went easier than I thought. So all that's left is to update the installer, and get the setup package over to the distributor. The updater program will take a while longer, of course, since I have to do the usual diffs against the 2.2 package.
May 8, 2003
The Vancouver Canucks lost. Sigh -- they won't be progressing to the Western Conference. They played with heart, they went down fighting, they didn't go down scoreless, but in the end, for whatever reason... it just wasn't meant to be. Some other time will be their time, but not this time. Waaaah!
As far as I can tell, Leveller 2.3 is now feature-complete and fix-complete. Unless some last-minute issues crop up, I'm not touching the code. I'm just doing docs, and they're almost done too. This thing is very close now. Thank goodness, too -- it's the only thing keeping me from crying in my beer.
The UV displacement mapping feature is the biggest change since 2.2, and given that it was actually done early on, it was tempting to release 2.3 early. But the thing is, there must be balance. As fun as UV mapping is, I just know a lot of existing users don't really need it, and for them, an update solely for that feature would have been more of an irritation than a help. So I made sure a lot of other nice things went in. Everyone should benefit from what 2.3 brings to the table.
May 6 nearly broke the visitation record on the website; it was shy by only a few hundred hits. I imagine the pending 2.3 release is the explanation. Well, we're talking days now. It's even money that this thing will be out before the Matrix movie.
May 7, 2003
Man, what a day. Nailing down a new release is like getting rid of air bubbles under wallpaper: there's always one more little thing to take care of.
But I believe Leveller 2.3 is close at hand. I can feel it. The builds have been getting very solid lately. I even got the DXF plug-in updated to recognize the new plug-in API v10 and use it to export UV-mapped triangle meshes.
Adding vertical pane stacking made the number of window-management commands enough to warrant moving them to the 'Window' menu, so that's been done. Which is nice; the 'View' menu is less cluttered. Each iteration of this project just keeps moving it closer to perfection. :)
The scene and map button panels have me a little worried, because they complicate the interface. I suppose it can't be helped. Once existing users grow familiar with a tool, it doesn't help to hold them back to a design intended for neophytes. Someday we'll have programs with interfaces that automatically adjust to user proficiency, but someone needs to develop a standard framework for that kind of thing. All I can say for now is that at least the button panels are harmless; using them won't cause the heightfields to change, so people who are mystified aren't in any danger of losing work.
The multiplatform stuff bit into my time. It's annoying in that it doesn't materially change Leveller on Windows; the benefits are only long-term. But it'll be worth it. All the scene exports, for example, now use an opaque CDiskFile class instead of fopen/fread/fwrite/fclose. Porting them over to the Mac will be easy. It's also safer; when a file object goes out of scope, it automatically closes the file if necessary. Pretty old stuff, actually, but you'd be amazed how many people still use C stdio calls everywhere.
May 3, 2003
Vertical pane stacking at last. Now that's more like it:
The whole pane management code had grown pretty crufty over the years, so I took the opportunity to clean it up at the same time.
It's understandable to think that such a simple thing should have been in eons ago. All I can say is: priorities and resources. There's just so much going on that a lot of small desirable things get passed over for a long time.
May 1, 2003
Finally down to the short strokes on Leveller 2.3. Loading grayscale bitmaps can have unsorted palettes automatically fixed. Scene export is interruptible, and I'm adding the option for view windows to show the scene and map panes stacked on top of each other instead of only side by side.
A good reason why fermions (matter particles) have mass and can't be accelerated to light speed occurred to me while drinking. The details (for those who enjoy that sort of thing) are available here.
April 26, 2003
Just got back from the Northwest LinuxFest down in Bellingham, Washington. It was just across the border from where I work in Canada, and Jon "Mad Dog" Hall was giving a lecture on a topic dear to my heart (how business and open source can work together), so I drove down. I also thought it would be neat to see Linux users and vendors, and discuss Linux with them and see what they were doing with it.
I saw a few interesting things, like a bigger accent on multimedia efforts, and those tiny PC form factors running Linux without problem. vmWare was also cool; I saw Linux running on top of Windows XP and vice versa. There was even a Yellow Dog distro running on a Power Mac, but its version of OpenOffice didn't support antialiased fonts, which was pretty glaring. It might be intrinsic to OpenOffice, but I'm not sure.
I got lucky and met with Jon about half an hour before he was scheduled to talk. We talked about the future of Linux in commercial contexts, and I mentioned things like payvoting and Street Performer Protocol. Unfortunately, just before we could really dig into things, this lady asked him for his autograph for her husband, and then launched into an unceasing explanation of how her kid was so gifted that she didn't know what to do to keep him from growing up a complete nerd. I kid you not. The way I figure it, if the young lad is happy, we should all be happy. Forcing him to be "balanced" will probably only bore him silly; I recommended letting him reach his intellectual limit in his own good time and then discover life's simpler pleasures.
Jon was introduced by the festival host and took the stage to welcome applause. He's a decent speaker and gets his point across well. He had a PowerPoint presentation of his talk behind him and walked us through it. I had woken up really early to make my border transition take five minutes instead of five hours, and unfortunately I almost nodded off at the end of Jon's talk, but just then he wrapped it up.
He made an excellent point about how consumer software is an imperfect compromise. What people really need and want is a solution tailored for them (or for their business) and this whole idea of shrink-wrap software, along with all the other darkness that tags along with it (like EULAs, binary-only provisioning, etc.) conflicts with that. He was also fair in heavily stressing that the community needs to work harder on distinguishing "free as in free beer" from "free as in free speech". His attacks on Microsoft were also commendable; if you didn't see the ruination that monopoly software companies threaten, you did after he mentioned them. I particularly enjoyed his answer to those who ask if open source will destroy the software market: hey, Microsoft will too, because they want to own it all.
My only disagreement was when he envisioned software development evolving back towards a service instead of a product (although he admitted earlier to me in our private discussion that perhaps not all types of software dev could go that route). I'm not saying I disagree in the predictive sense; the future may very well turn out like he suggests. But I disagree in that, for lots of people, software development is our only means of support (like myself) and we simply don't have some other business that will perform better if we can get open source. Maybe General Motors and other manufacturers find the software-as-service future rosy, but for people like me, it's pretty much a death sentence because in services, we can only earn as much money as there are hours in the day. Without the margins that products provide, payroll destroys everything. And the incentive to do great work won't materialize. I'm certainly not going to slave over a keyboard producing elegant, nicely documented code for five bucks an hour; that's chump change. I may as well go work at the gas station. Either that, or I have to do what other service professionals do: charge a ridiculuous rate. Why do you think plumbers won't touch your pipes for less than $100/hour? Because it's just not worth it otherwise!
People don't want to play helpdesk; they want to cash in. They want to have kids. They want to send their kids to college. They want to retire with dignity. They want to live in a house instead of a trailer park. They want to afford at least a few nice things. They want the ability to just buy something if they need or want it instead of jumping through budgeting hoops or getting permission from their spouse. They want to stop gnashing their teeth at tax time and gripping their desks as they track their stocks. They want financial freedom. And services, especially in the vein that most open source pundits present it, just don't cut it.
Products are where it's at, plain and simple, because they amplify a person's time. Services are the absolute worst, because when you demand them, you take a person's most precious asset: his time. Can you make someone younger? Can you? Look at any service company that rakes in millions and you'll notice that they're all extremely labour intensive. Services suck. In those companies, people toil day after day while management and the top shareholders get all the gravy. And when workers burn out, management just discards them like that horse in Orwell's Animal Farm. I'm no communist, and it's precisely the ability of people to make and sell products that makes capitalism better. Hoping that we'll all get shunted back down to service work is offensive. Why should people who manufacture physical products be the only ones to enjoy the good life? It's absurd.
And all this talk of "getting back more than you put in" because other people release their code is equally silly: How do I capitalize on other people's improvements if my customers can get them from anybody for free? It's nonsense. Even Jon admitted that Cygnus (prior to Red Hat buying them out) was perhaps the only really successful open source company, and only because their product line had extreme attributes. After all, who would want to maintain the GNU/gcc toolset for multiple platforms or even fork that code? Cygnus happened to pick a winner, but that's simply not representative of most software projects in general.
The real nail in the coffin, however, is that I could write code on a service basis, but to spread the cost fairly, I would have to deploy the very business model that people don't want: payvoting. But if Jon is right, and things get extreme, then that's where I'm headed. Quid pro quo.
April 23, 2003
Well, the RIB export is just about done. It took a lot of testing, due to the permutations, but it went very well. The dialog box was a total revamp, and here's what it looks like:
The other nice thing is that the testing also helps flush out little issues in Aqsis like patch edge artifacting. I included BMRT semantics support as well (things like "minshadowbias", which confuse other RIB renderers but BMRT needs), even though BMRT has gone underground. But just on the off chance it's still being used, since it wasn't much work to leave the support in.
The funny thing is, RIB is now supported as good as, or even better than, POV-Ray. For a long time, Leveller's somewhat had the stigma as being POV-oriented, but that's finally starting to fade.
April 21, 2003
After serious thought, I've decided to make my own cross-platform portability layer for Leveller (and for my other apps).
wxWindows looked very nice, but after reading a lot of messages on its mailing list, I figured that:
- I have a lot of code generalized already.
- I prefer my own generalized API (closer in spirit to Qt) than wxWindows. Emulating MFC is great for people who love MFC, but if I'm going to abstract my application code, I'm going to do it right.
- I want to get my hands dirty with the cross-platform code, so that I really understand what's going on, so that I can fix or tune things expertly. If it's someone else's code, I'll be too tempted to wait for others to fix it.
- wxWindows is still very rough. I just don't have time to learn and deal with all of its idiosyncrasies. If I build a new framework, I can code and modify it incrementally, fix each bug as it emerges, and keep the thing clean, instead of having hundreds of bugs all lying around. And besides, I'll be jump starting with my existing generic code, which has already been incrementally developed and debugged.
- I have a vision for what a cross-platform framework should be, and I believe the time has come to try it now. Yes, it's going to be a lot of work, but I don't have to write everything -- just the parts that Leveller needs.
- I have some expertise in cross-platform coding (between Mac and Win32, anyway) and the world could use another framework. Right now the only real games in town for a true affordable Win32/Mac/Linux system are wxWindows and Qt, and that's really not robust enough.
April 20, 2003
Turns out Aqsis developer Paul Gregory wasn't sure if Aqsis' rendering supported alpha channel textures, but it turns out it does. And with some of his help I got a shader working that uses the alpha data correctly. It will have to ship with Leveller since the standard RIB shader collection doesn't have the facility. The pic below shows a masked TIFF with its TextureCoordinates set to be scaled 400% and rotated forty-five degrees, with a MakeTexture instruction to do tiling.
April 18, 2003
More adventures in TIFF land.
I thought masked RGB images were written by using two TIFF directories, one for the color data and a second for the mask. After all, the TIFF specs define subimages specifically for masking purposes. But turns out a combined RGBA directory is traditional. It shrinks the TIFF writing code, at any rate.
POV-Ray reads 24-bit TIFFs with flipped scanline order, unfortunately. After some investigation, it appears to be a potential libtiff bug. Going through libtiff's bug database was, in a way, disheartening -- for something that was originally designed to be easy for developers to support, it instead turned out to be a quagmire. Windows itself can only display a fraction of the possible TIFF variants, and it even munges a few that it can. It's likely that no one has ever implemented a perfect TIFF reader. The possible combinations of pixel depths, masking, tiling, stripping, compression, orientation, color spaces, etc. are simply mind-boggling.
Hewlett-Packard is dead. It's been dead for several years, but only now am I pissed off enough to admit it. I didn't want to admit it, but I've been in denial. As hard as this is, I have to be strong and just come to terms with the painfully obvious.
Technically, the company exists, but let's face it: everything that defined HP, like product quality and actually caring about its customers, is gone.
A couple of years ago, I should have known something was wrong when the local PC retailer was offering HP Pavilions at competitive prices. Warning bells should have gone off left and right in my head, but for some reason I wasn't listening. How could HP sell their top-quality goods at commodity prices? The simple answer: cut corners. They did, and I've been paying ever since.
My HP Pavilion is dying, after only two years. I suspect it's either the hard drive or the RAM. It doesn't matter that I only feed it perfectly filtered power from UPS boxes; the thing keeps intermittently acting up until I'm forced to restore Windows. And speaking of Windows Restore, the stupid thing went and created 30,000 .cpy files in the c:\_restore directory even though it was disabled. Ate up over 3 GB and eventually hosed everything. I couldn't just delete the files, of course -- Windows said that they were "in use". And after the reinstall, I had to spend an hour deleting all the consumer junk HP thinks people lust after, like their Multimedia Keyboard software that regularly sends secret Internet traffic back to HP, or offers from Yahoo, AOL, and various vendors of questionable periodicals.
My HP printer is equally lame. The drivers suck; they don't even recognize the parallel port features of the Pavilion correctly, even though both devices are made by HP. The scanning software routinely fails to scan large random areas of images. It's supposed to fax, scan, and print, but all I've ever found it good for is printing. Which it is good at, actually -- I guess even HP's current management couldn't totally destroy the original spirit.
So I ask: Where did it all go wrong? Why did a great company that did so well for decades decide it had to sell out? Where am I now supposed to get reliable equipment? I don't care if the stuff is cheap enough to get rid of when it conks out; it takes time to replace things, and time is too precious. My newer Athlon-based system is standing by to take over, but I'm probably going to be transferring files over to it for a week.
My father always told me that money is merely a means to an end; it is not an end in itself. And yet, a great company fell prey to the most adolescent of wants. Somehow, being big and prosperous was more important than being small but producing quality goods. Why? Why does this need for market share blind otherwise intelligent people? Why must our basest, ugliest qualities always destroy our nobler ones?
Maybe a new company will bring back "HP-ness". But if everyone believes that such a company can no longer exist in today's world, then surely there is something wrong with us. I suppose I'll never understand the logic; if I had a top-notch hardware engineering firm that had "only" several thousand clients, I'd be estatic. Let the Compaqs and the Dells have the rest, if crappy knockoffs, cutthroat pricing, and growth at all costs (including harming the customer) is their game. To me, it's absolutely pointless, because it defeats the very purpose of running a business in the first place.
April 16, 2003
While working on Leveller's RIB exporter, I realized that most RIB renderers prefer texture files in TIFF format. So after some deep contemplation and examining Adobe's TIFF specs, I added basic 24-bit RGB TIFF output to Leveller. Now when I make a RIB file, I can output the texture bitmap as well. The scene and map panes can be output as TIFF, and attached textures can be output to POV-Ray in TIFF format too.
RIB is odd in that it has to generate a secondary (and potentially larger) bitmap file if you want to tile the texture (with the standard shaders, anyway) because normal RIB renderers like to optimize for antialiasing and such. POV-Ray, on the other hand, couldn't care less; it just tiles and maps the texture on the fly, interpolating for enlarged/shrunk texture pixels as necessary.
TIFF is not a hard format to understand in its essentials. In fact, it's quite straightforward. The problem is trying to support every possible TIFF flavor, because it likes to use lots of compression schemes. I was tempted to just use libtiff, but that's an option better suited to when I want to support full reading and writing.
April 14, 2003
From the Because-We-Can Dept.: Since reference shapes display as is regardless of the heightfield's UV mapping, I realized I could make a planet with a ring around it, just by importing some circular paths from Vectre.
Vectre 1.1 is now under development. It's inherited PNG image support from Leveller, and its LSL export now lets you choose the reference shape elevation, color, and curve quality approximation.
The VRML export is done and tested, and now I'm looking deep at the RIB exporter.
Tim O'Donaghue over on the Terragen mailing list was having trouble reading ASTER DEMs, so I gave it a try. Turns out the Raw Binary plug-in works pretty well. For his HDF file at least, the elevation values were single-precision floating point with Motorola endianess, header length 3704.
April 10, 2003
Well, Leveller 2.3's POV-Ray export is wrapped up. For a torture test on a 633 Mhz 64 MB PC, I exported a 720 x 360 heightfield of the Earth with 24-bit texture to a spherical mesh and rendered it at 1024 x 768 size with antialiasing.
The POV script wound up at 33 MB, taking about a minute to export. It took 2.5 minutes to parse, 4 minutes to render, and another half-minute for the hard drive to stop grinding the swap file. Peak memory usage was 100 MB. The moral of this story: mesh exports of large heightfields should not be done casually on modest hardware (duh). It could have been worse, I suppose -- some beta testers reported generating meshes of 75 MB and more. But when bump maps no longer do it for you...
I tried getting layered textures to work in mesh2 objects, so I could have masked imagemaps partially occluding and blending with colormaps, but no go. I'm not talking about having the mesh reference different textures in its texture list, but just a texture composed of several "texture" statements. But no matter what, the mesh2 syntax wasn't having it. A crying shame, because layered textures are so powerful. In fact, I'm not sure what the point is of not supporting them in meshes. Leveller can composite to blend the colormap itself, but layered UV textures would have been incredible.
As if that wasn't weird enough, turns out that a masked imagemap will cause ray intersections to continue through the mesh and blend in whatever lies underneath/behind the mesh. That makes for some interesting ways to create complex surfaces with holes in them. I can see people using that to render carved pumpkins. The mesh's backfacing polygons render also, and as near as I can tell, my previous surface normal bugs have upped and gone.
Had several students these past few weeks ask me for free Leveller licences. I'm curious what that's about because they say it's for school use, but since it's spring, wouldn't school be out around now? At any rate, I'm not exactly walking around a mansion in a monogrammed bathrobe smoking cigars and chatting up supermodels in the swimming pool. If Leveller made piles of cash, would I still be risking carpal tunnel syndrome coding the thing? So why does it occur to people that I should be running a charity? I don't get it. The program is already like one-tenth the price of Photoshop, for crying out loud. I've seen guys spend more on movies when they take their kids out. Hell, I've seen textbooks that cost more. Don't have eighty bucks? Ask your parents for it. Wait tables or tend bar for a few nights. Live without cable for two months.
What's sad is, these folks don't even offer me anything in return. Zip. Rien. Nada. Don't schools have to teach some basic economics? You'd think they could at least offer to document plug-ins or something. Isn't Latin mandatory? Does quid pro quo ring a bell?
The supremely ironic thing is, I didn't even get to go to school. I couldn't afford to. But if I could have, I don't think rounding up eighty bucks would have been hard. I mean, if I had had the ten or twenty large to attend college or whatever, eighty bucks would be a rounding error. I'd have pulled two evening shifts at my friend's typesetting shop outputting Mac files on his imagesetter and been done with it.
Started reading Kube-McDowell's book Vectors. It's about a researcher trying to measure consciousness. So far it's pretty good; I'll let you know how it turns out.
April 6, 2003
Closing in on the POV-Ray export for Leveller 2.3. The new texturing options now work for heightfield objects, and they're sweet. If worst comes to worst, you can generate a composited imagemap that simply copies the heightfield's final appearance in Leveller and builds a bitmap from it.
Got automatic alpha channel inversion working for TGA imagemaps, and what a relief that is. POV-Ray now renders masked TGA files the same way that Leveller does.
While cross-referencing Leveller's PNG support with POV-Ray's, I noticed a small bug in the latter and forwarded the one-line fix to news.povray.org. The problem has to do with grayscale PNGs of 4 bpp or less showing up as black.
Speaking of PNG, it has conflicting standards. The SDK docs say background color chunks can be ignored by PNG readers. The guy who made the test image suite says background colors should always be blended in alpha-channel files. I've taken the former advice for now; later on I may add a preference to let the user decide.
All the testing in POV-Ray 3.5 required a break, so I tried it's new "slope" keyword:
Man, what fun. The texture script is listed below. You may have to tweak it to match your particular heightfield.
// Insert your camera, lights, background, etc. here.
height_field
{
tga "pathspec_of_your_heightfield_file.tga"
smooth
pigment
{
gradient y
color_map
{
[ 0.000 color rgb <.3,.3,.3> ]
[ 0.25 color rgb <.7,.7,0> ]
[ 0.45 color rgb <.1,.15,0> ]
[ 0.49 color rgb <.3,.5,0> ]
[ 0.5 color rgb <.1,.15,0> ]
[ 0.515 color rgb <0,0,0> ]
[ 0.52 color rgb <.8,.7,0> ]
[ 0.53 color rgb <.4,.4,.2> ]
[ 0.55 color rgb <.3,.5,0> ]
[ 0.56 color rgb <.1,.15,0> ]
[ 0.57 color rgb <.8,.7,.6> ]
[ 0.59 color rgb <.3,.5,0> ]
[ 0.6 color rgb <.3,.5,0> ]
[ 0.61 color rgb <.1,.1,0> ]
[ 0.64 color rgb <.3,.5,0> ]
[ 0.65 color rgb <.1,.15,0> ]
[ 0.7 color rgb <.3,.5,0> ]
[ 1.000 color rgb <.0,.1,.5> ]
} // color_map
} // pigment (colormap)
texture
{
normal
{
slope
{
<0, -1, 0>, 0, 0.5
}
normal_map
{
[ 0.0 bumps .5 scale <.05, .005, .005> rotate -45*y]
[ 0.5 bumps .5 scale .001]
[ 0.51 bumps .5 scale .0001]
[ 0.52 bumps .12333 scale <.0001, .001, .0001> ]
[ 1.0 bumps .12333 scale <.001, .001, .001> ]
}
}
pigment
{
slope
{
<0, -1, 0>, 0, 0.5
}
color_map
{
[ 0.000 color rgb <1,1,1> ]
[ 0.500 color rgbt <1,1,1,1> ]
[ 0.510 color rgbt <.75,.75,0,.75> ]
[ 0.520 color rgbt <.5,.5,0, .7> ]
[ 0.750 color rgbt <.3,.3,.1,.5> ]
[ 1.000 color rgbt <0,0,0,1> ]
} // color_map
}
} // texture
finish { ambient .1 specular .66 }
// (your heightfield transforms here)
}
// Main fog.
fog { fog_type 1 distance ? color rgb .6 }
// Ground fog.
fog
{
fog_type 2
distance ?
color rgb 0.7
fog_offset ?
fog_alt ?
turbulence 0.8
}
April 3, 2003
Added PNG image support to Leveller, at least for texturing. The real advantage is for exporting heightfields with, since PNG supports true 16-bit grayscale. As it also supports alpha channels, this makes Leveller an ideal platform to create such PNG files. Since POV-Ray interprets 16-bit grayscale PNG files more efficiently than 24-bit Targa files, memory will be conserved as well when exporting to POV-Ray.
April 2, 2003
Seeing as how yesterday was April Fool's day, I thought I'd try a joke on everyone. I replaced the normal Leveller website page with one that announced a radical shift to payvote purchasing. I have no idea what the sense of humor really is, or why people have it, but it's fun. :) My only hope is that, if aliens do exist, they don't pick April 1st as the day to drop by, because then they'd probably get all confused, not realizing that most of the day's news was just made-up stuff.
On the serious side, I've been working my butt off revamping the POV-Ray export dialog to handle the new POV export features.
It called for some dynamic widget placement and dialog resizing, and Windows unfortunately makes the job harder than it has to be because of the way its windowing APIs work, but it'll be worth it. Since I'm emitting secondary texture bitmaps for all imagemaps, I can also cleanly handle the inverted mask interpretation issue POV-Ray has with alpha channels.
People's reaction to UV mapping ranges from favorable to "wow". Although a mesh takes much more memory than a normal heightfield, computers have come quite a ways since Leveller debuted, and with POV-Ray's support for UV texturing, it'd be a crime not to leverage it.
The scene section UV map had one big problem: it centered the distorted heightfield on the sphere, even when the section was just a tiny sphere patch, and that made navigation nearly impossible. But it's been resolved: the section centers on itself when it's small, and you can navigate and light it almost exactly the same way as a planar heightfield.
Older Notes