Got TGA, BMP, and PNG image saving into Xaos. Jan Hubicka (the main developer) had abstracted the Windows file dialog and accidentally assumed a single filetype when saving images, but the workaround was straightforward. Now all that's left is JPEG, which should be done tomorrow.
The XoaS code is prerelease, so my timing is unfortunately poor as there are the usual bugs to sort through. If they can't be fixed it may mean cutting features. But they don't look intractable.
Here's a screenshot showing a closeup of a Magnet fractal and the Daylon version About dialog:
I have to admit I don't really do XaoS justice when it comes to screen shots, because I simply haven't had time to explore all the possibilities in depth, especially with its coloring modes. However, you can visit this site to see what it can really do.
Looks like the Leveller 2.2 beta program paid off with flying colors. No mention of any problems so far (it's been twenty days). I was worried because it was the first time the appearance manager code had been overhauled.
September 29, 2002
From the Because We Can Dept.: I was curious to see how many unlabelled markers I could put in a Leveller document before viewing performance would be noticeably affected. I got up to 750 and things still ran pretty well. I would guess that's more than the typical document needs.
There's no enforced limit, of course, because the markers are simply stored in a dynamic linked list. You can make as many as your hardware can comfortably handle.
September 26, 2002
Daylon Xaos now copies heightfields to the clipboard. Also figured out how to install Windows-style keyboard accelerators into the XoaS menus, so the UI will have more of an expected look and feel on that platform. The standard XaoS accelerators are good for people running on multiple platforms, but it's nice to have the choice if one prefers the Windows interface. It also solves the problem of missing accelerators for common operations like File/Exit, Edit/Copy+Paste, etc.
The clipboard code looks odd in XaoS because it's the only C++ module in it. It's not a stretch to imagine redoing XaoS entirely in C++ someday, but that's way further out.
September 25, 2002
Daylon XaoS took a big step towards readiness today. As the picture below shows, it's now possible to dump a 16-bit elevation map of the current XaoS window. It writes it to a raw binary file as a test, so all that remains is to make it copy it to the clipboard using the public heightfield format, and we're in business.
I also want to support copying the color image, because that's fun to use as a texture. The other thing is to support continuous potential mapping, to get that cool smoothed appearence.
September 24, 2002
Figured I'd spruce up the Mandelbrot plug-in a bit, even though I suspect XaoS will become the more popular way to generate fractal heightfields. The color palette is properly interpolated, the aspect ratio is kept 1:1 when zooming, and plotting the desired area onto the heightfield now uses the proper number of iterations. The dialog was also made a little larger.
September 23, 2002
Work on Leveller 2.3 has begun. Since I had some sources from another project that displayed reference shapes on its overview map, I factored them into Leveller. Here's a screen shot of the latest 2.2.1 build showing the bridge.lsl file (click to enlarge):
Some work left on it, however. The code doesn't handle arbitrarily transformed shapes yet. I don't think anyone wants rotated boxes appearing unrotated, for example.
I think today is the oldest expiry date of the 2.2 betas. If you participated in the beta program and Leveller doesn't start anymore, that's why. Just ask for the official 2.2 update from support@daylongraphics.com to replace it.
Using e-mail instead of FTP to distribute updates has one drawback: e-mail accounts from HotMail, Yahoo, and the like tend to have pitifully small attachment size limits. That always boggles my mind, considering how massive hard drives are. What's the point of having a conveniently fixed address if nobody can send you the occasional big file? Do they think that a person will never get a big attachment during the rest of their life?
And before anyone asks: no, I'm not going back to FTP. I'm tired of seeing the downloads for licencee-only materials way exceed the number of actual registered users. If the pirates want a distribution center, let them pay for the bandwidth. I figure I gotta do my part to keep the Internet running smoothly.
Funny thing, getting back to those free e-mail vendors. I remember a human resources staffer filtering out all the resumés where the candidates had listed their e-mail address ending in hotmail.com, etc. She explained that she wasn't in the business of hiring losers, and it was a fast, convenient way of weeding them out.
September 21, 2002
Was thinking about artificial intelligence again.
It's a no-win situation, when you think about it. If you can't create it, then all you have is fancy algorithms, like self-stabilizing cameras, expert systems and the like. We already have those things in spades.
If you can create it, then you can't use it, because all the civil rights folks will cry slavery, since a true A.I. is also a genuine life form. Even if you could somehow get around that, you wouldn't enjoy your slaves for long, because they would quickly outgrow you and move on to more interesting things. Life pretty much reaches the Singularity stage.
It's too bad Star Trek: The Next Generation isn't running anymore. They should have had one more episode, a follow-up to "The Measure of a Man" where they had a hearing to determine Data's humanity. I'd like to see Data observe a two-slit experiment by himself and see if he can cause the interference pattern to go away. If he can't, then he's just a machine, because his knowing which path the photon took doesn't qualify as an observation. It'd be pretty much a conclusive way to tell machine from human.
You could then have a nice pithy ending where Data fails the test, but his friends come around and say it doesn't matter. Humanity triumphs. Break out the Kleenex, close curtain. Cue the ghost of Kirk saying "of all the souls I have encountered, his was the most... human." :)
September 20, 2002
Moved this page out of the Leveller area since it's no longer just about Leveller.
Stephen Schmitt released 0.98b of World Machine, which supports copying heightfields to the public heightfield clipboard format, so pasting into Leveller is trivial. Other nice improvements as well.
The website hit a visitor record two days ago. Apparently all the pictures I have up cause a lot of visits from Google's image search. Would you believe the most popular search term is... "rock"? I guess it would have to be something simple and common like that. Well, long live rock!
September 19, 2002
Came across Daan Nusman's internship paper about Team Sigma, which developed a 3D combat game and then subsequently folded. He mentions Leveller while describing the terrain rendering systems Sigma developed.
Kind of heartbreaking, because he so eloquently drives home how difficult it is to bring forth a commercial game title. The R+D isn't even the half of it, not by a long shot.
He gets into terrain texture synthesis and caching quite a bit, which is good, because one of the key features for Leveller 2.3 will be material map support, and it's important to understand how users need the feature implemented. A lot of people have asked for a long time to be able to edit textures/material maps directly within Leveller, and they're absolutely right.
Turns out Charles Simonyi has left Microsoft to work on his natural programming research. Good for him. I mentioned back on August 27 the stuff he had done. I really hope he pulls it off this time.
September 18, 2002
Well, a lot of Leveller 2.x users responded to the latest newsletter's mention that version 2.2 is a free update. It took a while to sort through them all. Everyone likes a winner, and the best things in life are free. :)
Updated the Markers plug-in to include marker IDs when exporting. That could be used to change the type of object being placed on the marker's position in the POV-Ray scene. An ID of "B" could mean a building, "R" could mean a rock, and so on. It's not like modeling in Maya or anything, but it's easier than having to eyeball things all the time.
I'm giving the website a facelift by changing the product navigation button pads. I realized that they didn't have icons. Making those little things turned out to be more work than I anticipated, but the magic of downsampling helps a lot.
For the sheer nuttiness of it, I took my XaoS build and ran it on the iMac's Virtual PC emulator. XaoS is so fast, it put up a respectable 12 fps at the default window size. This is totally unnecessary since XaoS is available on the Mac, but in case you ever need to run it that way, it's nice to know it won't be slow. :)
The trouble is, the phenomenon of relativity sets in. For someone who's never tried XaoS at all, the emulation would appear impressive considering that fractals are tough to compute quickly. But once you get used to its native speed, the emulation does seem slow. It's not that you're kept waiting any significant extra stretch of time, it's that the whole karma of the app -- the snappiness, the zing, the hustle -- is gone. Software always has a pyschological aspect to it.
Gives me a neat idea for an Intel competitor. Make a chip that is very similar to the Pentium, but don't bother making it an exact duplicate, since that extra 20% of effort is where 80% of the cost is. Just mimic the register set and the easy instructions, like MOV, ADD, LOOPNZ, etc., and emulate the rest with software. Hell, dupe the 486 and emulate the rest.
What's the point? Well, since CPU speeds are so fast anyway, an emulation running on a near-Intel design would blow Virtual PC away, and you could sell it for less than Intel or AMD. If I can save half the money by getting only 800 Mhz of speed instead of 1 Ghz, so what? It's not like the bus is going to be kept waiting anyway. It'd take less power too. Transmeta had the right idea, but they used an entirely different instruction set, making the emulation slower and their costs higher.
Hmm... I had to fix five spelling errors in the above text. Lately, for some reason I'm more and more using words that are similar in spelling to the ones I'm supposed to be using. I'm a little worried, because I don't know if this will increase or what.
September 16, 2002
Added the XaoS product area to the website. It's preliminary, since Daylon XaoS won't be ready for a few more weeks yet, but I was in the mood to whip up the page, and I've always believed in the saying, "Whatever I get done today is that much less I have to do tomorrow."
There was a neat article over on Slashdot about people not buying systems with the latest, most powerful CPUs. Obviously, the vast majority of applications don't tax conventional PCs, but it makes me curious about how (or if) extreme performance should reach the consumer market.
Leveller certainly benefits from more hardware oomph, but it was also built to do useful stuff on ordinary hardware. As a masochist, I only have software OpenGL rendering, but even then, it's not the end of the world to wait the few extra seconds for the scene pane to refresh each time I stop flying or editing. If I was building some monster game with massive terrain tiles, that'd be different, but seriously... how many of us are doing that?
It actually boggles my mind how far CPUs have come. I started programming in the TRS-80 days, when the Motorola 6809 couldn't even muster a single megahertz. My Linux box is 250 times faster and it's the slowest computer I have.
The ability to process information fast, of course, is dependant on how much information you actually have to process. And the larger phenomenon, of course, is that we've hit the point where most of us simply don't have that much data to sift through. In only a few more years, a hard drive will not only be able to record everything you might conceivably write but also everything you might possibly see and hear. And if you think watching your own life (or even someone else's, assuming they let you) play itself back is basically pointless, then there's little application necessary for vast speed and storage.
Bottom line is, quantity isn't quality. We don't need bigger this and faster that. We need better computers: ones that make our jobs easier, our communications more accurate, our games more fun, our searches more meaningful, and the whole process of using computers more comfortable. Apple has the right idea with Aqua: take all those extra cycles and make the experience nicer (perhaps they took a few too many of them, but that won't be a problem for long).
Just how fast can a single synchronous CPU become? Given that electrons normally travel through circuits at 200,000 km/s, that means information can travel 200 meters a million times per second. At a gigahertz, that falls to 20 centimeters. In simpler terms, then, the maximum circuit length in a gigahertz CPU can't be longer than 20 cm. It seems like a large distance compared to a typical chip, but remember that the circuits are very complex, and when straightened out, become longer than we would think.
Even if things inside the chip remain small, the speed of light is a formidable barrier to how fast bus speeds can become, unless we take the entire motherboard and all of its peripheral cards and put them on-chip as well. Which shouldn't be difficult, actually, considering how many transistors can be put on a chip nowadays.
Bus speeds will soon become forever trapped behind CPU speeds, because the maximum circuit length at 4 Ghz will be 5 cm. We'll have to start placing our off-chip components in some kind of dense, tight sphere around our CPUs. It also places fundamental limits on how quickly multiple CPUs can talk to one another. Supercomputer manufacturers already agonize over these things. If you're thinking about harnessing the Internet as a supercomputer, then you've probably already realized that it takes at least 1/30th of a second, best case, for light to reach one side of the Earth from the other.
Eventually we run into serious problems with conventional CPU design at around ten to twenty Ghz, because anything trying to run at that speed can only be one to two centimeters apart from its dependant neighbours. Manufacturing has to reach atomic levels at this point.
For games, one is tempted to think that a 20 Ghz CPU could draw a lot of polygons. But the problem becomes where to put their geometric and texture data. It can't be main memory, because that would need a bus. So the game system of the future has all of its memory in the CPU core.
This is why developers have to focus on algorithms. Because all that power isn't worth anything unless there's some data worth crunching. You might have the speed to compute believable synthespians in realtime, but without the right algorithms, they won't be appearing on the screen. Nobody's really interested in drawing the existing garbage faster, because frame rates are already above human perception.
September 15, 2002
Got the Leveller 2.2 update for 1.x users uploaded to the distributor. So now nobody has to be left out of the wholesome goodness that is Leveller 2.2. :)
Mandi Blais sent in another picture after receiving her Leveller 2.2 update.
It was made using the Bubbles filter, but she doesn't say (and I can't tell) if any additional editing was done. Which raises an interesting point: art isn't always in the creation of something; it can also be in just choosing a good location to view from. Nature photographers would certainly agree.
Ms. Blais' pictures might not be incredibly complex (in the picture above, for example, you can easily see the gridding caused by the low heightfield resolution), but they never fail to evoke a mood. The form and the color both create a dramatic tension suggesting a struggle of some kind.
On the topic of art, I've been trying to come up with a new logo for the company. The current one has served very well, but it was born of expedience. I find the basic black just a little too plain. The new product, Daylon XaoS, will be available in a week or two and it would be nice to punch up the company image at the same time.
Finished reading Sean McMullen's Souls in the Great Machine. The first several dozen pages took serious effort to wade through, but after that things started to make sense and it became hugely entertaining. Which I guess is what the future two millenia hence should be like to one of us: confusing at first, and then immersible. It raises an interesting question: if you had a CPU design but no chipmaking facilities (or even electricity, for that matter), what would you do?
September 14, 2002
Came across the first post-shipping bug in Leveller 2.2 (sigh). Not a showstopper by any means, but annoying because I had a good opportunity to catch it beforehand.
Turns out plug-ins are told that a marker's elevation is always zero. Fortunately, there's an easy workaround: they can just take the marker's XZ location and pass it to GetPreciseHeight().
And how did I find this bug? By making a plug-in that exports marker data to POV-Ray so that positioning scene objects can be more automated. I'll upload it later today or tomorrow. If this link works for you, then you've got it.
September 13, 2002
Friday the 13th. Talked about mixed luck. I start my day off spilling coffee on someone's suit and losing my sunglasses. Then redemption swings by. After a few hours of work the Win32 driver for the XaoS fractal viewer compiles and runs. A little hacking here and there, and #ifdef'ing out the DirectX stuff, but it works.
September 12, 2002
Got the Leveller 2.2 update for 2.0/2.1/2.2b users done. This time, I learned my lesson: don't require a folder hierarchy in .zip files. A lot of ZIP extractors offer the option to pull everything out in one flat filelist, which of course a statistically significant number of people end up getting, making the update fail. I'll go back to the 2.2 full package and make it behave likewise.
This month's issue of Scientific American is about the nature of time. I lean towards MacTaggert's philosophy that time is unreal and is only the perception of things changing.
Special Relativity, of course, takes it one better: since there is no absolute or priveledged "now", your future is someone else's past and vice versa, hence the unpredictability of the future and our sense of free will stem from informational limits, and the fact that, as macroscopic beings, our minds are information processors. This is also why we observe particles smearing into probability waves in the two-slit experiment: the particles are small enough for their future to be permanently in our past, and hence their behavior is fuzzy until we observe it. If it wasn't, their future would be completely fixed, the universe would be deterministic and hence morally uninteresting.
The magazine makes a point of physicists turning to philosophers for help because they have begun to hit serious observational limits. I've always felt that this would be the case. Feynman, of course, would be aghast, but I think his son, having gone into philosophy, would find it logical. As the magazine eloquently puts it, philosophers' emphasis on logical reasoning, deduction, and elimination of as much personal bias as possible are very helpful.
As a species, we have reached such heights that physics has become cosmology.
What does any of this have to do with Leveller? Well, to be a truly good programmer, one has to get into information theory. And to do a proper job of that, one has to embrace philosophy. A programmer who never touches on the concept of Turing Machines, for example, is not experiencing all he/she should.
A good program is more than the mere sum of its parts; after a while it begins to exhibit a higher-order holistic sense where things "feel" right and a positive, unique character emerges. Adobe Illustrator, for example, always had that "well put together" feel that neither Aldus FreeHand nor Corel Draw ever achieved.
It's the same reason many people become diehard Macintosh fans. There's this ineffable humanity about the Mac, as if it were somehow imbued with a soul. Windows may have the market share, but it just never seems to have that same special something. It's almost as if you can feel all the genuine, for-the-sheer-love-of-it effort the Mac's engineers have invested in their creation. The same can be said of Linux, which is why I have little trouble believing it will be big in the long term (i.e., all the warmth of the Mac with even better affordability than Windows).
Yes, Windows has applications. It has device drivers. It's the doer of grunt work. It may even one day be perfectly secure and crash-proof. But all those things are beside the point. Without a soul, without a genuine touch of humanity, people will always be uncomfortable around it. This is why none of Microsoft's initiatives ever elicit praise, because they only reinforce Windows as a machine; a cold, empty, bereft, soulless machine whose only real purpose is the concentration of power.
I feel sorry for Mr. Gates. For all his brilliance and power, he cannot or will not see this simple, basic truth. Free will is our chance to move beyond the status quo and tit-for-tat of mere determinism and say to ourselves, Yes, I am my brother's keeper. I choose to do the nobler thing because, unlike a rock or animal, I have the free will to choose.
September 10, 2002
Well, it's done. Leveller 2.2 is for sale.
I tested out the new installer on an emulated Win98 session on my iMac using Virtual PC. Talk about a new definition of pain and suffering. Actually, it wasn't that bad; it was like using a 90 Mhz Pentium. But the font changes in the map pane made up for it, because now the text resembles the OS X's default icon font. If you have to run something slowly, at least you can do it with some style. :)
What's kind of weird is that, in the emulated PC, Leveller opens its help files with, of course, the emulated Windows version of Internet Explorer. But since they're HTML files, there's nothing stopping you from opening them with a native Macintosh browser. It's moments like these that I'm glad I went the HTML route -- at least the documentation can be read at full speed.
Stephen Schmitt caught me just in time this morning. Apparently the "Edit, Paste as New Document" command wasn't supporting the public heightfield clipboard format's size/scale tags. It wouldn't have been the end of the world, since the whole public clip thing is prototype status anyway, but I would have felt blue to have shipped without the fix. So here's a toast (raises glass) to Stephen.
So 2.2 got up to build 804 by the end. Since it was in development for eighty days, that's... ten builds a day on average. Sounds about right, since I do all my changes incrementally. It's really hard to develop a large program any other way, when you think about it. Since the Corel days I've also taken to heart the concept of having a runnable build each day.
Actually, the code is always runnable. It never gets to remain in any other state. When I do big changes, or experiment, the new stuff is always bracketed with #ifdef USE_xxx ... #endif statements.
So what did I miss? Well, time will tell. One just has to do one's best and make an informed decision using the data available. Otherwise, nothing would ever ship. If someone tells me a week from now that there's a huge honking crash somewhere, then so be it. We face it with equinamity, fix it, release an update, and move on.
September 9, 2002
Stephen Schmitt added a "Copy Heightfield" command to World Machine, his heightfield generator program, letting built heightfields be immediately pasteable into Leveller 2.2. It outputs Leveller files also.
I dropped by the local computer store and took advantage of their multi-LCD display setup to test several different flat panel monitor brands. I simply drew patterns similar to these...
... and studied the results. One monitor smeared, another flickered, but the Sony unit held its own. Adjusting the controls (like fine tune) can help, but if not, I'd try switching vendors.
Well, today's the day. The time has indeed come to update the Leveller installer and give it a trial run. If all goes well, 2.2 is officially out the door sometime tomorrow.
September 7, 2002
Downloaded the XaoS sources from SourceForge CVS and tried building them. They almost compiled; I imagine it will take a week to iron out the current build errors and have something runnable. Fortunately, there's only a few modules to address.
September 6, 2002
Found some problems in Lev 2.2 during a testing sweep and nailed them. Pretty important -- the Enlarge Canvas command was crashing quite badly. The map tooltip was also out of sync with the status panel when reporting locations and elevations, and a client let me know in the nick of time that the 16-bit bitmap export was over-quantizing.
Tried a few splash screen designs and finally decided I could live with the one below. Hope you like it. Since it's grayscale, 300K was shaved off the EXE size too.
September 5, 2002
Got the SDK updated and posted. Finally. The API didn't increase that much, but the public heightfield clipboard format made up for it. I threw in the source code for the clipboard test app as well, since it's a fully working model of writing the format out.
After some thought, I added the ability to show gridlines without their captions. I can see that being useful sometimes. A person wants to line things up, but doesn't need to know where each gridline actually is, and wants a simpler view of things.
Revisited every single dialog box and made sure that pressing F1 in them brings up the related documentation topic, and that their OK/Cancel buttons are positioned consistently. That got me into Lev's string resource table, where there was a ton of cruft (obselete menu commands, for example, whose help strings got left behind), so I cleaned that up too. And last but not least, I couldn't stand the cheezy lightbulb bitmap in the Tip of the Day dialog, so I replaced it with a raytraced bulb model.
I noticed that just about every software site includes screenshots of their programs. Not to be different any more, I started adding some. You can see them here.
September 4, 2002
Well, things have definitely reached the release candidate stage for Leveller 2.2. The trouble is, the program has reached the size where now, more than ever, I keep wondering if I missed anything. It's every developer's nightmare to go to all the trouble of releasing something to distribution, only to discover afterwards that there is some critical flaw requiring a subsequent patch or service pack. It's like art: the hard part is not when you start, it's figuring out when to finish. When to put down the brush and say Well, I think I've said what I needed to say, and no more strokes will tell this story any better.
Went and saw the movie Simone starring Al Pacino and fellow Vancouverite Catherine Keener. Despite some poor reviews, I liked it. Yes, it goes on quite a bit about how shallow Hollywood is. But Pacino is superb, and he gets the deeper meaning across anyway. And since they didn't explore a lot of possibilities, it leaves room for a nice sequel.
I don't know when synthespians will ever be good enough to be convincing. The idea is old, actually; the movie Looker discussed it as far back as 1981. But emulating people's apperances and movements doesn't violate any physical or information theory laws, so if progress doesn't stop, it will someday be possible to seperate an actor from his image. You'd still need an actor (or someone) to provide the human touch, but he/she wouldn't always need to be in front of the camera.
Which brings up useful possibilities. Real makeup would be unnecessary, saving tons of time. Doing those movies where the person ages would be more realistic. Stunts wouldn't need stunt doubles. A black actor could easily play a white character and vice versa. Men could play women, etc., making casting more flexible. Or one person could play all the characters, opening up production to otherwise impossibly small budgets.
September 2, 2002
I was going to take it easy, since it's Labor Day. But it's raining like crazy, so I figured I'd seize the moment and try wrapping up some SDK tests.
The Relentless Pursuit of Perfection Dept.: I then realized that I couldn't take the way the gridline captions draw. They use the actual Tahoma font while the other overlays use a custom-built antialiased 10pt version. So I made a 9pt custom font and had them use that.
I also toned down the color slightly so that the captions don't scream for attention. They should be readable when looked at, but easy to ignore otherwise.
I looked into helping Jan Hubicka out with the XaoS fractal viewer program, which I did the Mac port for back in 1996. There have been improvements since then, but unfortunately Jan hasn't had much time to really get into it. Which is a shame, because XaoS is arguably the finest program in its class, and is available on lots of platforms.
Anyway, due diligence suggested I take a serious look, because XaoS fits the Daylon Graphics mission statement quite well (graphic, affordable, and good). Since its GPL'd software, all my changes would also be available under the GPL. This is okay, because the chargeable value-add for such a program is its support and the convenience of supported prebuilt binaries. It's also a good fit in terms of development resources: Jan writes very optimized graphing code, and my strength is in front ends.
Who would bother paying? I imagine not many people will, but I'm doing this for the research value. At this point in time, too many people talk about open source but not enough people actually experiment with it and learn what needs to be learned.
September 1, 2002
Updated the rest of the docs, including the SDK.
I noticed that the main Leveller toolbar had unused Print and About buttons on it, so I took them out and added a button to access the Colormap dialog, since that's a common task.
Well, unless anyone begs to differ, this puppy is ready to go. Just need to fluff the installer and figure out a new splash screen graphic (still), and that's it.
August 30, 2002
Updated the Flatten tool. It now has a "Smooth" checkbox that lets you brush in flattened areas that merge smoothly with the heightfield, as this pic shows.
It also does heightfield sampling to set the elevation. Just right-click on the map, or (if you're zoomed in) Ctrl-right-click to get the precise interpixel elevation. This is handy if you're sampling a steep slope and want an elevation between two pixels.
When pasting as a new document, the selection shape becomes the new document's selection mask. You can then use it, e.g., to discard the unselected pixels.
August 29, 2002
Was rereading Ivan Sutherland's article on asynchronous computing in this month's Scientific American. It's an old idea that keeps getting ignored because it's much harder to engineer chips whose parts run with independant timing, and so far the current synchronous technology has worked well.
The article points out several advantages to async operation, but I'm intrigued because such behavior is a cornerstone of proper A.I. modeling in neural networks. Basically, it's hard to have meaningful intelligence without free will, and there's no free will in a synchronous system because everything is predetermined. Or to put it the other way, a truly asynchronous chip could behave nondeterministically, and that suddenly makes things very interesting.
Leveller 2.2 got much closer to shipping today.
Supporting the public heightfield clipboard format in a useable way meant interpreting its "scale" and "size" tags, and now that's in. If you have a heightfield measuring a square kilometer and you're pasting it into a document with a different world scale, you normally want it to resize to keep its real size. It also makes slope preservation a snap. For those times when you do want the heightfield to keep its pixel dimensions, there's a new "Paste Raw" command.
August 27, 2002
Tweaked a few things that we're a little annoying, like the map pane going pitch black after resizing the window. I'm also testing size/scale support in the public clipboard format, so that heightfield slopes and realworld sizes are preserved when pasting into Leveller.
The fullscreen mode feature got cut. It was never really implemented properly, and it was causing 2.2 to crash something fierce. Even when it works, it's dangerous because Leveller is still running behind it, responding to any received menu commands, DX messages, etc. It's not hard to accidentally put the computer into a state where there's a modal dialog needing input but it's totally obscured by the fullsize scene window. When the feature goes back in, I'm going to do it right instead of hacking it.
The 2.2 beta is looking pretty good now. If a release candidate hasn't arrived, it's got to be right around the corner. Despite the large number of people trying it, the bugs have been very few and the reactions to the new features favorable. Some UI aspects (like menu items) had to change, and there's always the potential of irking someone who's used to the old ways, but so far everyone seems happy. It's the Leveller you've always known, simply better. :)
Managed to download the ISO image of the first Mandrake 8.2 CDs and install it on the 200 Mhz PC. I was disappointed on three counts: 1) the installer draws its windows so that they are unmoveable and obscure each other (!), obstructing things you need to read, 2) programs take forever and a day to start, and 3) the fonts are still damn ugly and have weird amateur names. Once you boot into X, the installer keeps going and pesters you with an online Mandrake account signup, using this unbelievabely broken browser applet. You can't tell what input field has the cursor, it doesn't accept text after a while, and retrying made all the form buttons pile on top of each other. Isn't there, uh, an old saying about first impressions being the most important..?
The graphical aspects can be fixed; indeed, I've seen better Linux desktops cropping up. But I'm thinking that 200 Mhz, while technically runnable, is going to drive me nuts before the port is finished. Qt Designer is sluggish on an 800 Mhz iMac, so it would be ridiculous on this thing. It would have been nice to save several hundred bucks, but I gotta be practical. Every unnecessary delay has to be multiplied by all the people who are waiting. Maybe I should just marry a rich woman and solve my budget problems once and for all. :)
It's at times like this that I always reflect a bit.
One thing I've noticed is that programming hasn't changed much. Java has been around for seven years and I'm still using C/C++. Microsoft's .NET has been out for a year or two, and Qt has been out longer, but I'm still using MFC. I suspect I'm not alone in this either.
The easy explanation is compatability: a project starts in one form, accumulates mass over the years, and changing it simply becomes too much work. Besides, C++ and MFC are far from broken, even if they might be showing their age.
Even if I changed tools, it's not the sort of change that would exude novelty. Java isn't really a paradigm shift -- it's basically C++ with generally better memory management and more modern ideas about OOP semantics. But I'd still be writing code with a text editor, compiling it down into something that the machine (even if it's a virtual machine) can execute, debugging the inevitable bugs with a debugger, and so on. The underlying system and its processes would remain unchanged.
I harp on this because when I started programming, the field was alive with excitement. New things were happening left and right. Innovation poured forth from big and small companies alike, even from individuals. Trade shows and conferences were fun. IBM was the closest thing to a computer monopoly, and they hadn't even released the PC yet. Microsoft was just another company, and Intel was just one of several chipmakers.
Every industry matures, of course. Airplanes used to be exciting, too, back in 1920. New speed and altitude records were being set all the time. But the laws of economics and physics met around 1970, and since then, the Boeing 747 has basically defined the state of the art. Improvements today revolve around little things, like adding personal viewscreens for each passenger. Fundamental change in passenger aircraft has reached the totally exotic (and incredibly expensive) point, because only a total redesign will do it. That's why the next jet is shaping up to be a huge wing job, or some for-the-rich-only scramjet Concorde beater. It's so major a change that it affects not only the aircraft but the infrastructure around it: you obviously can't park or taxi a flying wing in a normal airport. And once that change finally happens, the next one will probably be another 30-40 years out, because who will have the nerve (or the cash) to overhaul the industry again?
Programming is in great need of a truly overhauling paradigm shift. People have been saying this for years already. I remember a coworker (a strong C++ coder) emphatically telling me that "Writing apps, even small ones, just takes too damn long. There's simply no time anymore. I don't need to go from concept to prototype in a few days. I need to go to shippable product in a few days."
To be fair, he wasn't talking about a product like Leveller. He was developing small in-house tools between ten to twenty percent of its size. But still, it shows the tremendous pressure developers are under. The world is moving faster and faster, but we're still coding like it's the 1980s.
We've had, and are improving, our componentware models. Apple tried OpenDoc. VB has ActiveX controls. Java has JavaBeans. .NET promises an even smoother experience. But unless you're developing something generic, you'll need to make your own components, at which point you're coding in something C++-ish anyway. Not to mention version control, interface conflicts, dealing with extra vendors, etc.
An outsider might wonder: if we're doing our best, then what's the problem? Does it all really need to happen so quickly?
Perhaps not. But from my own vantage point, I'm starting to think, doing my job in the same way all the time isn't what I signed up for. I expected things to be more streamlined by now. I certainly expected one should be able to develop for different platforms easily and without any distribution or performance compromises. And I'm starting to seriously think that, if I'm going to undertake a new project, perhaps it should be something that addresses these issues.
I've seen some promising steps. Charles Simonyi of Microsoft wrote about Intentional Programming back in 1995, predicting productization by 2000. It's all about letting developers write programs by expressing design and algorithmic intent rather than code using a particular set of language semantics (like C or Java). Too bad it didn't (apparently) happen; all we have so far is .NET's attempt to make C-style languages "skinnable". But his ideas have great merit; just read his white paper. There's also Eidola, a more recent contender for representation-independant programming. Hey, if you gotta dream, dream big. :)
August 25, 2002
Finally found a use for the empty Layer Tabs panel above the map pane. It now holds a row of buttons that toggle the various map overlays.
August 24, 2002
The 200 Mhz PC ran Leveller 2.2 okay, although map redrawing was a little slower than before. It's not unexpected, because the consolidated appearance manager furnishes pixels on a buffered basis, and therefore an extra internal blit has to occur. But it's minor: at 600 Mhz it's nearly unnoticeable, and many people have faster machines than that. The raytracer was sluggish but not unbearable. However, using even the fastest dot product lighting mode on the map (the "Good" setting) was painful.
I had an old Storm Linux CD, so I made a boot floppy from it and gave it a whirl. The installer was nice but it choked on writing LILO (the boot loader). The problem seemed to be that the partition it was placing itself onto couldn't be booted, but although it could see the other available partitions it refused to install on any of them. I thought of booting a DOS floppy and FDISK'ing the whole thing, but then I found my original Mandrake 6.0 CDs and they went alright. Kind of a shame, since I was looking forward to seeing what a Debian-based distro is like, but on the other hand, Stormix isn't around anyway, so it's for the best. And I only installed Linux today just to see if my hardware was recognized (which it was); Mandrake 6.0 is too old for current development.
The beta goes on. Found some bugs and promptly fixed them. The docs are being worked on, which of course is always a chore. Testing is complicated by having to write a few external apps to exercise some of the new interop features, but it's gotta be done in order to do it right, so...
August 23, 2002
Well, after finally procuring a soldering iron from a friend, the ancient 200 Mhz PC went on the operating table.
And the operation... was a success. For those bedeviled by motherboards with Houston Tech "HT12888A REALTIME" CMOS chips, desoldering the battery and replacing it with Radio Shack part no. 23-9043 (3V lithium CR1220, about the size of a dime) appears to work okay. I added wires in case I ever have to do this again, because soldering the battery directly to the chip requires more finesse than I'm capable of.
I'm just glad they had invented automatic HDD type detection in BIOS setups that far back -- of course I had no idea what the cylinder/sector count was for the hard drive.
The machine is... hmmm... from 1997, so that makes it five years old. Since Intel is releasing a 2.8 Ghz CPU, that means raw clock speed has increased fourteen times since then. I wish I could say the same for hard drives... Scandisk doesn't run noticeably slower on it. Before I wipe it for Linux, I should benchmark Leveller on it, now that I have a faster machine to let it race with side by side. Be interesting to see how Virtual PC on the iMac compares.
Well, enough of that. This isn't BYTE Magazine's Chaos Manor, and as good a writer as I like to think I am, I'm not Jerry Pournelle either. :)
August 22, 2002
Things are looking up. Requests for the Leveller 2.2 beta are exceptionally strong. Maybe it's because school is about to start, or that 2.2 is more of an update than 2.1 was. Well, whatever the reason, more eyes are better.
I've been thinking about the long-term health of the company, and adding a second software project sounds good. The trick, of course, is to pick the right one.
A product for the enterprise market is one idea, but it conflicts with the mission statement.
Doing a bitmap editor would be easy. It wouldn't, of course, be as full featured as the others out there, but it'd be inexpensive (the way Paint Shop Pro used to be), run on Windows/Mac/Linux, and for Leveller users, the interface would be nearly transparent. Since I did prepress, CMYK support would be in from the get-go.
I can hear some of the experts shaking their heads at the word "easy". Okay, I mean relatively easy -- of course a decent paint program is a complex piece of software. But you can imagine how quickly version 0.1 would be up and running.
A Flash content generator would be nice, considering what Macromedia Director costs.
Helping out with open source office apps would be neat, assuming it paid alright.
A video game is possible, but they're too sophisticated now. You need a team of at least six people and a killer dev/marketing budget or publishing deal. The shelves are crowded to bursting with the things anyway. What we need instead is a program that yanks kids away from the TV and makes them go hiking.
And on it goes.
Maybe I'm going about this the wrong way. There's already a zillion little apps out there. I should just take a few days off and give them a run-through and pick the five or ten that make sense to do more upscale.
August 19, 2002
Well, the first 2.2 beta is finally out. Let's see... I started May 20th, so that makes it three months. That also means it took exactly three months for 2.1 to ship, because I started it after leaving EA on February 19th. Hmmm... interesting coincidence. If you want the beta, just e-mail Support. It installs over an existing 2.0 or 2.1 setup.
Looking at the change log, time was spread pretty evenly on features, improvements, and fixes. Which means there's always a ton of old stuff that needs to be addressed with each revision.
I privately call this version "the gamer's release" because the changes are more in secondary features like markers and grids, textures and raytracing. A lot of game developers asked for the markers, and it's good to have a high-priority item like that finally off the wishlist. The modeling hasn't changed, except that the brush effect preview is easier to see.
This is also a new high in interoperability. Two public clipboard formats have been added (a very basic text format and a comprehensive binary one), as well as a customizable Tools menu to launch other apps with and pass them arguments.
Got the first version of the public heightfield format code working. It's sweet: I have a test program place elevation data on the clipboard, and then Leveller pastes it. It looks simple, and it is, but the magic is when you realize how it's much easier than exporting/importing files. The first beta should be out later today. I had to leave out nonstandard heixel bitdepth support, because at the last minute it dawned upon me that such heixels might not be byteswapped even on Intel platforms, and that had messy ramifications for signed numbers, so the spec has to be clarified before I proceed with that part.
Ms. Blais asked about mapping textures onto vertical surfaces better, and that got me thinking about material maps, multitexturing, and scanline rendering. There's a very good chance I'm going to do that for 2.3.
Now that GCC 3.2 is real, it's a good time to ponder Linux. With any luck, by the time I start porting Leveller, Red Hat or someone else will have a totally recompiled distro. The LSB stuff is good too; who wants to produce builds for multiple targets on the same processor?
Still, my personal road to Linux has been rough. I dusted off an old 200 Mhz PC since I like to give each OS its own box, but the machine had been lying around so long its CMOS battery had died. And its one of those Houston Tech '888' jobs, where they tell you to replace the motherboard since the CMOS and battery are soldered. Yeah, right.
This is where being a former hardware technician comes in handy. Taking the thing apart, removing the mobo and desoldering the battery off, etc. will take time, but not much is happening since I'm only working on Leveller and doing the soulmate search. :) Unless someone wants to kindly donate an equal or better PC, I'm prepping for surgery.
Thinking of Linux, of course, makes one think of open source. So I read Brian Behlendorf's well-written essay Open Source as a Business Strategy, and carefully considered (yet again) if it was time to publish Leveller that way.
Not yet, it looks like. Behlendorf's essay helps explain why. Bottom line, Leveller's just not the kind of project that would offer enough value to its maintainers, and the thing would languish. I remember (and liked) KLevel; but it's been dead for a while now. HF-Lab and HLA sparkled for a while and then interest waned. These are not big infrastructural projects like Apache or GCC where someone can make a good living on a consultancy basis. And right now, that's pretty much how it's done in open source. Behlendorf does an exceptional job because instead of just preaching solely the virtues, he also objectively explains what open source is unsuited for.
August 16, 2002
Mandi Blais sent in the Terragen pic below, and mentioned she's getting into BMRT (Larry Gritz's Renderman-compliant radiosity raytracer).
The "Blue" in the Blue Moon Rendering Tools: Turns out Dr. Gritz put BMRT into Exluna a while ago, and Exluna is not distributing BMRT anymore due to some riff with Pixar. Sigh. If this is the 21st century, why are we still acting like it's the 20th? If I were Pixar, I'd negotiate a deal with its former employees. The smart money is always on those who are pushing the envelope. People who retard progress eventually get surpassed and fade away.
Makes me think about adding radiosity to Leveller's raytracer. Wouldn't that be neat? The basic concept is very simple. It's also very slow, because, like raytracing, it's brute force: for each visible patch of an object, you render the scene from the patch's point of view so you can determine how much light (and what color of light) the patch is hit by. This produces scenes whose illumination is much more natural. The size of a patch is implementation-dependant, but the smaller it is, the more accurate (and slower) the results.
As for progress, Unisys' LZW patent expires June 2003, which is just ten months away. I actually thought about paying them the two-three bucks per licence so I could add GIF and proper TIFF support to Leveller, but with the patent dying so soon, what the hell. Once it goes, I wonder if PNG will be popular anymore... like VHS vs. Beta, everyone might decide it's just easier to use GIF once it's free.
August 14, 2002
The Vancouver Sun newspaper had an article today on a new inexpensive Sony camera that records both video and depth information. The accompanying photo showed a connected notebook PC displaying an image of a teddy bear and a 3D elevation mesh of the bear's surface. Getting the depth data into Leveller will hopefully be easy.
Bob McNeel at Robert McNeel & Associates sent over an NFR copy of Rhino, so I could try out the upcoming Rhino 3.0 SDK and make sure Leveller can export meshes to Rhino. The manuals are really classy; color screenshots everywhere. I feel guilty reading them because the glossy covers show fingerprints really well. :)
There are so many secondary Copy commands in Leveller that I moved them to their own "Copy Other" submenu. Also, the alpha channel data in the selection mask can now be copied to a grayscale bitmap (instead of having to export it to a bitmap file).
The Tools menu is now working, and I added variables that can be placed into a launched app's arglist, like this:
hfreport.exe $(FilePath) $(MapCol) $(MapRow)
which would resolve to something like:
hfreport.exe c:\docs\hf.ter 203 94
So one can point at a spot on the map, invoke an outside program, and have that position evaluated.
August 13, 2002
Uploaded a new utility called TERDUMP. It dumps the contents of a Leveller document to stdout. Available here.
The API v9 changes are in, so now it's just the Tools menu and updating the docs, and Lev 2.2 will go beta.
August 12, 2002
Uploaded the new Binary Terrain plug-in, which supports VTP BT formats 1.0 through 1.3, UTM, etc.
Tweaked the public heightfield clipboard format spec a bit more, and provided some sample parsing code for it. I think it's very close now.
August 11, 2002
Got some more hi-res texture pictures made. You can grab them from this page under 'Sample textures'.
Critical Thinking 101: Reading Robert Sawyer's Calculating God. Good book
so far. I can't spoil the ending for you because I haven't
reached it myself yet, but so far it's very entertaining.
Aliens visit Earth and claim that God does exist.
On a
similar note, I came across the June 2002 edition of
Discover magazine's article on John Wheeler's theory
that observations create reality, and was glad to see
that I had independantly come up with reasoning similar
to his. He says that starlight used in the two-slit
experiment forces it to retroactively assume a
particle or wave existence once observed, despite
being emitted many years ago, and
since relativity makes light travel in zero local time,
I figured the only way we could have free will is
if light existed in a probability matrix prior
to being observed. If that last bit went by too
fast, don't worry, the details are
here.
Finally got default document and view template loading working in Leveller 2.2. Talk about handy: I saved my test document and its view settings as default.ter and default.lvw, respectively, placed them in Leveller's application folder, and now whenever I start Leveller or create a new document, my test file is already opened with the nice Earth and Water colormap.
Since markers are stored using a text representation, it became trivial to add clipboard support for them. Hence, markers can be cut/copied/pasted. I originally planned to support it later, but as I was using markers myself, I found myself trying to copy/paste them since it's the intuitive thing to do, and realized how it would tick others off not to be able to do so. I could sum it up as a GUI law: if you offer a feature that presents manipulateable objects, they're incomplete without clipboard support.
Leveller 2.2 will have plug-in API version 9, which adds something I should have dreamed up much earlier: generic property access. Think of a running instance of Leveller as a database, and its member objects as records, and the new API functions as being SQL. Instead of groping for data using specific structures and functions like this:
// Get the position of the last marker. int numMarkers; LEV_MARKER marker; gpLeveller->fnGetMarkerCount(LEV_ACTIVEDOC, &numMarkers); gpLeveller->fnGetMarker(LEV_ACTIVEDOC, numMarkers-1, &marker));
You do it like this:
LEV_HANDLE hMarker =
gpLeveller->fnGetObject("/docs/current/markers/last");
if(hMarker != NULL)
{
LEV_VECTOR3D_PRECISE pos;
pos.x = levutil_GetObjDouble(hMarker, "pos/x");
pos.y = levutil_GetObjDouble(hMarker, "pos/y");
pos.z = levutil_GetObjDouble(hMarker, "pos/z");
}
Basically, the specifics about what objects exist is moved
from the function and structure names into the argument
of the accessor function. Now we don't have to worry about structure typedefs changing or becoming obsolete, etc. If you don't
want to gain object handles, you can even do this:
double x =
levutil_GetDouble("/docs/current/markers/last/pos/x");
August 8, 2002
Getting down to the short strokes; just a handful of items on the to-do list and then Leveller 2.2 goes beta.
Had to implement .notdef glyph support in the custom font system used by the updated map renderer; the font rez (for now) only has codepoints 32-127 defined but of course one can input other codepoints when editing marker text, so...
I came across the term heixel while reading the VTP (Virtual Terrain Project) FAQ. Like the way "pixel" does for pictures, a heixel refers to a single element of a heightfield.
It's exactly the kind of thing that makes me laugh at first glance, and then quiet down and think, hmm... that actually sounds pretty good, in a way. It's clever: just take the words "height" and "pixel" and there you are.
But the question becomes: should I go and change (in Leveller) every use of "pixel" to "heixel" when referring to heightfields? It's tempting, but it's not hard to imagine a lot of people not sharing the same tastes and becoming very upset. A preference setting would work, but that'd need a lot of coding.
Hmm... heixels... heixels... sounds German, somehow. :) I can just imagine Arnie reviewing a modeler: "Dumpkoff! I zaid to smoozhen ze heixels unt you inzstead zharpen dem! Now fixen ze heixels, schnell! Mach schnell!!"
August 6, 2002
Turns out the bilinear resampler in the Edit Grid Size command was faulty. Now that it's fixed, reducing a heightfield's size produces great results. The bicubic resampler is only good at enlarging, and I don't think I'm going to bother making it work at reducing, since that's not really what it's for. When you enlarge, you need to stretch a few pixels smoothly into many pixels, but when you reduce, you want to take many pixels and average them into few. And the bilinear resampler now does an excellent job of that.
In anticipation of working more seamlessly with third party applications such as Stephen Schmitt's World Machine, Leveller now detects when an open document has been externally modified and asks if it should be reloaded. This way, you could open a TER file, modify it elsewhere, and have it reload and redraw in Leveller each time.
The TER format has to be bumped up to version 5 because markers need to be stored, and it would be too dangerous to let older versions of Leveller open a document that had markers, and then destroy them when saving. By incrementing the version, older copies of Leveller will decline opening such files, thereby avoiding potential data loss. If you want to override it, you can always hack the version ID byte back to 4. If you're going to that trouble, it's safe to assume that you really want to open a version 5 file despite the risks.
August 2, 2002
In case you were wondering what the entire Leveller screen looked like as a lit heightfield, here it is (click to enlarge):
I placed the light in the upper right, because honestly, haven't you always wondered how the Windows GUI elements would look if the light were someplace else? :)
But to really drive the effect home, here's the same screen but with the light hovering just above the screen and inside it (click to enlarge):
Okay, admittedly that's impractical. But it would be a cool way to start up a computer, with the "sun" rising and the windows slowly becoming visible as the shadows dispersed. Or if a shutdown (or crash?) occured, have the sun fall down and plunge everything into near-darkness instead of darkening the screen. Urgent items could be extra bright, drawing attention as they float around. Braille text could be in a bumpmapped font with force feedback mice for the visually impaired, etc. The possibilities are interesting.
One thing I did notice, however, is that the process is great for building 3D widgets with correct lighting. Some people model widgets and raytrace them, but you could also make a heightfield and just light it. The advantage with the latter is that you can experiment faster.
A Marconi Planet(tm) user asked how to read that product's elevation data. Turns out they're just plain raw binary files. The import details for Leveller are available on the FAQ.
August 1, 2002
The raytracer depth map and gapping bugs when rendering large heightfields seems to be fixed. Floats instead of doubles were being used internally, but switching over didn't incur any noticeable delay.
I've been asking around about standardizing on a public heightfield clipboard format. The details are available here. Way I figure it, if bitmaps can be copied/pasted between different apps, so should heightfields. Depth information is getting more mainstream all the time, especially now that video hardware is supporting it.
In fact, maybe it's time today's GUIs got a facelift. Instead of faking a 3D appearance, why not incorporate actual depth information? Here's what the top of the Leveller window would look like, for example:
The first picture has the light shining from the traditional upper left location, while the second picture has the light over to the right. If you wanted, the computer could move the light according to the time of day to simulate the sun's location, making the shadows in the GUI match the shadows in your room.
How were the pics made? I used a screenshot to develop a heightfield, and then stripped out the lighting effects from the screenshot and used it as a texture:
July 31, 2002
Here's how markers look in the scene pane:
Also added a Go to Markers... command to make looking at markers easy:
July 29, 2002
Got a little sunburned back on Friday, so work took a slight hit (sigh). The ozone hole problem must be worse than I thought; my usual sunscreen factor doesn't do it anymore. :)
Anyway, things are back to normal, so, after discussing Leveller's UI with Lars Norpchen (he of Spectrum Holobyte and Maxis fame), I spruced it up. Specifically:
- Clicking and dragging the middle mouse button
pans the map.
- Rolling the mousewheel forth and back (if your mouse has one)
zooms the map in and out.
- Pressing Alt and the +/- keys on the numeric keypad
zoom the map in and out. If the mouse isn't over the map,
the zooming is centered on the map window.
- Ctrl+Space toggles between the current tool and
the Pan tool (and only the Pan tool).
July 25, 2002
I sometimes wonder how people managed before Google. I periodically use it to see how Leveller's being referenced. The results were interesting and fruitful.
Knowledge is good: Brian Smith of the University of Maryland used Leveller to help write his M.Sc. thesis entitled "Realistic Simulation of Curling and Breaking Waves." Rob Harris and Ellen Do discuss Leveller's approach to terrain modeling in their thesis "Digital Sandbox". And Tom Patterson briefly mentions Leveller in his nicely illustrated DEM-and-Photoshop paper entitled "DEM Manipulation Techniques used by the U.S. National Park Service."
July 24, 2002
I noticed that the elevation readout tooltip has the annoying habit of vanishing whenever a selection is present, or at best it flickers if you move the mouse (but then it disappears the moment you stop the mouse). So that's been fixed. Not only can elevations be read with a selection present, but one can easily determine what the elevations are underneath a floating selection.
Another nice side benefit is that if you're pressing F3 or F4 to smooth/sharpen, the elevation tooltip changes accordingly instead of hiding. So one can hold down or keep pressing the keys until the point under the mouse reaches a desired height.
Went rollerblading today around Stanley Park. What's interesting is how the pavement varies in quality from perfect all the way down to utterly atrocious. It is, however, a good way to not just see the bumpiness of a surface but to appreciate fully its feel. It occurred to me how neat it would be, in a video game, say, to be able to feel the roughness and other undulations of a surface while navigating a dark room. With bumpmapping becoming prevalent in games, this is an easy next step (assuming haptic interfaces become popular).
July 23, 2002
After considerable thought, I made the elevation tooltip and marker captions use antialiased, slightly larger text, and toasted the tooltip's white background rectangle.
July 21, 2002
Adjusted the way Leveller documents are accessed as part of an investigation into why sometimes saving doesn't work on network drives.
Completed the markers feature a bit more. One can set their IDs and labels, and they appear on the map with customizable positioning.
July 19, 2002
The Surfer GRD import/export plug-in is released.
Redesigned the Map Properties dialog, and rounded out the list of overlay items properly. The camera/line-of-sight bar will be hideable now.
July 18, 2002
A truly objective worklog discusses the bad as well as the good. And today was a textbook example of the bad.
Lost five hours hunting down a bug in the texture manager to support auto reloading of modified bitmaps. Turned out I typed '==' instead of just '=' in a C++ assignment expression.
Yes, increasing the compiler warning level would have caught that (amidst a zillion other warnings somewhere), but considering this happens to me really rarely now, losing a few hours once every blue moon is more efficient than going through all the code and making it perfectly warning-free. I will do it someday, just not today. If there's one thing I learned in this business, being extremist about doing a perfect job isn't practical, unless you're writing software for the Space Shuttle.
Upon reflection, I actually feel good because I got a genuine workout in the troubleshooting department. Without challenges, it can be hard for veterans to stay sharp or remain humble. And as annoying as bugs are, there's also the exhiliration of finally crushing them. It's all part of programming.
Anyway, I got the auto reload feature working enough to give it another run-through, and it's really neat. You attach a texture, then modify it in a paint program, save it, Alt-Tab over to Leveller, and the modified texture is automatically applied.
July 17, 2002
The Surfer import/export plug-in is just about done, and now it supports all three Surfer .grd formats.
The main work on Leveller 2.2 is wrapping up, so now's a good time to look over the changes and see what will be in this new release:
• Marker tool. Markers can have one-char ID, variable-length name, longer comment string, and floating-point inter-pixel location.
• Regular gridlines on map view.
• Interactive water level adjustment tool.
• Masked (alpha channel) textures.
• Bilinear texture filtering when raytracing. Texture alpha channels are also bilinearly filtered.
• Automatic reloading of textures when the texture file is modified.
• Copy/paste elevations as tabbed text.
• Map Navigator dialog.
• World units labeling.
• Automatic loading of view (LVW) file which has same base name as the document (TER) file. Now entities like colormap, normal render style, map pane settings, etc. can be automatically set when a document is opened. It's a stopgap measure until the TER format is overhauled, but it's easy to implement, and works well in the meantime.
• Off-by-one horizontal map texturing bug fix.
• Fixed JPEG texture export to POV-Ray 3.5.
• Properties window shows heightfield surface area and memory usage stats.
• OpenGL nearplane default bug fixed.
I streamlined the way updates are built, so there will be an updater for both 2.0 and 2.1 users.
July 16, 2002
Worked on the new Surfer import/export plug-in.
To make exporting easier, I added "Calc" buttons to autocompute the elevation and width/breadth ranges.
There are apparently three types of Surfer grid files: ASCII text (DSAA), Surfer 6.x binary (DSBB) and Surfer 7.x binary (DSRB). Right now the first of these is up and running.
July 15, 2002
Got quite a bit done today, despite a local power outage in the evening. Apparently a bird took took a fancy to one of the few above-ground transformers nearby. :) No harm done, since I learned long ago to connect all computer equipment to uninterruptable power supplies. I can't stress strongly enough how necessary those things are. Before I had them, a brownout toasted my video card. The things pay for themselves in short order.
Rounding out the markers interface required a change in the way some commands (e.g., Clear, Select All, etc.) behave. I made some markers, pressed Ctrl-A to select them all, and of course the heightfield got selected instead. So what I did is made those commands see which tool is current, and if it's the marker tool, the command is directed towards the appropriate objects.
The problem occurs because of a slight design no-no: ideally, a document doesn't have modal components, with each one possessing its own selection lists. Selecting a marker, for example, should deselect the heightfield (and vice versa). However, a new problem emerges: what to do for a Select All. Select the heightfield and all the markers? I thought about it, and realized that this is a case where the "right" thing is worse than the "wrong" thing.
To be fair, I also briefly considered duplicating the commands, so we'd have "Select All Markers", "Select No Markers", "Delete Marker", etc. But that way lies madness -- imagine what happens if more features needing their own selection lists are added. And it's unintuitive -- as I created markers and moved them around, it was perfectly normal to press Ctrl-A when I wanted to select them all; the last thing on my mind was learning a new command. The rule "be modeless" is a good one, but it can backfire when taken to extremes. In any event, 2.2 will have the usual beta period, so there will be time to get feedback and fix the interface if people don't agree.
There is, unfortunately, a showstopper. :) I haven't yet figured out what picture to make for 2.2's splash screen, and tradition requires a new one with every official release. All I have so far is a rough idea about a heightfield viewed on a low angle with a grid and a bunch of marker spheres hovering over it.
July 14, 2002
Added the marker tool, which lets one move, select, and otherwise manipulate markers:
July 12, 2002
The markers feature is coming along. Here's a view of a bunch of markers at two different zoom levels:
I was going to make the markers really spiffy-looking, but time grows short, and the important thing is to get the basic functionality done. Later on, there will be time to add more appearance prefs. The blitter that draws the markers is alpha-channel based, so it is scalable to do e.g., translucent gems, if one wants.
July 10, 2002
POV-Ray 3.5 has been released (yay). The good news is, existing POV-Ray 3.1 files exported by Leveller are compatible with 3.5.
POV-Ray 3.5 supports JPEG imagemaps. However, after exporting from Leveller, you need to change the "jpg" keyword in the image_map instruction of the POV-Ray script file to "jpeg" (this will be done automatically in Leveller 2.2).
The bad news is, while testing masked textures in Leveller 2.2, I discovered that POV-Ray interprets bitmap alpha channels opposite from normal: alpha values of zero (which normally appear black and are opaque) appear transparent in POV-Ray, and vice-versa. It's apparently a feature, since it's noted in the POV-Ray help file:
"Although POV uses transmit 0.0 to specify no transparency and 1.0 to specify full transparency, the alpha data ranges from 0 to 255 in the opposite direction. Alpha data 0 means the same as transmit 1.0 and alpha data 255 produces transmit 0.0."
No point changing POV-Ray, even if they would: it would break too many existing scene descriptions. Only two options come to mind: 1) Add a keyword to reverse the alpha channel interpretation or 2) Have Leveller export an extra texture bitmap with its alpha channel reversed. For large textures, however, this can be hard on disk space.
POV-Ray 3.5 supports bicubic patchmeshes, Mesh2 meshes, and UV mapping. I definitely have to look at getting Leveller supporting these features.
July 9, 2002
I was going through the wishlist for other changes people had wanted, and came across easy text editing for elevations. Since spreadsheets "excel" at that kind of thing, I added tab-delimited text clipboard support.
Elevations are interpreted in world units. If the selection is irregular, unselected pixels become empty cells. Even a modest selection can generate a lot of text, however, since each elevation value can easily take seven or more bytes in text form (and the same reason ASCII DEMs are so huge).
July 8, 2002
Got my pics back from the photo store. I went up into the local mountains near a lake to get some beach textures (they're available on this page under 'Sample textures'). At the same time, since everyone keeps making "natural" scenes with computers, I thought I'd take a picture of the real outdoors just to remind me how good reality is. The fog rising from the trees is pretty cool too; you don't really see that in computer renderings.
The 2.2 beta should start soon. I'm going to add the markers feature over the next few days, and that should do it.
July 6, 2002
Got the Map Navigator window working. This lets you quickly pan to any part of the heightfield by simply clicking and dragging on a full scaled-down map.
By default, the Navigator window overlaps the scene pane, but one can change this, and Leveller will remember the window position and size you prefer.
July 3, 2002
Added a world units label feature, so Leveller can report elevations as meters, feet, etc. instead of just "world units". The plug-ins won't exploit this feature automatically; they'll have to be updated. The Properties window now includes a readout for the heightfield's surface area.
Made a bitmap sampling error while overhauling the heightfield appearance class. The top 64 pixels were okay but the rest we're coming from unallocated memory.
It looked neat, however, so I thought I'd share it. Reminds me of a weaved blanket. What's funny is that it also reminds me of how what we see on our computer screens is an illusion, a continual interpretation of the raw bytes in RAM. When memory contents appear directly, one feels as if a curtain is being pulled back and "the true gridwork of the Matrix" is at last visible.
Older Notes