Masked textures are finally getting in. Here's a sample:
Also got bilinear texture sampling working for the raytracer:
June 29, 2002
Working on a Saturday. Oh well, when you run your own show, it's hard to tell the days apart. :)
Finally started consolidating the heightfield appearance code. For speed reasons, several classes had their own customized copies of it, but I figured out how to centralize the code without a significant speed drop, which is great because now that I'm adding alpha channels to textures, it's getting too painful to update the appearance code the old way.
June 26, 2002
Finally got the Mac TERDISP utility good enough to share (well, if I may humbly say so). There's some strange problem with the colormap getting posterized, but otherwise it's coming along nicely. If you want to try it, just click here. Note: only Mac OS X is supported.
When you open a TER file, be careful to open only those files ending in ".ter". Filtering out other filetypes in the file dialog is still being worked on (apparently, it's not trivial if the filtering callback needs to know the name of the file or its contents, sigh).
June 19, 2002
Turns out I was wrong about the OS X system font being hard to find. It's Lucida Grande (14pt in the menubar, 12pt most everywhere else).
OS X is schizophrenic, unfortunately. If you run TeachText, it renders Lucida Grande the way Aqua does. Most other apps (including AppleWorks) render it thinner and uglier. So does Qt, unfortunately. I suspect it has something to do with whether an app calls the Quartz render engine or the older QuickDraw APIs. Here's a pic to show what I mean:
With Illustrator added, you get three different ways to render the same font. Amazing. For a company that builds both the hardware and the software, you'd think they could make fonts render consistently.
June 18, 2002
I guess Macintosh fans will be happy to hear that I spent today evaluating Trolltech's Qt cross-platform software development framework. With little more than a recompile, I could have Leveller building on Windows, Mac, and (later on) Linux.
Installing Qt, building the test apps, and playing with the GUI designer all went okay. The architecture of the C++ framework is nice. The layout feature in the dialog editor is a godsend. But...
Qt's GUI widgets under OS X are damn ugly.
The user interface is the thing you're staring at day after day, week after week. It has to look good. Whatever font OS X uses to draw menu items with is hard to find. It doesn't show up in the font dialogs. And Qt doesn't use it by default. Instead, it uses some thin Geneva look-alike that turns the Aqua interface into a default KDE knockoff. Mac support was only added recently to Qt, so I'm guessing this is an early release problem.
It's always something, isn't it? :)
June 16, 2002
Got the Wavefront OBJ plug-in released. The original version used too much memory on irregular selections, so it got overhauled. Worst case, it needed as much memory as the heightfield itself. Some plug-ins can't avoid doing that, but that wasn't the case here, so...
Man, what a process that was. Wound up rewriting the code four or five times. It's a textbook case of a problem that looks trivial but has subtleties to zap the brain. Except for the most straightforward situation, there's really no such thing as a simple mesh export if you want all the vertices to be unique.
It's easy if you're not constrained by memory limits, but let's face it: not everyone has tons of RAM, and even if they do, they could have other apps or documents open. Paging them out to VM every time you export a mesh is unprofessional. There are also post-processing solutions, where you generate all the vertices and then cull out the unneeded ones afterwards, but that a) runs slower and b) complicates things. Every time you add another temp file or a new step in the process, it's another chance for something to go wrong and cause problems. Spending an extra day or two on the code is nothing compared to all the time I won't have to spend fixing it later on.
June 13, 2002
Got a Wavefront OBJ export working. The pic below shows ChumbalumSoft's MilkShape 3D modeler after importing an OBJ exported from Leveller. Like the DXF export, you can limit the output vertices to whatever is selected. The plug-in will be up soon but if you need or want it beforehand just write.
One obviously gets a lot of triangles doing this. Your mileage will vary depending on how much RAM you have. OBJ supports curved surface patches but the plug-in doesn't do those yet. Later on I need to modify the TMesh plug-in to support OBJ. Milkshape has a progressive mesh plug-in, but it didn't work on the imported heightfields properly.
Currently rethinking the licencing process. Lately there's been a bunch of episodes where a person buys one licence, and simply transfers it to a friend/coworker/spouse/whatever when he/she becomes proficient at it. Only problem is, it skews the statistical user behavior needed to keep support possible. With transfers, I end up supporting, on a single licence, a "perpetual trainee". There's simply no economic balance to it. Historically, I could afford to look the other way when it was just a side thing, but now it's getting epidemic.
Kind of ironic, considering that most people argue strongly that software should earn its living from support. I agree, but this is like a new low or something. First people pirate, and then they start figuring out how to get me to spend time helping them... unbelievable. :)
June 11, 2002
Added an "Edit, Paste as New Document" command. Select some part of an existing document, copy it, then paste it as a whole new document. Handy. All the other pixels editors have this command, so it's high time Leveller did.
Changed the OpenGL near plane to 0.5 from 0.05. No wonder some solid views were getting Z-buffer artifacts. The far plane should be moveable farther out now as well. Tried 1.0, but it caused visible near clipping when the camera was 0.48 grid units above the HF.
Continuing the big crash course in GIS. I'm trying to make a USGS ASCII DEM exporter but the format specs read like the proverbial Stereo Manual from Hell (I don't even want to find out what the SDTS specs must be like).
June 5, 2002
Turns out there's a small bug in Leveller's "Selection, Feather" command which may be major for some people (smoothing some of the edge pixels in the selmask reads unallocated memory).
The algorithm was also on the to-do list for memory optimization, so I'm killing two birds and also doing that. It will be part of the 2.2 update. Anyone who needs the fix earlier can request the current 2.2 alpha.
May 29, 2002
Since gridlines are going into Leveller 2.2, the logical question becomes: what about geographic coordinates? Wouldn't it be nice for DEM users to have coordinates that read out in longitude and latitude? Although Leveller is strictly a heightfield modeler, the practical issue is that heightfields are mainly used for terrain.
Instead of trying to support all manner of projection systems at this stage, a good general solution is to support azimuth projections. The diagram below shows the basic idea:
These projections are normally used for polar regions, but they have the advantage of being able to map spherical areas onto planes from any point, with the distortion being constant regardless of which surface patch is chosen. It's also easy to rotate the plane about the projection axis. Standard Mercator (cylindrical) projection distorts heavily in high latitudes, but many planetary textures use them, so I'd probably support this too. Between the two systems, it's possible to map any part of a planetary body onto a heightfield and get useful results.
For azimuth projections, I'll probably forego datums (which describe the Earth as a slightly distorted spheroid) and just assume a perfect sphere. They can always be added later without disruption. The projection center can be placed anywhere along the projection axis, or even at infinity, producing orthographic projections. Basic ray/sphere intersection tests handle converting between heightfield pixel space and latitude/longitude.
Views of far north/south areas or polar regions will look interesting -- the latitude lines will appear curved, or even circular, in the map window, and longitude lines (meridians) will radiate from the pole.
May 25, 2002
The gridlines feature is taking shape nicely. I also consolidated a bunch of commands into a single Map Properties dialog:
May 23, 2002
Ran into a new bunch of Web articles about piracy, of both the musical and the software variety. As a person trying to make software more affordable for people, I'm always interested in how I can do that without going under myself.
Most people bring up the issue of cost. I think I've done everything I can in that respect. I mean, for one licence to Adobe Photoshop, you can get, what? Eight Leveller licences. And if you need eight, you can even get a bulk order discount. A lot of people cite $50 as a reasonable price. Well, $74.95 is pretty close to that.
I'm pragmatic on the issue. A person who doesn't mind getting his software from unofficial sources and who doesn't need support can obviously save a few bucks by copying. When most people do it, though, the effect has been historically obvious: I have to take a day job and progress starts grinding to a near halt. I don't make the rules, and I don't have any magical powers to go around violating basic economics. If you're dirt poor, that's one thing, but if you can afford to do the right thing, why not? It makes everything easier for everyone.
I think the support relationship is worth the licence fee (I ought to know; I've answered thousands of questions in the last four years). For anyone whose time is valuable, it's money well spent. They don't have to wrack their brains or be told to RTFM in newsgroups -- they send me an e-mail, and they get the straight dope within 24 hours. When you think about other companies charging $50 per issue, we're talking a good bargain here.
May 21, 2002
Added the text captions to the gridline view. Getting them to draw without flickering required revamping the old double-buffering logic, but it was good to do that anyway since it cleaned up drawing of other overlay elements. I thought of adding rulers and drawing the captions on them, but that would delay the 2.2 release.
May 20, 2002
Since I have a little more room with my new web host, I figured I'd add this new section. That, and also because for people who are really into Leveller, it helps to discuss the latest going-ons. People too often feel left out of the design process, and that's hopefully something we can address here. It can also be fun, like those "behind the scenes" documentaries they do for movies.
So... what is going on lately?
Well, since I finished with Electronic Arts back in February, I've had much more time to work on Leveller. Which doesn't automatically translate into all sorts of new features and changes, of course, since there is the small matter of running Daylon Graphics, and doing other things to pay the bills. :) But there is some stuff happening.
The website is slowly but surely evolving again. I started off by changing the color scheme for the navigation panel (The irregular pile of buttons to the left). I was too lazy to change their shape; doing that is a big chore because of the way the HTML pages refer to the image. Anyway, since getting a Mac and running OS X, I've been bombarded with its eyecandy Aqua interface, and I guess I got a little taken with it. It also made for a neat raytracing challenge -- you wouldn't believe the hoops one has to jump through to make blue crystal buttons look passable.
Leveller 2.1: Yes, it's out. You probably saw the big graphic on the product page extolling its, uh, numerous virtues. The main difference is that it does interactive dot-product lighting. This would have been in earlier, but when I started Leveller, computers were much slower, and dot-product lighting isn't for the faint of heart or slow of CPU.
What's funny is that just after releasing 2.1, I got the new Water tool working. Sigh... if I'd waited, it would have been in 2.1 instead. This tool is simple but very handy: it lets you interactively change the water level. You can click where you want the water to rise to, or drag with the right mouse button to raise/lower the water normally. The scene and the map update in realtime, which makes the whole process child's play. You just release the mouse when you see what you want.
I'm not too wild about the way the Water tool's button looks. Since this is all in development anyway, I just whipped it up in five minutes. It just would have been convenient if it had been good enough to ship with. If you have a better button image, I'm all ears.
I'm also (finally) adding a gridline feature. This simply draws evenly-spaced gridlines over the map. It looks like this:
As you can see, the effect looks crowded as you zoom out, because the lines can't get any thinner (since they're only two pixels thick). I'll probably provide customizable spacings on a per-zoomlevel basis, so the line density automatically lowers itself as you zoom out, and vice versa. I had to draw two sets of lines, one dark and one light, because a single color tends to vanish when it matches the heightfield color. I thought about using XOR'd drawing, but that fails when the background is 50% gray, and I want the lines to hold their color more constantly, instead of depending on what the heightfield color is. I also need to figure out how to make the gridline captions (the little numbers identifying what coordinates the lines correspond to) look nice. They should be readable, but not distracting.
I added some more links to the FAQ. The About Heightfields document also got modified.
What I'm really looking forward to is revamping the TER file format. This is Leveller's document format, and we all know what a pain it is to have view-related information (textures, water, map settings, etc.) stored in optional secondary files (which, unsurprisingly, people forget to create). I've gone and carefully itemized exactly what data is being stored where, and what it's for, so I'm on the path to turning the next version of the TER format into a true project file format. I want (hell, we all want) to be able to hit Save, close the file or quit Leveller, and when we reopen a file, to have absolutely everything come back the way it was.
On that subject, I also thought maybe I should stop using "TER" as a filename extension, since it conflicts with Terragen. Matt Fairclough was using it first, and if I had known, I would have picked something else since type ambiguity is a bad thing. The only fortunate thing so far has been that Terragen and Leveller actually store very similar data, so the ambiguity isn't life-threatening. I thought of using "LEV", but that would fall apart if the program's name ever changed (and that could happen; you never know).