Home Tour Gallery
    

Archives

Apr-Jul 2003
Jan-Mar 2003
Oct-Dec 2002
Jul-Sep 2002
May-Jun 2002

December 22, 2003

Build 798 of the Leveller 2.4 beta was made. Gives testers a chance to try the 3D editing mode, the DEM export plug-in and also a UKOS DTM import plug-in.

Whipped up a histogram viewer plug-in since it was a long-requested feature. It will be added to the plug-in distribution for the 2.4 beta later on.

It basically shows the distribution of elevations from lowest to highest, across the display left to right. The picture above shows how the gforge filter tends to give elevations a bell distribution except for the higher heights.


December 21, 2003

Well, the USGS DEM Export plug-in is finally stable enough to be externally tested. It supports geographic and UTM ground reference systems, and here's what the dialog box looks like:

Synthesizing UTM-based DEMs is tricky because the quadrangles are usually rotated relative to longitude/latitude lines, causing the DEM profiles to have varying rowcounts and starting points.


December 15, 2003

I need to brush up on georef data so that Leveller can export proper DEMs, so as part of the learning process I wrote a console app called DEMDUMP to list USGS ASCII DEM files. Here's some sample output:

USGS ASCII DEM File Content Lister (build time Mon Dec 15 01:32:44 2003)
Based on USGS January 1998 specifications
Copyright 2003 Daylon Graphics Ltd.
-------------------------------------------------------------------------------

File: 055+243.dem
Size: 50.16 MB

Header (logical A record):

             Filename: Digital Elevation Model by 3DEM         
          Description:                                         
               Filler:                              
         SE geocorner: Undefined
         Process code: 0
               Filler:  
  Sectional indicator:    
          Origin code:     
           Level code: 1 (auto-correlated or manually profiled)
    Elevation pattern: 1 (regular)
    Ground coord. sys: 1 (UTM)
            Zone code: 34
         Ground units: 2 (meters)
      Elevation units: 2 (meters)
        Polygon sides: 4 
   SW corner location: 424,345 by 4,169,591 meters
   NW corner location: 424,345 by 4,247,979 meters
   NE corner location: 520,615 by 4,247,979 meters
   SE corner location: 520,615 by 4,169,591 meters
       Elevation span: -183 to 2,439 meters
             Rotation: 0 degrees 
   Elevation accuracy: 0 (unknown)
        X scale ratio: 30
        Y scale ratio: 30
        Z scale ratio: 1
              Columns: 3210
                 Rows: See B records

  Extra (newer type A record) fields detected:

                 Data source date: 0
     Inspection and revision date: 0
                  Inspection flag:  
                  Validation code: 0 (No validation performed)
   RMSE computed from test points: No
             Bad elevations flags: 0 (None)
                   Vertical datum: 2 (NAVD 88)
                 Horizontal datum: 1 (WGS 72)
                     Data edition: 0
                Edge match flag W: 0 (unknown)
                Edge match flag N: 0 (unknown)
                Edge match flag E: 0 (unknown)
                Edge match flag S: 0 (unknown)
                Vert. datum shift: 0.00


Records (logical B records):

        File offset: 0x400
  Number of records: 3210
   Highest rowcount: 2613
    Void elevations detected


Trailer (logical C record):

              File offset: 0x3228400
         Abs. RMSE avail.: 0 (no)
         File RMSE avail.: 0 (no)


December 9, 2003

Pete Patterson is a fan of both the Active Worlds web-based virtual worlds browser and Leveller. To streamline the process of getting elevation data from it to AW, he wrote this nice plug-in:

When I finish the new appearance acquisition APIs in the plug-in SDK, he'll have an easier time getting data on textures, colormaps, etc. from Leveller.

ActiveWorlds is a nice idea, but the main problem is detail. As humans, our everyday experience tends to center on things within arms' reach, but in AW, objects and textures at that distance break down into irreducible aspects like pixels and basic geometry. It makes for an experience that leaves you thinking: this will all be really cool in a few more years. They still haven't figured out how to do dynamic billboard-based LOD conversions, so even at cable speeds large chunks of cities pop in piece by piece. If you move forward and turn around, the part of the city where you were vanishes. It gives everything a more virtual feel than one hopes for. But it does give an exciting taste of things to come. If you visit the Nouveau Monde world, the art gallery is great.


December 6, 2003

In for a penny, in for a pound.

That's the latest Leveller plug-in API. I had to break backwards compatibility with the previous versions, and then I realized, if I have to do that, I may as well take the opportunity to fix lots of other stuff that had it coming.

