Archives
June '04-Apr '06
Jan-May 2004
Aug-Dec 2003
Apr-Jul 2003
Jan-Mar 2003
Oct-Dec 2002
Jul-Sep 2002
May-Jun 2002
Apple introduced its new iPad computer tablet two days ago.
Granted, it didn't produce the kind of impression that the iPhone did, since it's basically a larger iPod Touch. There's not as much novelty this time around. When Steve Jobs was demonstrating the web browser and email features, I got the feeling that the crowd was thinking to itself, "Yes, we've seen this all before", and was politely waiting for something fresher. Fortunately, Phil Schiller showed off the iWork suite, which was new to the multitouch environment.
While time will of course tell if the iPad succeeds, I give it a good chance. Apple doesn't release new products without considerable research, testing, and careful design. They don't really do Newtons or Cubes anymore. They don't introduce something unless they're absolutely sure that there's a market for it, and a big market at that.
That being said, this time around I think Apple is also taking a little more risk than usual, because it is introducing a new idea, which I guess can be called "impulse computing". Apple is betting that once people "get it", they will want it, and then ask themselves how they ever lived without it.
Impulse computing is simply portable computing that's so portable that you can compute whenever the impulse grabs you. You don't have to stop to think whether you want to lug your laptop or netbook somewhere and wait while it starts its OS. You don't have to worry about where to place your device; you just sit or stand how you want and go to it.
PDAs and cellphones already do this, but neither are really suitable for serious work or document review. Apple wanted a device that is almost book-like in its simplicity, precisely because books satisfy impulse use (and is also why the iPad's book-reading application tries to look and feel like a book). The iPad is essentially today's version of the book, but also more. And Apple is betting that people will see the paradigm shift. We'll probably be writing books this way too. Long term, Apple wants people to think of iPads when they think of books, and for books to be relegated to archival purposes. They also want creative types or note takers to reach for an iPad instead of a pad of blank paper.
The iPad's lack of a camera is mysterious. I'm guessing Apple wanted to lower costs and give itself an easy upgrade path for iPad 2.0. Ditto for multitasking; although that may take longer. The bane of Apple's user-centric design is such that even if background apps consume more resources than they should, Apple will get blamed for the low battery life.
Another possible reason why there's no camera is that with its larger screen, the iPad would have the largest preview of any digicam, and people would be taking lots of pictures. So many, in fact, that maybe AT&T was worried about bandwidth once people started sharing them. Or maybe Apple didn't want people whining about video capture. The iPad plays video, so if it had a camera, why can't it be a video camera? And why not two cameras, one front and the other back for taking pictures and chatting (and there comes the bandwidth issue again). It wouldn't surprise me if Apple decided to wait for 2.0 for all that. In the meantime, with the Kindle DX out there, Apple couldn't wait any longer to dampen its lead. Even without a camera, the iPad is delayed until March or April.
I would have liked to see a stylus. I would love to draw on an iPad with something more accurate than my fingers. It would also make using applications more precise. Again, probably in the next version. Or, if the touchscreen has enough precision, maybe a peripheral add-on for today's iPad. Give any student or artist an iPad, and the instinct to sketch on it will be hard to quell.
I'm optimistic in the long term. At the very least, Apple has taken us closer than ever before to what such a device can do and how it should work. And if the iPad isn't the right device, then its successor probably will be close enough that version 2.0 or 3.0 really does usher in the Dynabook age.
Which is probably the best way to play it. If you're trying to improve upon something as common and accepted as the book, you can't do it all in one go. You want to release something close, something useful, that gets you enough units out in the field to get the feedback you need to nail the design perfectly in the next iteration. And I think Apple's on that path.
December 17, 2009
Well, the first decade of the 21st century is coming to a close.
I think this decade will be remembered because it stands out in one very important way: it was the time when human civilization reached enough of a limit on the performance of single-processor architectures that it shifted seriously to multicore. Or to put it more bluntly, this was when Moore's Law started to fail. People will look back and say, this is when everything had to go parallel.
The next decade will probably be even more memorable for a similar reason: we will really hit the fundamental limits of how small the basics of computer devices (transistors) can be. There will be only two choices then: a radical new direction, or the computer industry will crest the way commercial aviation did starting with the Boeing 747.
October 12, 2009
Landshaper 2.0 and Landshaper Golf 3.0 were released today. They feature vector shape texturing, which lets the terrain be covered with procedural and/or image-based content. The shapes can also be feathered, so that their edges transition gradually and their content smoothly transitions over a specified distance. The raytracer also supports transparent backgrounds for post compositing and a partial-area tool for quick render tests.
Some example renders are available here.
May 23, 2009
Leveller 3.1 received some nice slipstreamed updates. Scene pane navigation is much easier: you can use the zoom and pan tools, and the camera tool spins locally instead of globally. Animations are much smoother since flightpaths can be generated from vector shapes instead of recording from a keyboard navigation sequence. The raytracer also renders textured billboard reference shapes.
April 25, 2009
Leveller 3.1 will be out soon. The main things are a bunch of fixes and moving some of the view-level entities over to the document: heightfield texture, colormap, water texture, and reference shapes (for Landshaper, this also includes contour lines and elevation labels). The reduced flexibility of having variations of these things on a per-view basis is offset by more automatic saving and loading.
The fixes include replacing all use of C's strtok function with a custom version. It's not only about thread safety: strtok bites you when some low-level subsystem uses it and higher-level code isn't aware.
February 3, 2009
Leveller 3.0 is out.
Well, time will tell how the vector layer feature plays out. It adds some basic usefulness, like making complex selection masks easier to create, but the rest of the 3.x series can be devoted to exploring the possibilities.
December 6, 2008
The Leveller 3.0 beta became available. From here it's just the usual process of iterating various tweaks and fixes, and maybe some feature additions, until a release candidate coalesces.
The TER file format isn't suited to storing lots of small entities, so all the shapes in the vector layer are put into a single object and persisted that way. Nothing really new there; the markers have been doing the same thing for years.
Vector performance is pretty good. I don't expect Leveller documents to have tons of shapes, but if they do, their rendering speed still seems snappy. And of course they can be hidden if it interferes with terrain modeling too much. I don't know how smoothly Wine handles it for those using Linux; I should set up a test rig for that.
Shapes can be imported/exported to a few formats. I didn't have time to have the I/O go through GDAL; a local code path was used instead. Obviously GDAL is the better long-term approach. Speaking of which, GDAL 1.6 is near release or has been just released, so it makes sense to dovetail with it.
Vectre may be retrofitted with the improved vector code Leveller 3.0 now has, and rereleased to continue as a standalone shape editor/viewer. It's certainly useful as a way to cross-reference code behavior, which is a good debugging strategy.
December 1, 2008
Leveller 3.0 will debut early in 2009. The vector layer integration took several months, but the issues were ironed out, and it works very well. The first thing they'll be used for is to make it easier to make polygonal and other complex terrain selection masks.
A new raytracer has also been developed, and it's multithreaded. Its shaders are all internal, instead of being plug-ins, so it may be made available in addition to the old raytracer instead of replacing it.
October 16, 2008
Daylon Graphics turned ten years old last month, and Leveller soon will. At times like these it's good to reflect.
Software has changed and it hasn't. There are several interesting user interface projects underway and some of their work, such as touchscreen gestures, have been commercialized (e.g., iPhone). By and large, however, we're still using programs the same way we did since GUIs arrived.
Problem domain abstraction remains an issue. If you want a program to do something, you first have to translate how you see the goal into terms the computer can understand. Want to calculate a loan repayment plan? You have to figure out how to express that as a set of cells in a spreadsheet (Maybe there's an existing template, but templates often aren't flexible enough to cover every variation. The problem is analogous to the brittleness of expert systems).
Computers don't know about soil, grass, snow, water, and so on. We still can't model landscapes just by saying "Make this part sandy, that part snowy, and put a forest of conifers over here." Even if the computer could parse that sentence, it would use its default properties for the various items, and we'd get bogged down explaining what kind of sandiness and snow and conifers we meant, and why a forest should be sparser or more crowded or more random. If you could somehow cram all the possibilities (which stem from combinatorial explosion) into the machine, it would take too long to program. A modern game consumes a DVD's worth of storage and can take years for a team of people to create, and can be exhausted by a capable player in a day or two.
Computers would also need to make "good" mistakes and work iteratively. This is how managers and staffers work in real life -- a manager tells his people what he wants, in high-level terms, and the staff works for a while and usually comes within 90% of what the manager wanted. Then he tells them -- again, in high-level terms, albeit more focused on the shortfalls -- what's still needed (e.g., "make those trees larger"). The cycle repeats until the staff nails it or comes close enough that the manager doesn't care about any remaining imperfections.
Part of the problem with computers is that there is a philosophy of user-machine interaction that requires machines to do precisely what users tell them, but this is in fact counter to the way people work with each other, especially in creative fields. But this letter-of-the-law precision of computers is also a key desirability of their operation (and indeed, lies at the very heart of automation: the ability to perform boring tasks perfectly every time). The sweet spot, as often envisioned in stories, is to combine the two: the speed, precision, and perfect recall of the machine with the high-level abstraction-handling capabilities and creativeness of a person.
Computers need to draw comparisons. People are notorious for explaining goals via analogy, either to previous work or to something entirely external (e.g., "Make it look like the Swiss Alps, but with the glacier flow you did on last year's project").
I don't expect these things to happen soon. The human mind pulls it off because of neuron interconnection far denser than anything computers can handle today. People also have subjective experience (qualia), which is an absolute a priori knowledge that lets them know what things really mean (such as the snowness of snow), not merely what things are called.
What is useful to determine -- despite computers lacking these qualities -- are the limits of automation. Can programs be easier to use than they are now? And how much easier? We are currently in a plateau where all the easy low-hanging fruit has been picked, and there's this tasty fruit higher up, but so far it's remained stubbornly out of reach. And we're not even sure if that fruit exists or if there are others above it.
And I wonder, could this be another reason for Bill Gates' departure from Microsoft? He often talked about how PCs would get dramatically easier to use. But maybe he realized that we're really on the tail end of a law of diminishing returns, and that with all the low fruit picked really clean, now was as good a time as any to call it a day. Staying on would have grown increasingly frustrating, because his ambitions would have required ever-longer amounts of time to realize. Maybe he saw that PCs would need to improve their CPU and memory architectures by several orders of magnitude to come into parity with the brain, and that the wait would be too long.
June 12, 2008
BusinessWeek has this article about Windows Vista hurting Microsoft's bottom line. Nothing really new, of course, but it's interesting to think about what might be.
Microsoft is forging ahead with Windows 7. Maybe history will repeat itself and the "third time's the charm" effect will work its magic. Which shouldn't be necessary since Windows is a mature product, but maybe it takes two or three rehearsals to get new, complex technologies like WinFS firing on all cylinders.
But Microsoft could also seize the opportunity to throw in the towel with Windows and focus on something it does much better: applications. Exchange, for example, is so strong that Apple now supports it in their new iPhone. Word, Excel, Powerpoint, Project... these are core programs that businesses won't be leaving for a long time. And imagine how much better they could be if the resources spent on the OS could be turned to applications.
Letting Apple deal with the OS is understandbly a hard idea to sell. There are compatability issues. There would also be a big drop in revenue. And there's also pride. Plus it might be the worst thing for OS X -- without Windows to fight, Apple's OS could languish. Just as bad, it would become the new number one target of viruses. Linux would also lose the prime motivator behind its growth (although Linux is the kind of project that is also beyond such concerns, existing because true love never dies).
Compatibility issues could be treated via emulation, which today would work better than ever since Macs are Intel-based. As a developer, I don't mind different APIs if the new ones offer real value, and Apple has done some good work there. It's also enticing since the new iPhone SDK is largely based on OS X. Emulation would maintain revenue streams while migrating code (or making the code multiplatform).
The revenue drop can be offset by letting go of Windows OS developers or shifting them to application development. There are other cool Microsoft projects that could use more manpower, such as Photosynth. Or maybe more games for the Xbox. Or applications that I can't even think of today.
Pride is difficult to address. Let's face it, Windows pretty much defined what an OS is for most people, and before it, the same could be said of MS-DOS. Microsoft's presence on the boot sector goes way back. Although I might respect the person who decides to pass the torch to a better holder, I wouldn't envy that person having to break the news to his employees and shareholders. It's more painful than Hillary conceding defeat to Obama. Remember how the crowd booed Steve Jobs when he welcomed Bill Gates during a keynote? It would be harder than that.
What such a person needs, like Nixon, is capitulation without dishonor. Maybe Gates saw that Vista had made Windows jump the shark and decided that this was a good time to leave Microsoft. If that's true, maybe it was just too hard to face the music. How do you put a good face on winding down over two decades of OS development, especially after being such a de facto standard?
If it were me, I'd focus on the positive. That's the whole point of the exercise: not to tear something down, but to build things better, to allocate resources better, to strengthen a company by realizing and focusing on its core strengths. Despite the pain, I would gladly trade a drawn-out (and arguably pointless) fight with OS X in exchange for improving and building applications. It's also more glamorous: plumbing is what people take for granted. They expect it to already exist on their computers. People care about programs, not operating systems.
February 5, 2008
Leveller 2.6.2 should be out in a few days. It will feature GDAL 1.5 and a new visual texture placement tool, which makes lining up textures with heightfield formations a snap.
A new Deterrace plug-in should also be available, which will be faster and more accurate. The picture below (click for a bigger version) shows part of a high-res terraced contour plot getting the treatment:
There's also a picture here of the same thing but with some Guassian blurring afterwards.
January 8, 2008
Happy New Year. Still working on the Leveller 2.6 SDK, which is quite different from the previous ones, so it's been taking longer than usual. But the work is going well, and the material is much better organized.
GDAL 1.5 is out, so Leveller will be updated to use that instead of 1.4.2. At the same time, it turns out that GDAL interprets pixels as areas whereas Leveller sees them as points, so a half-pixel error occurs on some file formats which will be addressed. It also means the GDAL drivers for the Leveller and Terragen formats will be modified.
Received a copy of Critical Mass: How One Thing Leads to Another for Christmas. Philip Ball collects and describes several interesting ideas of how the behavior of large systems emerge naturally and unplanned from the interaction of much smaller components, including human societies. The underlying mathematics and analogues to phase transitions in matter make interesting food for thought.
October 27, 2007
Leveller 2.6 plays nicely with Second Life, with its dataformat and selector plug-ins to make modeling SL terrain easier. At the same time I looked into scripting SL objects, as part of a wave-making project. SL suffers easily from lag, so I spend time trying to keep my multiprim wavesets efficient. Here's a shot of the parcel in the Tilly sim's northwest corner where the research is conducted:
Second Life is many things to many people. Personally I would just like it (and many would agree) if they could work out the bugs more. Scripting is (for a variety of reasons) much harder than it has to be. Still, it has its charms. Improvements like switching over to v4 of the Havok physics engine are very welcome, even if late.
Leveller 2.6.1 shaped up nicely. Two extra tools (polygonal and brush-based selectors), several bug fixes, and loading selections from disk prompts for integration with the current selmask.
September 25, 2007
Thought I'd take some time to do some realtime 3D art in OpenGL, by modding the Terrain Viewer app. I'm trying to simulate nice ocean surf, both in the water and when it laps on the shore. Here's a video:
August 24, 2007
Had some plug-in updates for Leveller 2.6. It's now easier to maintain all the channels in a Second Life terrain file, and a new plug-in, Cracked Cells, was added. Below is an example:
Canada may be dying. I love my country, but I'm worried. I received a phone call from a police-affiliated organization asking for donations so that they can lobby the government for more resources to help them do their job. Well, that way lies madness -- we'll go from a world where the poor have little power to one where they don't even have rights. And as high as taxes already are, apparently they're no longer enough. And in Canada, of all places.
July 15, 2007
It's nice when a plan comes together. Yesterday, heightfield modeling; today, terrain modeling. Such a sea change might have merited calling it 3.0, but in my mind 3.0 is yet to come.
After two years and two weeks, Leveller 2.6 is now available.
Still some usual loose ends to tie up, like the 2.x update and the SDK, but it's nothing that hasn't been done before, so they should be out soon too. I don't imagine the SDK will take as long to finalize as it did the last time.
The program also changes the developer. What have I learned this time around? Being organized matters more as a project gets bigger. Which I don't think is any new insight, but it was certainly being stressed upon me many times.
Revamping code pays dividends, even if all that work and interface breaking blows chunks initially. Now that we're here, I'm so very glad the code has been heavily refactored. A lot of cruft and inelegance got jettisoned, and I can move into the future with much more confidence (or maybe it's more valid to say that the project can move into the future at all). I shudder to think what morass I'd be in today if the revamp hadn't been done or only partly done.
And the sad thing is, that sort of thing really does happen all the time at software companies. Since I work for myself, it would have been hypocritical (or at least ironic) to succumb to that fate -- this was indeed my opportunity to leverage being able to do things the way I'm always saying they ought to be done. I certainly can't blame coworkers or bureaucracy.
What else? I got to use STL and templates much more. What a difference those make. The code is so much more readable. If STL was a woman, I'd marry her. :)
July 10, 2007
Well, we're almost there. Leveller 2.6 should be available on the 15th. I lost my private race against the iPhone; Apple got their stuff out first. :) And nice stuff it is.
Some last-minute niceties were able to get in: Second Life terrain import/export; more multithreading including feathered selections; hi-res map pane rendering; user-definable colormap resolution; USGS DEM driver roundtrip fixes, georeferenced texture output, auto texture repositioning during cropping and padding, and the rest of the available GDAL image formats enabled (although there wasn't time to test them). GDAL 1.4.2 happened to be released just last week, so it was nice timing.
As usual, the SDK and the update for 2.x users will come out later, since their production is more involved. But step by step, it all gets done, and things keep moving forward.
June 4, 2007
Down to the short strokes now. In a few days, the rest of this month will be the release candidate period for Leveller 2.6 (yay).
The documentation was heavily revamped, and I'm confident that most users will find it a big improvement. It's more verb- vs. noun-oriented; it tackles how to accomplish things rather than describing what the things are. Or to put it a better way, both those things happen, but now they're approached from a better starting point. The table of contents is a multilevel tree widget, instead of flattening to give access to long pages containing dozens of topics each.
It looks as if Leveller 2.5 may have an exact two-year run; well, that's a nice round number. I still wonder where all the time went, though.
Microsoft demonstrated their Surface technology and Apple will soon release their iPhone. We certainly live in interesting times. Leveller is perhaps too large (interface-wise) to run on a cellphone, but some of Surface's possibilities could work nicely.
March 18, 2007
Leveller 2.6 has reach beta status. Technically, all the features that are supposed to be in are in, and now it's just a question of how well they work.
The above picture shows marker captions in the scene pane, courtesy of finally getting around to text rendering onto OpenGL bitmaps. Not difficult, it's just that on a large project there's always other things taking priority, and that can go on for a while.
How much longer to go? It's hard to say. This is, however, the longest time between releases. 2.5 is having a good run, about twenty months now.
Open Leveller funding recently crossed the 2.5% point ($5000). While I appreciate the support, at the current rate it will be another sixty years before the goal is reached. I guess heightfield modeling is too vertical to attract big numbers (although, realistically, two hundred grand is a pittance for commercial software development). It's tempting to call a spade a spade and scrap the idea, but like they say in investment circles, past performance is no guarantee of future performance. With 2.6, we'll have a better idea of the interest level.
February 24, 2007
The Leveller 2.6 alpha keeps rolling along. Progress has been nicely steady, and the light at the end of the tunnel is much closer now, and my goal is to start the beta phase in March. Beta meaning, of course, that all intended features are present, even if they don't yet work correctly.
Thou shalt have no core software functionality other than the one we provide.
The New York Times had an article on how Microsoft might derail VMware's plans in the virtualization market. Although I can appreciate Microsoft's desire to keep Windows at the bottom of the software stack, it might help to reflect on what really constitutes an operating system.
The truth is, an OS is actually two things, the first dictated by necessity and the second built on top afterwards as an obvious convenience. If you don't believe me, just fire up one of the early microcomputers like the Apple II or the TRS-80; even the original Macintosh gave user programs full control of the machine and the ability to totally bring it down. Back then, an OS was just a bootstrap that got things started but then handed over the reins to whatever software you ran next. But even then, developers wanted low-level details taken care of.
An OS has to be a minimal set of drivers that abstracts the hardware. All it takes is for the hardware to undergo a single revision or for some new widely-used device to be added (and then revised) for programmers to start abstracting said hardware. There also needs to be some way to get user programs to load up and run.
Programmers can then extend the "load up and run" service to become a full-fledged process administrator. It's especially useful to do on machines that have enough memory and speed to multitask. This then leads to user interfaces, and standardization of user experiences, which make sense to layer on top. But these things are really the second part of the OS. And it's no wonder that these things appeared when microcomputers became powerful enough to multitask. In fact, they just repeated the same history that mainframes had gone through decades earlier.
Virtualization software sits between these two parts. It has to abstract the hardware; it leaves running user programs and everything higher up to the OS being virtualized. Of course, a virtualizor that is itself a user program depends on the underlying OS to abstract the hardware, but ideally (in, say, a server farm or mainframe) the virtualizor would be the bottommost piece of software.
Microsoft has been abstracting hardware for a long time. It's without doubt an important part of Windows. But when being virtualized, it's only the program management part that's really needed. What Microsoft could do is recognize that Windows is actually two products in one, and offer the second part separately to customers who want to virtualize. My guess is, such a user-side part would be a) easier to maintain and support, b) load up and run faster, and c) be more secure and reliable. There are some nice advantages for everyone, Microsoft included.
I like the way Windows makes each Windows app (more or less) behave consistently; but if my host OS already furnishes a desktop, do I really need Windows to do so? And vice versa: if I want to run OS X apps on my Windows box, do I really need the OS X desktop? There are obvious functional lines that OS vendors seem to deliberately choose not to see as such. Customers want choice; vendors seem desperate to deny choice by integrating everything under one roof.
Despite Ballmer's comments, virtualization is definitely not an OS feature. Nobody wants to virtualize the part of the OS that does hardware abstraction; that's being done by the OS underneath the virtualizer or by the virtualizer itself. If an OS tries to offer the abilty to run other operating systems, it's no longer an operating system. Now you've got three parts you have to maintain, test, support, debug, etc. etc. And it's one more back door by which malware can seize the machine, while presenting the user an identical copy of the OS that looks and runs fine while the malware does God-knows-what.
Okay, so maybe we don't offer user programs any way of accessing the virtualizor functionality. But that cure is even worse than the disease.
An OS is supposed to be a set of functionality that is at the disposal of user programs. The moment the OS keeps some things to itself, it's not an OS anymore. And if the OS insists on being bottommost on the software stack, it can't be virtualized, limiting its functionality. What if I need to run a pure sandbox environment for security reasons? It's impossible to trust an OS that has to be bottommost. And if an OS can't be virtualized, then one should immediately be suspicious as to why. Is there a hardware lock-in? Is there a collusion between a hardware and a software vendor? And if so, what else are they doing together?
Virtualization is also a great way to find out everything an OS does and where it has performance issues. If an OS can't be run in this manner, that also raises suspicion. And it's probably needless to say that even if the OS can run a copy of itself, that doesn't deflect such suspicion, since only one vendor is involved.
Something to worry about? Well, Microsoft should be careful about what it says, because now it's just one step away from saying Thou shalt have no core software functionality other than the one we provide. And if that happens, well, you may as well just hand them everything on your hard drive, since, for all intents and purposes, they would have the means to secretly copy it anyway. Worse still, they would have the means to secretly change it, and that puts us back into the world of 1984 and defeats the entire purpose of computing. Maybe no one today is planning to make TV sets which can't be muted, but that's where petty, monopolistic ownership of software stacks can easily take us. Apple isn't innocent either -- it doesn't licence OS X to be virtualized. Which is ironic, considering their 1984 ad.
Someday, you'll buy a car and then the dealer will walk after you just before you get into it, to remind you that you can only drive the car on such-and-such roads. The grocers will tell you where you can and can't eat food. The entertainment industry will tell you where you can and can't play music and movies and games.
Oh, wait... that last part might already have happened. Now you see what a slippery slope we've gotten ourselves on.
How can I wrap up this rant? Suffice it to bring up someone who foresaw all this -- Alan Turing -- and reiterate what he said: that any computer powerful enough to be useful (a Universal Turing Machine) can emulate any other computer. The corollary is that if you tamper with this ability, you reduce the computer to something that no one in his right mind would want to use. We're talking about something that is a very fundamental property of computation, maybe even of reality itself. Life requires certain things in order to be worth living, and we tamper with those things at our peril.
January 11, 2007
Apple introduced its new iPhone yesterday. After looking at it for a while, for some reason I began feeling uncomfortable about the regular positioning of its home icons. For a very friendly device, it just seemed out of character. So I made this doctored image to show something a little more natural, a little less... square?
The second pic is less random but meant to make the buttons more accessible for someone using the phone with one hand (and presumably a right-handed person). The buttons I need most often have also been moved closer to the bottom.
January 10, 2007
Happy New Year.
The 2.6 alpha continues to draw to a close. Oshyan Greene is holding a terrain summit forum where two of the topics are overhangs and improving detail on sloped areas. Well, in the spirit of prototyping, I added an experimental displacement map reference shape to the alpha. If you have an 8-bit grayscale heightfield, you're good to go. It might make it into the official release.
A set of nine 64 x 64 displacement maps on a flat heightfield:
The same set, but each map with unique vertical scaling:
The unscaled maps on top of a simple hill:
The scaled maps on top of the same hill:
Changing the map scales and the hill:
A view from above:
The maps on a simple ramp, showing the ease of self-intersection:
Wireframe and solid versions of a simple displaced hill:
December 7, 2006
Texture georeferencing in Leveller 2.6 has shaped up. It's one of the main features of this release and as it gets completed, the light at the end of the development tunnel gets noticeably brighter. Texture quality in the raytracer has been boosted a lot too.
I didn't know James Kim at all; I never had time to watch any CNet videos or even read their articles. But the tragic story of his family becoming lost in the Oregon wilderness and then him losing his life yesterday, well, I feel like it will take a while before things feel normal again. His death was so unnecessary, so... I can't find the right word, but what I'm trying to say is, why him? I know life is unfair, or that it isn't about fairness anyway, but this is just beyond the pale somehow.
The search party says that they were in contact with him before he died; I'm hoping that they were able to communicate that his family was safe, so that he didn't have to die wondering. Or maybe he was able to infer that, if they had found him, they must have found the others.
Rest in peace, Mr. Kim. The cold and the hunger have ended; they cannot hurt you now.
October 10, 2006
Leveller 2.6 is still in the alpha phase, up to build 2831. I've been using GDAL 1.3.0 for stability, but 1.3.2 has been out since May so it was time to switch to it.
Not that there still weren't a few glitches; turns out 16-bit BMP reading was gnarfed. Not a hard thing to fix, fortunately. The only downside with 16-bit RGB pixels is that GDAL expands them to 24-bit since it only supports byte-multiple channel sizes, while Leveller's own BMP reader could keep memory usage at 16 bpp. However, even that's possible to remedy; I've been contemplating having Leveller read the BMP file's header, and if it's 16-bit, to compact the block data returned by GDAL.
Image I/O (for textures and such) now leverages GDAL as well, but it has meant generalizing the bitmap subsystem. One of the aspects touches on a legacy issue with Windows, which is that filenames don't really indicate filetypes. The extension "FIT", for example, is used by both GDAL's FIT and FITS drivers. On the Mac, one doesn't have to put an extension on a filename at all, so you can't trust the filename for squat.
Solving the problem let me solve another: including the settings people want to use when generating images, such as bit depth, compression, etc. So now there's a specific dialog box that asks you for the image format, its filespec, and the encoding options.
Why not just customize the existing File Save dialog? Well, it turns out that images may not be encoded in single files either; if they use a fileset, then we need to specify folder names instead of filenames. You see this already with elevation data; importing a GTOPO30 "file" will prompt you for the folder containing the dataset. The standard concept of data being in a file works generally well, but it's by no means universal.
If you're in Munich, Germany, you can catch Leveller being demonstrated at the InterGeo expo by Bitmanagement Software. They call it GeoFormer, however, to better fit into a consistent product suite. This naturally makes me think of language localization, and I do like Unicode, but that's another huge task better left to 2.7. On top of the branding, Bitmanagement will also offer local support.
August 5, 2006
Well, the Leveller 2.6 alpha went out on time. A second update is available today with the first round of improvements.
There's a lot of work involved, and some of it remains doubtless gnarly, but I feel the corner has been turned. For people who work with georeferenced elevation data, this is going to be sweet. Load up a DEM and bam -- it's just there, all of it, with a proper aspect ratio, and you can edit it using realworld measures.
July 31, 2006
Even the most timid soul ventures into the future bravely.
Will attempt to release the first public alpha of Leveller 2.6 tomorrow. I believe this particular alpha is the most "alpha-ish" of them; previous alphas tended to be pretty robust. Since I carefully track every single work item in a database, I know where the problem lies: combinatorial explosion from the georeferencing feature. It has required modifying much more code than I originally expected.
But it's all for the best, of course. We'll look back on this day and laugh. Getting alphas and betas into users' hands is a key turning point in improving things too, since more eyes will be involved. Especially in matters of look and feel; there's not much I can do by myself to say what ought to be specifically engineered there.
June 15, 2006
I don't normally write about Microsoft Windows. It's ubiquity gives it plenty of attention already. But as the OS that Leveller (currently) runs on, and the OS that I've worked with and seen evolve since the 3.1 days, I thought it would be worth delving into the Vista delay. Especially as a developer who's had his own ups and downs; all the personal growth makes it fairer to comment on other developers.
I don't personally dislike Windows. It obviously does a fair job of being an OS. For better or worse, it has made it possible for ISVs to justify developing apps since they can address 95% of computer users with a single product binary. Its API isn't perfect but it gets the job done reasonably well. While large parts of Vista may not provide anything noticeably superior over XP, it's still nice to flesh out any remaining weaknesses, such as security, searching, etc. Some of Windows' faults irk me, for sure, but so do the quirks of other systems. I have a love/hate relationship with all of them.
I remember when Microsoft got into the applications business. I remember feeling awkward. In those days it was rare or verboten for hardware or OS vendors to make applications. But because Microsoft was already making languages and developer tools, it seemed logical to reuse all their hard-won skill and code libraries to make apps. And they certainly didn't have to train their developers on the DOS or Windows APIs. Making apps also gave them insight into making the OS better, in a virtuous circle. It was all very elegant and efficient.
Of course, some third parties got hurt, but it was merely a larger variation of the utility makers finding their ecological niches logically deneccessitated by the OS being upgraded. Did Adobe really think that Windows would never have smooth vector fonts built-in? Goodbye Adobe Type Manager (and good riddance, most of us would say as well). Apple upgraded the MacOS to do the same.
Then came Internet Explorer. It's one thing to develop apps, but it didn't take a rocket scientist or a philosophy major to see that it crossed a line to start putting application code into an OS. Even without the anticompetitive legal ramifications, it just didn't make any sense from a domain perspective. An OS is supposed to expose and abstract the underlying hardware, not be a Web browser and God knows what else. If Microsoft was thinking to abstract the Internet as a resource, that's admittedly a noble sentiment, but once you take that step, you're no longer an OS but the Net itself. And that's just too big a domain for anyone to address. Even if it could be done, who would be crazy enough (for security reaons) to let a for-profit corporation do it?
Every business has an externality: the thing(s) that it prefers other firms would handle. Looking at Vista, I think there was a misjudgement in defining what constituted externalities. In software, this is especially difficult, because the boundaries are fine-grained and shift as one's techincal acumen and assets increase. Not Invented Here syndrome is also laughably easy to develop since it's often much easier to deal with your own people and processes rather than work with outsiders. Last but not least, of course, is the profit motive, and the profit could be obscene.
The Vista delay shows where internalization went overboard. All of that inclusive lets-do-it-ourselves idealogy slowly but surely caused Windows to bloat. They ship the OS on DVDs now, even if all you want to do is read e-mail and play games. Not only does no one person understand Windows, it could well be that even the whole of Microsoft doesn't. The system has reached the limits of what even the human group consciousness can understand. By the time it gets a handle on it, the system has changed enough to make that understanding out of date. Or, the natural turnaround of staff causes the understanding to never quite gel. Whatever the case, the mass of code and its interdependencies denies closure.
The laws of physics don't prevent Vista from shipping. Software can be much larger -- but the human mind even in group form can only handle so much. We've reached the limit of a Moore's Law of neural biology. Without humans, software is just a big random pattern of bits. It doesn't exist unless we can define it, and to do that, we have to understand it. I don't even understand what 99% of the files in the System folder are for, let alone the code behind them. To me, Windows isn't so much an OS as a mostly hazy blur of unfathomable binaries with completely forgettable names, and I suspect it's like that for Microsoft's own people too. Like many apps (or even our own brains), each of us only uses 10%, and that small percentage becomes what we consider the OS. Reality and perception drift far apart, and when that finally happens to the people maintaining Windows, something has to give.
Whenever I get into a situation like that with my own code, I institute a total code freeze so I'm not chasing a moving target. Then I focus on externalizing, in order to reduce the problem so that it once again fits within my ability to understand. There's no choice in this; I can't hire staff and I can't expand my brain. Fortunately, I can also refactor and rearchitect, which makes the code more modular so that I can wrap my head around its pieces and their relationships. Even this strategy will fail someday, but that's why open source is the next logical phase of Leveller's evolution.
I don't know if Microsoft can freeze Vista. Their customers' feature requests probably form a never-ending stream. And it probably wouldn't do for thousands of employees to just sit around taking an extended break. Besides, freezing is only the start of the solution, and the other steps are even harder. Vista might also be too large to understand even when frozen.
Externalizing would mean letting third parties do more applications and libraries. While I personally think it would be A Good Thing for someone else to make Office, I can imagine how hard it would be to sell the idea inside MS. But it would lift an enormous burden from their shoulders, and let them focus on a more manageable product. Apple externalized by basing OS X on UNIX, and the results speak for themselves. Okay, Apple isn't as rich or dominating as Microsoft, but I don't think customers primarily care about the wealth or power of a vendor -- the point was to make good use of the hardware. Once the goal shifted away from that, I think that's when everything started going downhill, and we're paying for it now.
June 4, 2006
I'm living for giving the Devil his due
And I'm burning I'm burning I'm burning for you
If anyone in the Blue Oyster Cult was a programmer, I'd understand. Their song captures the spirit of engineering a nontrivial project (e.g., anything above 50,000 lines or so). You can pay the devil now, or you can pay him later, but one way or another, you'll pay. Oh yes. Never doubt it; no fact is more fundamental.
The larger a project gets, the more it experiences refactoring. It's unavoidable, because to keep growing it has to maintain a minimal level of elegance (which is inversely proportional to how many engineers you have). In my case, being the only engineer, I have to keep Leveller's code base at what amounts to almost a pristine work of art. Refactoring also increases readability and makes hunting down usage patterns easier: for example, changing all usage of strings as filenames to a specific filesystem_entity_id type. The portability the new type offers is nice, but even on one platform there are benefits. There's also things like replacing the old 1998-era custom containers with STL classes (now that STL is much better supported).
I admit the code has never looked better, which thankfully makes it all worth it. But I can see why some people look at programming and think, Man, unless I have a serious passion for this, I'll choose another career.
Programming is of course a weird profession in that, on the one hand, you need tons of passion (how else are you going to slog through all the crap?). But on the other hand, you need to be clinically detached to objectively spot bugs and figure out the fixes, and architect things the right way instead of, say, the more fun way (which usually tends to be the quick and dirty way). So you have to be hot and cold simultaneously. It's a balancing act, that's for sure. I don't wonder anymore why so many projects start off and then get abandoned after 10,000 or 20,000 lines.
May 3, 2006
The GTOPO30 importer's logic is now in a dataformat plug-in for Leveller 2.6, and it works well. HGT (hi-res SRTM) was added too, and of course SRTM30 works. NASA's Shuttle data certainly smokes the old GTOPO dataset.
Converting the Raw Binary import/export plug-in to a dataformat plug-in went well, and provided an opportunity to make sure that dataformat user interfaces are correctly supported (since Raw Binary can't do anything without user input). It's neat -- now if you have a huge raw binary file, you can preview, subselect, and/or downsample it. Overviews are also cached so you don't have to wait for them to build each time.
Working with GDAL gave me experience with its pros and cons, so I summarized some of it in regards to elevation data support, available here.
They say large projects experience refactoring. Leveller is certainly no exception; I would've reorganized it long ago except it was always more practical to put it off. But the time came, and it's for the best. I must admit things are very organized now internally. A looming issue was something I call the "old names problem", which is what happens when you choose good names for things at the start of a project, but then the things change while retaining their original names to avoid breaking interfaces, so after a while one has a ton of things whose names aren't good anymore. Where a dialog's class reads AppPrefs, for example, when it should be FlightOptions.
Part of the refactoring made me spend some time on something I wish I had use more of earlier, namely the STL (Standard Template Library), and just templates in general. Once you get your head around metaprogramming, it really is an incredible timesaver and code organizer. I think those who avoid STL do so because it adds to the set of keywords one has to know (versus just coding functionality using the keywords one already knows). E.g., now I prefer to use a custom range template class to handle elevation spans, but another person might prefer to just directly manage two numbers.
Attended LinuxFest NorthWest last Saturday. A lot of good presentations this time, and the mood seemed more upbeat from last year. I got the feeling that some sort of critical mass was being reached in terms of certain applications, or at least certain enabling technologies. There were a number of LAMP-based packages, for example, such as SQL Ledger, a simple but workable general ledger app that runs in the browser. Which is very heartening -- once you see business apps appear, it's a good sign that things have moved from the geeky to the practical, that everyday users are adopting a platform. The Apple II took off with Visicalc, the IBM PC and its clones took off with Lotus 1-2-3, so I feel something similar is now happening to Linux. Accounting software lends a sheen of credibility to a platform like nothing else, because, I guess, it's so bottom-line.
I'm still waiting (as the developers I met agreed) for something like Linux Standards Base to become mainstream, so that a shrinkwrap Linux economy can evolve. That's really a cornerstone to getting Linux to the masses, just having a basic infrastructure of standards to avoid unnecessary duplication of effort. Even if I have a cross-platform development framework to code with, it means nothing if I have a maintenance nightmare of supporting several different installer packages and binary build configurations (aside from 32- and 64-bit).
Older Notes