Archives
Aug-Dec 2003
Apr-Jul 2003
Jan-Mar 2003
Oct-Dec 2002
Jul-Sep 2002
May-Jun 2002
Fixed a bug in the DXF import plug-in. It was confusing the data of non-vertex fields as indicating vertex entries, causing artifacts to appear (or just crashing).
Discovered the VCF (Visual Component) framework a few days ago, appears to be a more developed version of Abstract. It's API is not as high-level as I would have made it, but using VCF to implement Abstract would save lots of time.
May 7, 2004
Working on a GeoTIFF import/export plug-in. So far it's going alright; I'm writing a small test app to read elevation data from a GeoTIFF file and display it. Once that's working the code will be transplanted to a plug-in.
April 22, 2004
Recently got back from a road trip. Part of it was to meet a client in Ontario, from which several useful ideas about Leveller 3.0 emerged.
The trick with any program is to expand its feature set and user interface within whatever solution domain the program is about. It's too easy to go off in any of several directions that would totally change Leveller. Customers have lots of good ideas -- the challenge is to avoid any one of them compromising what other customers would want. If things get really tricky, often one has to be honest and define two or more programs to address what really are different audiences.
March 24, 2004
The Mac OS X version of the TERDISP utility was updated. It colormaps properly and scrolls large documents, and reads both version 4 and 5 TER files.
It needs OS X 10.2 (Jaguar) and higher, because it uses the recently added HIView APIs. I wanted to do the scrolling and window update logic myself, but had to settle for using Apple's HIImageView class, because the lower-level details are documented so poorly. I don't know what Apple is thinking, but they really need to overhaul their developer documentation.
At one point I thought I'd forget about Quartz and use the tried-and-true QuickDraw rendering system, which I'm already familiar with, but blitting from a GWorld using CopyBits just to avoid slow SetCPixel calls seems absolutely nuts when the window system is double-buffered already. Quartz ImageRefs solve the problem by using a data provider abstraction, but for reasons only Apple knows, they don't exploit the abstraction properly -- large images wind up getting sampled for pixels that aren't even visible. Even HIImageView doesn't do it right; it reads the entire image and builds up a device representation which it then scrolls nice and quick. It's one of those classic lost opportunities: the system has the plumbing to do large images correctly, but the facilities are ignored because someone went and assumed that no one would ever want to use large images. Apple's own HIView samples are pathetic -- they all just invalidate and repaint the entire view surface instead of demonstrating how update regions are processed. Sigh. Isn't anyone doing any optimization over there?? No wonder Aqua is so damn slow.
Apple treats HIView like a replacement for the Control Manager, so they keep thinking in terms of little widgets that are fully visible on screen, instead of taking the larger view that they should ditch the whole window/control concept and just move to the simpler and more elegant they're-all-window-objects like Win32 does. Doing an API transition in stages is just silly; if you're going to do something new, just bite the bullet and do it all the way so we can reach nirvana sooner.
March 15, 2004
Started overhauling Vectre's Undo system to match what Leveller is using. This is a necessary step before Vectre's spline tools can be copied into Leveller since they must use its event support infrastructure.
Vectre supported multiple Undo before Leveller, but it did it the elegant brute-force way, which is to simply store snapshot copies of the document after each edit. This is the easiest and most intuitive way to implement multiple Undo, but it is very wasteful of memory when editing large documents. All other undo systems can be treated as optimizations.
March 14, 2004
It took a little doing but John Ratcliff's TER2WRL app has been refactored as the new TMesh2 Leveller plug-in. On top of generating better optimized meshes, it can export to DXF and OBJ in addition to VRML.
February 22, 2004
Finally got enough viewpane class code working in Abstract for the small test app to make an appearance on both Windows and Macintosh. I had it draw lots of colored squares in order to be sure that buffered drawing was working.
The Windows version has the buffering logic added to make it imitate OS X. The application doesn't know, of course -- it itself doesn't contain any platform-specific code at all.
Windows of course has the containing window frame while the Mac doesn't, but the trick is to keep that frame outside of the abstraction model. The application has no idea it's there, so it doesn't get hung up about it being nonexistant on the Mac. The menubar and its menus are also abstracted away; the application doesn't know how commands are presented or chosen.
February 17, 2004
Vectre 1.2 build 226 was released. It supports importing UKOS DTM contour files that are DXF encoded. Here's an example:
Was working on my Abstract cross-platform framework now that all the various chores associated with Leveller 2.4 are done. It's strange how even the simplest things are incredibly complex... had to spend five hours today just figuring out how command objects should be represented. Turns out they require about a dozen classes. The complexity comes from the features people expect commands to have, such as name, state, logical groupings, visual representations, accelerator keys, etc. etc. But I feel good about how it's going. I'm learning some interesting stuff, at any rate.
Abstract, of course, is what I want to use to port Leveller to Mac OS X (and Linux). What worries me about the Mac is that, even though Apple is enjoying good times, there's a quiet movement by vendors to distance themselves from the platform. Corel announced that Bryce will be Windows-only, and digging around on their website revealed that the same will happen to version 12 of their Draw suite. The reason? Their marketing data indicates that Windows has 95% of the market. What's disturbing is that Corel went to a great deal of trouble to make Draw's source code cross-platform (and I know, because I helped them do so), and now the usefulness of having a single source tree will deliberately be unleveraged. For any reasonable person to do that, the bottom-line returns of supporting the Mac must be astoundingly low. Even when the Mac has improved its OS, GUI, and hardware speed. Maybe Corel's management figured that if the Mac's market share couldn't increase after those things were done, then it truly is a lost cause.
TrollTech is so desperate for Mac versions of software ported using Qt that they're giving away a G5 PowerMac to the nicest example. Okino used to have Mac versions of their products, but it discontinued them because the low sales spoke for themselves. The basic logic is hard to refute, because if one is just managing to get by with Windows, what does a platform with only five percent of the user base offer? Adobe of course dropped Premiere, but that's more likely because it made no point competing with Apple's own movie software. And Microsoft still makes Office for the Mac. The pattern suggests that supporting the Mac is something that only the biggest companies can afford to do.
As a small vendor (and I couldn't get any smaller) I certainly can't afford any ongoing engineering on a Mac version of Leveller. So the trick is to have Abstract be robust enough that porting is truly just a matter of simply recompiling the source code. The moment that effort goes beyond five percent of the total development effort, it becomes unsustainable. In fact, for a developer, having one OS dominate is the most economical situation, because all porting costs vanish. The worst situation (ironically enough) is a level playing field: imagine having to support two platforms because each has half the market -- you'd have to work twice as hard (worst case) to get more than half the market.
But there is something else.
Oddly enough, Windows itself provides a good reason to use a cross-platform framework. Longhorn has enough of a different GUI architecture that in order to support it along with Win32, even Microsoft is recommending to developers to make stronger separation between core code and UI code in their apps. The way I figure it, is if I'm going to go to that much trouble (and I will, because Longhorn has every chance of grabbing lots of market share), then why not use Abstract and make a version of it that supports non-Windows platforms?
February 12, 2004
Programming is, of course, just one part of software. There's a whole underlying business infrastructure that also needs to be maintained. Well, it does if you really want to do justice to the project. Even when it's a non-profit thing, that surrounding environment still needs tending to.
Keeping in touch with the outside world: In my latest perusal of the Internet I came across a few tutorials that I hadn't seen before. Interesting stuff.
Updates: The Leveller 1.x-to-2.4 updater is now available.
Only $49.95 through Digital River or PayPal.
I don't talk as much about my other love, philosophy, as much as I used to. I've sort of reached a plateau in that area.
It's an interesting game, but the closer you get to ultimate truth the exponentially harder it becomes to make progress. I suspect the problem is that it also becomes harder to tell if you're making progress. For all I know, one develops a great theory but there's no frame of reference in which to test it. Even physicists now have that problem with string theory.
Is it a waste of time? Hardly. I honestly believe you enrich yourself immeasurably by pursuing truth, even if you don't get as close to it as you'd like.
I'm starting to conclude that reality is essentially mysterious, and the mystery is an essential part of reality. The whole entirety of matter and energy is like that -- we can't ever know it perfectly, because it's constantly vibrating and is composed of things too tiny to measure, and that unknowability is key to making the stuff real. It's no surprise that the more we know, the better our simulations become, and the more the unreal appears real.
So where does that leave me? Well, I have a newer respect and fondness for the universe. Better still, perhaps, is that I'm not as stressed as I used to be about not being able to figure it out. The whole thing is mysterious, and that's okay. The universe is telling us, Don't spend all your time trying to figure me out. Life is also about enjoying experiences, aside from the experience of figuring me out.
Hardcore scientists and philosophers are like moviegoers who, after seeing a movie, start endlessly dissecting it and trying to understand all the stuff the director and producer went through. Well, unless you're going to make your own movies, it seems like overanalysis. I can just see the director shaking his head wondering why people don't watch the movie for the purpose of watching it. That's what the movie was made for, after all -- to be watched.
I guess the thing is that, if you push your limits to the honest-to-goodness utmost, if you give your projects the greatest, no-holds-barred effort you can muster, then you finally come to know yourself. You know what you're made of, and who you actually are at a fundamental level. The person you are that was originally created by Nature, whose character defines every moment you had and will ever have, that is what you come to know.
And I think (or I like to think, anyway) that each of us has a true character worth exploring and coming to know. That is the challenge facing everyone, to push ourselves hard enough to clear away all the dirt and fog obscuring our true selves. To finally come face to face with the person we see every day in the mirror and truly know who that person is. And by having that knowledge, if we find something we don't like, we also have the power to truly change, and thus gain free will.
The search for truth isn't so much about figuring out how the universe or reality works. It's about discovering who you are, and coming to terms with your destiny, either letting it happen to you or you taking charge of it. Because no matter how much anyone figures out about anything, in the end life still boils down to making choices. And when you don't know who you really are, all your choices feel like they're being made by someone or something else, and that's what makes people unhappy.
Knowledge of self is important. Most people think that if they had a lot of money that they'd be happy, but the reason they often don't become so is that you could be rich and still feel like your choices aren't your own. And then you get paranoid about wondering if the wealth was just fate or luck and if so, it could all one day vanish pretty quick. So you see these rich people desperately trying to make even more money. What they need is to let it go and face a truly great challenge, after which they will know who they are, and then they'll finally know peace. It's part of the same reason why so many successful people advise simply working on what you love, and not worrying so much about whether it will make you rich or not.
February 7, 2004
Upon reflection, "catch-up" isn't quite the right word... "matured" is perhaps a better one. Leveller is now getting the architectural underpinnings it needs to scale to bigger and better things.
Accidentally came across a simple way to make a stripmining effect (and sinkholes, too, probably). Turn "Affect Unbrushed Areas Only" on, choose the Dig tool with the flat brush style, set a fairly heavy strength value, and then brush an area. When you release the mouse, switch to a smaller brush radius and dig inside the area just made, and repeat as often as desired. The Elevate filter could be used with numerous selection masks also, if one wanted greater precision. Either way the shape of the terrain within each region isn't altered; it's just lowered. The above picture got a pass from the scanline renderer to roughen the ground up a bit.
February 6, 2004
History appears to be repeating itself. So far, although numerous people have upgraded to Leveller 2.4, no one has reported anything amiss. The first demo build had a startup flaw but that was fixed yesterday.
Now I'm upgrading the SDK. Due to the more extreme API changes it's a bigger job than usual, but it's coming along. Talk about your classic test of character... the whole thing is grunt work.
Reminds me of the time I interviewed for this small shop in Oregon that developed PostScript filtering software; the owner jokingly referred to his operation as garbage hauling, the stuff that nobody else wanted to touch. It is (or was?) a lucrative field and benefited greatly from a natural dearth of competitors, but you really had to like programming to stick with it. The whole thing was grunt work from beginning to end.
February 2, 2004
Leveller 2.4 was released last night. Although development took four or five months longer than planned, it was time well invested. This version has received the highest level of testing and its internals have been rebuilt much closer to what they should be. I personally feel a lot better simply because my confidence in the code is much greater. When things are nebulous, that's when programming becomes a total chore instead of fun.
Still working on the updates and the demo. For the demo, I want to be a little more liberal and restrict fewer things. There has to be a better sweet spot where the demo demonstrates but still doesn't compete with the actual program.
In many ways, 2.4 is the "catch-up" release. Multiple Undo, feathered selection masking... any normal bitmap editor has those features. It would be honest to say "it's about time" as much as it would be to say "cool". The 3D editing, however, is more in the latter camp, and for many people that's what 2.4 is mainly about.
So... where to from here? Well, 3.0 is the logical next step. The time has come to bring the vector editing tools from Vectre into Leveller, and restructure the whole document/view file format thing.
January 31, 2004
Well, tomorrow is the release date for Leveller 2.4, and I do believe it's good to go. I had one day of spare time left over, so I used it to improve the scanline renderer a bit. Namely, to make it show the water level, because without water the scenes were looking pretty dry.
The last picture demonstrates how, because the water plane is tesselated, it follows the current UV distortion map (in this case a 60-degree sphere section).
The shader for the water is quite tame; just a flat noise pattern with optional shoreline blending. It would have been nice to get specularly lit wave-combined Perlin noise, but time was limited, and the internal renderers are meant more for prototyping.
January 27, 2004
While testing the selector plug-ins I noticed that the newer Select Slopes plug-in can help make interesting weathering and corrosion effects. An example is shown below, which I think looks like what happens when you press a wet soap bar against a flat surface and then pull it away to see the pattern of foam it leaves behind.
The basic principle is to smoothly select a range of slopes creating a nicely transitioning selmask, and then flatten those areas with it. After doing that a few times, inverting the mask and then using the smooth filter makes the unaffected regions connect up better. The original heightfield was a basic gforge pattern.
January 26, 2004
Leveller 2.4 is getting really nice now. Still some things to test and fix, but nothing heavy. The most bothersome thing is that several features are modal and thus combine with each other, increasing the permutational complexity of most test items. The only thing that can be done is to keep the underlying implementations well-designed, because the features are absolutely necessary for this type of program.
PCs are now so fast that I enabled alpha-blended floating selection drawing. If you make a feathered selection, for example, and then drag it around, the chunk of heightfield floating above the document heightfield will appear softly transparent and then fading off entirely at the mask's edges. I would include a picture but the effect can't truly be appreciated unless there's motion. To make a long story short, it really helps indicate what will happen if a feathered selection is defloated.
January 17, 2004
Almost there. Leveller 2.4's task list is down to the really short strokes. Small (but important) things keep cropping up, and the latest thing confirmed yet again that in every programmer's life, there will always be the Very Difficult Bug. This bug is the one that we all hope doesn't strike, consumes major time to fix, sometimes goes unfixed for eons, and if fixed, becomes part of the dev team lore. If I had to choose some key defining element that a programmer should have, I would ask if he or she had experienced that. If not, then an important part of their character has yet to be tested. Those are the kinds of bugs that make or break a programmer, that separate the wheat from the chaff. If your heart's not truly in it, those bugs will make you switch careers mumbling "I didn't really like engineering anyway."
In this case, it was the Smooth/Sharpen tool being unable to duplicate its behavior between live edits and those played back as part of the Undo system's journaling process. The difference was small, but enough to make a document drift from reality whenever the Undo/Redo commands were used. The Undo system demands absolute mimicry during edit playback, so the hunt was on.
Turned out that the style for the brush mask was different between live and journaled editing. It's flat by default, set in the edit's base class, but the Smooth/Sharpen tool uses a non-flat style and an override was missing.
Since only two days passed between detection and fix, I wouldn't call it a Very Difficult Bug, although it certainly had been the most mysterious and worrying. An earlier version of me would easily have spent two weeks hunting it down (shudder).
Could I have prevented it? That would require some way of asserting that the live edit conditions are properly re-established during journal playback. Considering how many types of edits there are, a simpler assertion would be to just perform a brute force comparison of a document with its Undo-then-Redo version. That won't catch the precise item that has differed, but it will flag which edit class the error is in, and from there further assertions can be added. That way, time is spent only on those things that need it.
For the HF-Lab plug-in, I made an HTML version of the HF-Lab help file. This is the file that describes all the HF-Lab commands and their parameters. The page is on the website since it makes a handy online reference to HF-Lab even though it is geared towards the version of HF-Lab used by the plug-in.
January 8, 2004
Since the Select Slopes plug-in now does gradual selecting, one can easily make smoother transitions for bump patterns in the scanline renderer. Two initial results are here and here. I picked one of them and scaled it down to become the official splash screen for Leveller 2.4:
Why go back to the mountains? Well, with the USGS DEM Export, Leveller also turns an important corner on supporting georeferenced data.
As has been noted before, often it's the small things that make a difference.
I finally got around to adding view frustum indicator lines to the map pane's camera indicator. I'm not wild about the black-with-white-offset method of making the lines stand out against the underlying terrain, and given today's faster PCs, was even thinking about drawing them antialiased.
The dashed selmask marquee now surrounds all selected pixels, not just those which are 50% selected or more. Tools also report selmask pixel transparency values when the mouse is over the map.
January 3, 2004
Happy New Year.
I feel bad that Leveller 2.4 didn't ship in time for Christmas; that would certainly have been nice timing. On the other hand, my task list is very highly defined now and focused on the short strokes, and I have every reason to believe this thing will be out before February. The betas are getting nicely solid.
With every release, there's always this temptation to fix or improve numerous little things because the thought process is: If it ships without them, what a shame that would be. They won't get in then until the next update. It's so seductive that anyone can spend several additional weeks just trying to be perfect. My only consolation is that I've done so many versions now (2.4 will be the fifteenth commercial one), that I can be philosophical about it. If there needs to be a 2.4.1 to fix some loose ends, then so be it.
Recent last-minute niceties include all usage of "world units" inside Leveller using the active document's world scale label, and a "File, Open Containing Folder" command. I was typing in pathspecs into Explorer shell windows (or into the address bar) to open the folder of the current heightfield file, and realized that Leveller could do it for me.
The USGS DEM Import plug-in also got updated to use the newer parsing logic in the DEMDUMP utility. Profile columns aren't south-aligned anymore, and every heixel is exactly where it's supposed to be.
John Ratcliff (formerly of Sony Online) updated his TMesh work... he's done a console app that emits better triangle meshes from Leveller TER files. Preserves small features better, and the mesh edges on flat HFs don't have tons of little triangles anymore. When time permits, the TMesh plug-in will be updated accordingly.
Older Notes