Such as... the LEV_PLUGIN_INSTANCE parameter used by nearly all the functions. I just deprecated the thing outright. I thought I would need it, but I was wrong, and now the code is cleaner. Texture and colormap access APIs are going in too; it's hard to believe they managed to stay out all this time.


November 26, 2003

Leveller 2.4 went beta yesterday, and today I managed to get the editing tools working by clicking and dragging the mouse on the 3D scene pane. It certainly makes modeling more intuitive, although of course it works best when looking down upon the heightfield at a steep angle.

The picture above shows the Flatten tool being used on the scene pane. The transparent cylinder helps shows the brush region against sloped terrain and the brighter ring indicates the elevation of the heightfield pixel that maps to the mouse position.


November 14, 2003

Things that work only in one direction are only half as fun, so I wrote a PolyTrans/NuGraf plug-in that imports Leveller heightfield files to complement the earlier export plug-in that generates them.

 

Got the basic event loop mechanism working and can even establish primary app menus on Win32 and OS X.


November 8, 2003

After realizing that the handy Polytrans program didn't have a plug-in to export Leveller heightfields, I got in touch with Okino's Mr. Lansdale and promptly wrote one.

It's the same idea as Leveller's DXF importer. You just choose the heightfield size, span, and projection axis, and out comes a depthmap of whatever Polytrans has loaded.

There's a new project in town called Abstract. As part of porting Leveller to other platforms, I realized that the best way would be formalize a cross-platform framework since I have a lot of related ideas I want to implement as well.


October 30, 2003

Program menus can be deceiving. Leveller has a bunch of plug-ins listed in its Import and Export menus, and those lists didn't look too long. Well, I'm still going through those plug-ins getting them updated for Leveller 2.4, and now I know that a lot of stuff can accumulate in five years.

It'll be worth it. Every single plug-in is getting documented and their dialog boxes are being made consistent. The unified feel will be like nothing Leveller had before.

Came across a serious bug in the 2.4 alpha. Loading a document forgets to make the selection mask of the journal tracker match the heightfield dimensions, causing a GPF when you do a selmask edit and then try to undo it. Oh well... but this is what alphas are for.


October 20, 2003

Sometimes it's the little things that make all the difference.

Leveller plug-ins always said "world units" when referring to whatever non-pixel measurement system the heightfield was using, but that wasn't much fun. Now it's possible for them to refer to the actual measurement label, making dialog boxes more intuitive.


October 16, 2003

The Leveller 2.4 alpha phase has now begun. Interested 2.3 users can get a 2.4 updater by contacting Support.

Sometimes clouds do have silver linings. I noticed I had broken the scene's OpenGL renderer; along slab edges there were slightly misformed triangles. But in the process of fixing the bug, I realized I could greatly simplify the code and speed it up. As a side effect, the auto-LOD mode was also greatly improved; the slab gapping between LOD transitions is almost gone.


October 14, 2003

Since I was neck-deep in plug-in code, I figured I'd add an interesting generator plug-in. I call it Cells, because it makes cellular texture formations:


October 11, 2003

What a grind. But persistence pays off: the Leveller 2.4 alpha is pretty much at hand.

Getting plug-ins to support Multiple Undo ultimately required a serious refactoring of the plug-in system within Leveller. That code is so ancient and complicated I had to spend a few days just relearning how it all worked. It would up for the best -- the new code is a marked improvement.

Now that the plug-ins are being supported, the new Undo system really earns its stripes. I can run the Fractal Noise plug-in, for example, and experiment with many different settings and then just Undo/Redo through them, like a flipbook.


September 28, 2003

Several plug-ins now support multilevel Undo. Since I'm slowly going through each plug-in one by one, I've taken advantage of the situation to rectify a long-standing oversight: writing the plug-in documentation. I also added an API call to let plug-ins display their documentation from directly within their dialog boxes.

What a difference a few years can make. The original Lines plug-in took several days to write, worked poorly, took over a thousand lines of code, and didn't antialias. Today I rewrote it in three hours and it works perfectly, antialiases, and is much smaller.


September 25, 2003

Finally got one plug-in (Bubbles) to support multilevel Undo. Works like a charm. There are a ton of other plug-ins to update, but it's all downhill from here. Now that the system has been worked out, it's just a matter of applying it to where it's needed. Developers will definitely have to modify their plug-ins slightly to use the new SDK, but it's by no means major surgery.

There's this book project that's been in the back of my mind for ages. I even started it a few times but then stopped. It's a big document on how to write software in C++, but I can't help wonder if there aren't enough books on that subject already. I don't know if what I have to say about programming is unique enough to merit the effort.


September 20, 2003

