Ancient Spaces Blog

Well, I finally got the scene elements of all types and their properties to serialize. I have no idea whether it is correct or efficient at this point though, since I have not yet been able to get it all to deserialize.

In order to load a new scene into memory, we need a way to clear the current scene out of memory. This would be the effect of the File -> New menu item. A File -> Open is a File -> New followed by a deserialization and then initialization of runtime state based on the deserialized property and scene element data. The trouble is that clearing the scene does not currently work as intended because of the way our design was laid out.

We have an ownership conflict regarding the RenderNode corresponding to a SceneElement. A RenderNode is the visual representation of something, typically (but not necessarily) a SceneElement. The Renderer component of the Engine has to know of all the RenderNodes in the world so that it can render them. There do exist RenderNodes which do not belong to SceneElements, which suggests that all RenderNodes should simply belong to the Renderer. On the other hand, never should a SceneElement be destroyed without its corresponding RenderNode also being destroyed. Thus it seems reasonable that a SceneElement should own its RenderNode.

A proposed solution was to have the Renderer provide an interface for destroying RenderNodes, just as it presently does for creating them. This would work fine except it implies that every SceneElement must be aware of its Renderer, or that it must be told who its Renderer is when it is destroyed. Neither of these seems desirable. Creation of a RenderNode has been messy and involved passing in who the Renderer is to date, so it seems the time has come for a refactoring in the SceneElement code. It should simply know its Renderer from the moment of its birth.

Saving and Loading! Yeaaargh!

So,

The GUI we use for the editor is wxWidgets, a fairly comprehensive GUI library, which is designed to operate as natively on a platform as possible. This means lots of generic Windows XP style menu bars, and grey slightly sort of almost 3D-ish buttons. In order to make the application slightly more usable, we also are using wxAUI, a 3rd party addition to wxWidgets which adds dockable windows and tool bars to the system. wxWidgets is nice in that it allows for fairly simple creation of customized panels, with layouts of buttons and lists of data. The overall look of the program is only a nice the look of the operating system (I am not a fan of the default Windows XP skin)). It does seem to be the best open source tool out there for constructing our interface.

There are however some problems with widgets. The event handling systems relies on lots and lots of enumerated values and macros, which means giant lists of button and menu option configurations. And I've found that not all events behave the way one would expect. My largest concern related to this is selection in the Scene Editor window. This window contains a wxTreeControl, which looks much like a small window for browsing directories, but in this case allows users to edit the scene. Selection on this window should mirror the scene, and visa versa. The events triggered by changing the selection in the window have proven to be extremely unpredictable, sometimes triggering multiple selection events, sometimes not triggering any. This results in selection on the window having no effect in the rest of the editor. Although this and similar issues do not cause program crashes, they may prove to be bugs that reside in the software until the are fixed in wxWidgets.

-Simon
Chief GUI Officer

For my extra work this week, I worked on many parts of the Intiwatana. However, none of them are at a state to make a wiki-post.

First of all, the textures. As always, textures could become a pain when a part or parts of a wall is not visible. In the Intiwatana structure 2 for example, the destroyed walls took forever to "reconstruct". Furthermore, if it's a realistic model we are aiming for, it means that the rock creases of each edge must be seamless. Now, that's the hard part. By trial and error in Blender and Photoshop, I was able to create a somewhat decent texture for it. Nevertheless, there's room for improvements. Another detail added to the realism is that, the rocks must have the same tint if they were to be tiled. Some previously rendered pictures do not have that, thus it looks weird. In the coming version, that issue should be addressed.

The rest of the landscape is now almost done. In order to export to Ogre properly and efficiently, I joined all the landscape objects as one object. Yes, joining them may be easy, just select all and press Ctrl+J, but to actually optimize it, ie, to get rid of the faces that are never seen, or welding the vertices together could greatly reduce the polycount. Yet, time-consuming. This is also difficult because the sundial has blocked parts of the wall that's essential to the complete model! With the plan inaccurate, I had to approximate the distance and size of the blocked wall.

So far, the polycount is adequate. It does not slow down the rendering and we still have a decent FPS. Matt and I discussed about this. We should make a realistic/photographic texture for the stairs or even build the stones rock by rock. This way, it would greatly reduce the time in texture editing and improve realism drastically. Rock by rock method is not a problem here, because, we can handle a lot more polygons than we thought. Therefore, with this method, we should be able to complete the entire Machu Picchu site within the deadline and with great quality.