Screenshots of Mundo

Date: 2003-Feb-05
	Just to let you know... Development is still going on but currently I've had to re-iterate my doings from the previous days and determine whether it is the right track or not. This screenshot shows you already the (default) texturing of landscapes in the editor, the import dialog and it's merged with the wireframe view. Also, it's now already possible to select faces for editing, but no manipulations can yet be performed. The objective is to create so-called manipulators, which basically creates draggers and handles on faces or vertices so that everything can be moved around in a very intuitive manner. The texturing is however the first thing I want to get right, because the storage here determines how I can render the things later. Other progress was made on the export/import code, because it's already possible to export the scenes here to the (eventually) real terrain rendering library. This terrain library will visualise what we create here and it already does so for all the vertices. The other things now being worked on are the strategy for texturing, which is quite a pain as it will have consequences for performance or otherwise visualisation capabilities, if not ease of editing.
Date: 2003-Jan-29
	Got it! This image shows a lot of things... There are some bugs to remove, but nothing I can't handle. The algorithm is perfect. This image shows a crude image of DEM data. What I do essentially is take the elevation points from DEM data, triangulate between the points and decimate certain areas that do not need so many triangles. The result is a fair (and sometimes better) approximation of the landscape and it's data that can actually be used in realtime applications. The next images should start with some vertex or face manipulations and some texturing here and there. Texturing takes more work in general, but vertex/face manipulation using Coin3D is fairly simple.
Date: 2003-Jan-28
	This image shows already the import of various GeoSpatial data formats into the editor. I'm using the GDAL library to do this. The image is a 30-sec representation of "Fernando de Noronha", an island very close to Recife, Brazil. The triangulation of this terrain is done using a very straight-forward approach and, as you can guess, it's definitely not optimal. I'm working on the integration of an approach that not only triangulates the landscape, but also decimates the points. The objective is to render a landscape with the detail desired with as little triangles as possible. Several math-techniques exist to do this, but these take time to implement. I hope to have this general implementation done tomorrow.
Date: 2003-Jan-24
	Now that that works, I wanted to see this work for terrains. This is a screenshot of the terrain data that OSG used in their hangglide demo. (thanks guys!). It's just showing a single object containing all the elevation points. The way this is eventually going to work is that I import elevation data from any source (using GDAL), slice it up in four-by-four elevation points and put it in a separate object. This enables very easy manipulation later on. I'll show that in a separate screenshot some time later.
Date: 2003-Jan-22
	An image of the start of the landscape editor. I've spent ages searching for a modifiable editor that did what I wanted and there just didn't seem to be any around. This editor will be based on Coin 3D (OpenInventor) library. Definitely a very cool library that is very extensible. In this example, I have based the client area on the SoQt extensions ( same website ).
Date: 2003-Jan-15
	An image of the BSP renderer in Mundo. This one is derived from AfterShock, but I removed all global variables and now render according to a rendercontext. This makes it possible to have either one large BSP scene or perhaps three very simple ones at the same time on the screen without interfering each other. The main objective however is to make sure this BSP renderer does not bite the terrain engine.
	An image of the terrain renderer for Mundo, from Open Scene Graph. This image is derived from their hangglide demo after I used the hangglide demo code in my own application. There is a WHOLE lot to be done with this code, which currently lives in my own unittest code for easier integration later. The most of it will go into yet another separate library.