Well, all of the normal document modifying actions have been updated to support multilevel Undo. Now comes the interesting part, which is to get the plug-in system to do the same. Not an easy task, but a strategy has been mapped out. I'm more worried about how different the plug-in API and deployment model may change, since that will impact plug-in developers.


August 28, 2003

The multilevel Undo stuff is more involved than I thought, so the document format revamp has been moved to Leveller 3.0. The good thing is, most people prefer to associate document format changes with whole number app revisions, so it works out. 2.4 will be basically just an update for the multilevel Undo, true selection feathering, and the usual round of fixes.

Part of the delay is also an architectural sweep. I'm always trying to structure the code better and kept cruft out of my life. There was, for example, a whole ton of legacy view class members relating to the selection object, but since all the selection data was moved into the document class a long time ago, they were in the wrong place.


August 23, 2003

Just got back from Kelowna, B.C., where a large forest fire is still continuing to raze nearly everything. My brother chose the town several months ago for his wedding, so fire or no fire, it behooved me to go up there. Fortunately, the active front had travelled quite easterly by the next day, and the air cleared up and the wedding went great. Love indeed conquers all. :)

Still, the first few hours were pretty bad... I had cigaratte-style ash particles floating around in the car, and everything looked and smelled like a BBQ gone totally wrong. The sky totally gray, distances obscured with a filthy haze, the air oddly several degrees hotter than it was just outside the city, breathing slightly harder than usual, and everything coated with burnt carbon dust and smelling like an ashtray...

I can't even begin to imagine what it must be like for the firefighters who are right smack in the middle of it all. You look at the immense smoke plumes, and at first you think that a volcano has erupted, but it's simply the simultaneous burning of countless trees. No description can do it justice; one has to see it to even try to believe it. A second fire began while I was there, and the last thing I heard on the local radio driving out was that almost a thousand homes had been totally destroyed. But the place is so nice, it's small wonder that lots of people have moved there. Kelowna is the largest city in BC outside the Vancouver area.

The region is part of the Okanagan Valley, and if you're like me, your first impression is how Terragen-esque it is. If you go down the coastal lakeside highway into neighbouring Peachland you're apt to think that you've been transported into a classic Terragen lake-and-mountain scene. Of course, the opposite side of the lake is pretty roasted, but still. The water appeared to be bouncing back quickly... it was already nicely blue again by the time I left.

The thing that struck me most was that as nice as landscape software is, the problem is monitor resolution. I kept realizing how much more detail there is in a real scene, and that it is the level of detail that makes a real scene so much better. Higher frame rates are nice, but for video technology, we need to focus on bringing down the costs for higher resolution display systems. This is truly the next frontier for computer graphics, to provide a pixel for every retinal sensor. We actually can go around generating 6000 x 4000 pixel images in practical time with consumer-level equipment, but we need the monitors to display them without scrolling.


August 20, 2003

Sixty-one editing events now support multilevel Undo. It's also starting to support markers. The irritation of the old system is that not only was it one level deep, it only cared about the heightfield, so it's good to finally change that.

Leveller 2.4 also introduces startup activity logging. This will help troubleshoot those rare situations when Leveller won't start (the existing "Help, Log Commands..." feature can't help, since the menu command isn't available unless Leveller starts properly to begin with).

Not that it's really my responsibility, since obviously Leveller starts on any normal Win32 system. But it was easy to add, doesn't noticeably delay the startup time, and if the problem isn't reproducible with any other program, then it's damn useful if Leveller itself can help diagnose.


August 14, 2003

Added a "show selection mask" mode to the map pane, to make it a no-brainer to see exactly what the selection mask is.

Every once in a blue moon, someone has a Windows system which won't start Leveller. Given the complexity of operating systems today, the cause could be nearly anything. In an attempt at troubleshooting, I've made a small System Check applet available for Leveller 2.3. It simply queries all the system files Leveller uses to see if they are of a sufficiently high version.


August 12, 2003

Need for speed: the first cut of my selection feathering algorithm was taking too long. It needed 91 seconds to do a 50-pixel radius feather of a large complex irregular selection on the canyon test file.

I knew it would be slow, but that's downright nuts. Two optimizations later, it's down to five seconds. The release build should be even better. I imagine feather radii of 200 or greater will not be uncommon, so this feature has to run fast.

Spent the rest of the day getting the shape tools to support multilevel Undo. It turned out to be a classic case of something you think will take a few hours winding up taking three times as long.

The problem is, a shape can be stroked as well as filled, and the stroke is centered on the shape's edge. In the old system, where the selection mask filtering was done after the shape was drawn, the task was trivial. But in the new system, selmask filtering has to be done live, which means I can only modify each heightfield pixel once (otherwise overfiltering will occur). Which means, in turn, that I have to determine if a shape's pixel is within its stroke or its fill -- I can't just draw the fill and then overlay the stroke on top.

The solution was to borrow a page from the raytracing book and adopt a device space sampling approach. Now, the affected rectangle of the heightfield is iterated over, and for each pixel, we figure out which shape element it belongs to (or if it is within the shape at all) and then filter and plot that element's elevation.

It works fine, runs reasonably fast, and repeatedly pressing Ctrl-Z and Ctrl-Y to undo/redo various shape drawing commands was pretty breathtaking. I know, the novelty will wear off, but doing it when it's never been available before just makes you feel like you're running a whole new program. Now that I'm able to jump at whim to any point in a heightfield's history, I'm seeing how enabling this will be. The ability to experiment is just a million times greater.


August 10, 2003

Well, 37 events now support multilevel Undo, which is about the halfway mark. Some are easier than others to modify, and I'm certainly learning a lot about event abstraction.

One nice thing (even though it means extra work) is that I've had to clean up some old code to structure it better. There were several items in the view classes (such as the rebrush tracking mask) that are now document members.

Pasting of large elevation data chunks is a bear -- the Undo system has to store the pasted data into its queue so that any potential regression using it can do so independantly of what's on the clipboard. Otherwise, one could Paste, Undo, switch to another app, copy something different to the clipboard, then switch back to Leveller and Redo. I'm going to have some type of heightfield compression to alleviate "large pasting stress", but it's still nevertheless easy to overwhelm memory anyway.

Multiple histories (branches) are neat. I know how to do them, but it would stretch the schedule too much for 2.4. For most people it's also overkill.

Defense Condition is at 0.5 now. Objects explode with better color and debris mass correlation, and there's a PREFS.TXT file that one can use to modify the game's behavior.

According to this article on Slashdot, 8-bit classic games (on emulation or whatever) are quite dead. Oh well. Good thing I got some coding experience out of it. :) The game also makes a handy way to test my portability layer classes.

Boy, I can't believe the number of fake "returned emails" I've gotten today. Some person or persons out there has decided to spoof their spam's reply headers with other people's addresses. Since a lot of spam recipients are invalid, the spammer gets bounceback. Or more correctly, I get it, since the mail system thinks I sent their email.

Sigh. Deleting spam is one thing. I even have pretty good filters for that. But abusing other people's addresses is just downright wrong. I don't know... it kind of marks a whole new low in civilization or something. If they can't fix this, we may as well hang it up and go back to living in caves.

I think faster computers and improved statistical analysis software (like the kind that's making human language translation easier) will eventually cure us of spam. Either that, or we deploy a neat solution that helps redistribute the wealth, improve literacy and spread technology: give everyone an Internet PC, and pay poor people to manually filter spam.

Then again, spammers would just embed their messages inside mail that starts off looking legitimate, since human readers wouldn't have time to read every last word of every message.

Maybe this is why there are no alien civilizations. They invent Internets and e-mail, and then they kill each other arguing over spam. :)

Or a new elite social class may rise: people wealthy enough to pay others to read every word of every e-mail. Reminds me of the bosses I had who were computer illiterate and proud of being able to remain so because they "had assistants for that sort of thing."

Or a disturbing legal alteration, probably starting first in some country where the government was draconian anyway: permitting the confinement and/or "removal" of spammers.


August 5, 2003

Got heightfield cropping and resizing to support the new multilevel Undo system, and it works quite well. No more of this "action cannot be undone" stuff. Resizing to a preset size also doesn't flatten the heightfield anymore; Leveller resamples it instead and automatically uses bilinear resampling (which is best) if resizing downwards.

Updated the downloads page. There were so many items on it that it seemed proper to break the list up into categories. I also added links to a few items that reside in the main download area.


August 4, 2003

Selection feathering now works properly, using a feather radius instead of just blurring the selection mask. The previous behavior has been moved to a "Selection, Blur" command.

Rolling along on the multilevel Undo feature. Twenty-three edit events now support it. The above picture is a screenshot of the new "Edit, Regress To..." command's dialog, which lets one choose a particular state of the document to regress to.


August 2, 2003

Finally got multi-level Undo going into Leveller. Each command (or any event that can modify the document) has to be coded to support the feature, so it will take a while before it's fully ready. So far, the Smooth and Sharpen filters work with it, and the way the system works (to save on memory), it takes three seconds to Undo after doing a dozen smooth operations on a 480 x 500 heightfield. More detailed info is available on the mailing list.


Older Notes