Ancient Spaces Blog

Us programmers spent Saturday making some very cool effects (mainly for use of fire effects for fireplaces etc)

Here's some smoke

Over the weekend, I've worked on the Intiwatana area. The third building is now done modeling. Well, if you look at the picture in the DVD that Marvin gave us, the building is embedded inside the wall of the top region, so I decided to make them one object in Blender. Connecting the edges' vertices are quite tricky. For example, the stair case part is very detailed. It has a lot of vertices. The other parts such as the ground is very simple; it has very large squares for edges. To connect them, many vertices from the stairs side will join onto one vertex on the ground side. This will make many small faces which are not good for rendering due to normals. How I responded to this is that I refined the ground side to have more vertices and connected them together. This "gradual" effect can solve the lighting and shadows problem, but it does increase the polycount of the scene.

Again, on the far side of the scene. The part behind the sundial is still very difficult to model the exact shape. From every picture, the blocked rocks seem... different...

If you find the photo that was taken from the lower level of Intiwatana, you can see another wall behind the third structure. I looked for other photos to find whether there's more angles on that intersecting wall. There isn't. Can't do much more than just guess.

The textures are still not done. For the rest two weeks, I will be concentrating on the textures for this entire Intiwatana area. A picture of the current work in progress should be posted on Wiki soon.

Yep, for the Intiwatana Structure 2, I decided to build my own texture for the back wall. Let's say, it wasn't fun connecting rock creases with those of other walls, but it was done! Yay...

When I did a render of the building, some didn't look right. It was the tint and the shades. Check out the wiki for images. The back wall's tint look much different from those of the side walls. Although the rock creases match on the edges, the top wall textures have a different tint from other parts of the same wall, so it didn't look right.:P

Basically, I've spent another half a day just to "colour" the rocks, changing from the dark rocks to light rock or yellow rocks. Now if you look on the wiki, the textures of the three walls are about the same style of tinting. The walls actually look like they are from the same building. I bet Marvin will like it :D

By the way, this building was half destroyed in the original photograph. The model I made is basically a reconstruction. Again check out wiki for images.

Now that this building is complete, it's time for me to catch up on some programming before doing more modeling.

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.

So we finally got our long awaited plant software (Treemagik and Plantlife) that we could use to make all the plants we'd need for our scenes. Unfortunately, it turned out that Treemagik, while being able to make a variety of decent looking deciduous trees, is completely unable to make any coniferous ones.

Meanwhile, I got this nice list of trees to be modelled...Malus Fusca, Acer Glabrum, Western Fir, Alpine Fir, Western Yew, Juniper, Alder, Pine, Thuja Plicata, Chamaecyparis Nookatensis, Picea Sitchensis, Tsuga heterophylla. And of course most of them are coniferous trees.

So I've been modelling trees all day. I did manage to get a semi-decent looking cedar.

Besides that, it seems that most of the major structures for the Nisga village are done. A few smaller ones still need some moficications though. Here, for example, is a bathhouse frame that is supposed to be covered in hides/blankets. However, it's not known what kind of hides and blankets are supposed to be on it so it's just a frame for now.

I've also finished up a bunch of simple structures this last week, such as a Ganee'e (a fish drying structure) and a simple bridge/boardwalk. Here's a picture of the Ganee'e:

Anyways, back to tree modelling...

Sigh...

Serialization is being very annoying. I clear one obstacle only to slam directly into another. When will the pain ever end? It is finite I'm sure but it seems unnecessary and excessive. What's happening now is that property set tables for plain SceneElements works perfectly, but a very informative exception is thrown when attempting to serialize LightElements:

I looked at the Boost User mailing list for inspiration or instigation or something and came across a conversation over something similar. At least it confirmed that polymorphic serialization should actually work, meaning the system should be able to serialize a light without caring that it is a light. I suspect that the actual error could be caused by something like the fact that SceneElements have only one PropertySet whereas Lights happen to have two. I'll have to test this and other hypotheses with meticulous care.

All just for saving and loading! This is not even the hard part yet. :|

This is Glen again,

I have finished updating the widgets so that now you can control objects in the editor by dragging on neat tools :D This latest additions to the tool allows you to modify a group of objects. Also, Simon implemented a neat copy method that allows us to copy all the selected objects. This led me to a quick (took about 10 seconds) little experiement on adding many many ogreheads on the screen.

Also, along with a translate widget shown in the following pic, you can see the beginnings of an attempt to add a grid to the main editor window

That's all for today, enjoy,
Glen

Having just finished yet another tweak to the camera control system, I thought I would take some time to describe the control system we have developed. I wouldn't call it terribly innovative, but camera movement and control is solid and should allow for efficient manipulation of the camera by the user.

So, to start with, right click with the mouse has become the camera button. Holding down right click while dragging orbits the camera around a set oorbit point, Ctrl-Right dragging moves around this point, and thus the camera. This can also be done using the middle button. Mouse wheeling in and out zooms in and out of this point.

The camera feature I just added come into effect when you try to zoom in past the orbit point. When this happens the orbit point starts moving forward along with the camera allowing and indefinite zoom.

In addition to normal camera movement I spent a bunch of time this week working on the Fly Through Camera Mode. This gives you first person camera controls using the arrows keys (or w s a d) to move and right dragging to look around. This special mode is not used for editing, but can be used to explore your ancient spaces world while still in the editor.

Also in fly through mode the 'q' and 'e' keys work to raise and lower the camera, adding vertical movement to the camera.

It took a while to figure out, but the camera can switch seamlessly between normal orbit mode and special fly through mode.

The other cool camera feature is that holding down the shift key triples camera movement and rotating, so if you need to look at something far away, holding shift will get you there faster.

-Simon
Executive Director of Camera Movement

Folks -

The new Ancient Spaces website is online at ancient.arts.ubc.ca. It's an ongoing work in progress, and will be for the next couple of weeks, as we start to populate the wiki and prepare the forum for broader use. You'll see the last week's blog entries from the development team stretching out below, an engaging and trackless desert of print.

See my first blog entry for some general news and updates.

Michael Griffin
Project Mgr

The Intiwatana site contains three structures, Intiwatana Structure 001, Intiwatana Structure 002 and Intiwatana Structure 003. And... of course, the landscape which contains many staircases.

Matt has done Structure 001 and I am going to finish the rest. First of all, I built(refined) the single rock staircase that leads up to Structure 002. See here for details.

I, then, spend a few hours modeling the structure. It wasn't hard or time consuming, but it was difficult to tell the dimensions especially with half of its entire walls torn down. Again, textures took the longest to create. "Un-shadowing" the outside part of the side walls took an entire day or so. The inside part of the side walls were better because I had more images of them. By matching the seams from two different photos, I managed to get a decent texture after some editing.

The rear part of the structure consists of a series of staircases and terraces, but there's only one photo that shows them clearly. Therefore, I encountered many dimension problems when I tried to model it.

There is now content in the editor!

I spent yesterday converting Blender meshes into a format which Ogre can import. This was done with the Blender Mesh & Animation Exporter v1.0.7. A screenshot and description of the exporter can be found here.

Exporting the meshes did not go very smoothly as I ran into many issues.

First there was the "Error: error in normalize" message I got when trying to export a mesh from Blender. This error is kind of a mystery but it's caused by improper modeling of the mesh, more precisely verticies forming strange angles with each other.

Another fantastic error was the material/image error. Each mesh has to have a material. This material can be used by other meshes (ie. display_texture material). For our meshes, each mesh has one or more UV images (jpg, png, etc.) assigned to it. You can use the same image on multiple meshes (ie. a common floor texture) but the material name has to be unique! If not, what ends up happening is the meshes and material files export fine but when you try to load ASEditor it just crashes :(. luckily you can check the log file to find out what made it crash.

I'll leave you with a screenshot of ASEditor with some meshes in it. Enjoy!

Serializification.

As it turned out the Boost serialization library had a weird undocumented idiosyncrasy in that certain lines of code depended on others in a way which induced an ordering in the header files wherever serialization was used.

If I put this at the top of my files, everything works just fine:

#include <boost/archive/text_iarchive.hpp>
#include <boost/archive/text_oarchive.hpp>


#include <boost/serialization/utility.hpp>
#include <boost/serialization/serialization.hpp>
#include <boost/serialization/tracking.hpp>
#include <boost/serialization/map.hpp>


Heaven forbid, however, that I dare put:

#include <boost/serialization/utility.hpp>
#include <boost/serialization/serialization.hpp>
#include <boost/serialization/tracking.hpp>
#include <boost/serialization/map.hpp>


#include <boost/archive/text_iarchive.hpp>
#include <boost/archive/text_oarchive.hpp>


Naturally, these files should include their dependancies implicitly in the way they are defined so that the order does not matter. This is not the case with the existing version of the library. The author was reachable through the Boost mailing list and ensures me that it will all be fixed in the next release of this library which will be released real soon now.

After clearing that hurdle I am instantly faced with another one. As it turns out, the way we define our vectors and other objects (Quaternions, Colours..) they are nothing but aliases for Ogre's own definitions of them. This posed a problem for serialization because Ogre of course does not define how Boost's serialization library should handle them.

So at first I tried to derive our own versions of these objects which would inherit the properties of the Ogre ones and add definitions for serialization, but this introduced a new compllication in that their definitions are subtly interdependant, so that extending one would mean redefining certain parts of their functionality to depend on the redefined versions of the others instead of on the original Ogre versions of them. Eventually this became too convoluted and complex, so I tried an alternative approach which has been working well.

What I did was to use a feature of the Boost serialization library which permits a function to be written which specifies how to serialize an object without intruding on the definition of the object itself, so long as the object's original definition exposes an interface powerful enough to allow for the object fully to be deconstructed and reconstructed through that interface alone. Fortunately, the objects in question turned out to expose everything publically because they are really just mathematical primitives, which are fairly transparently just data (or specifically "Plain-Old-Data" in the lingo :P).

So, now a small part of serialization is somewhat working, although I have yet to test whether it actually does what it is supposed to do. Serialization of properties, both for SceneElements and the Scene itself is currently missing and will prove painful. The whole hierarchy of RenderNodes and process of reconstructing them is still to come, as well as the serialization of the whole scripting system...

Until next time,
~ Dieter

I'm Ilia Slobodov, a fourth year Engineering Physics student at UBC. Like Matt and Tom, I'm also an modeler/texturer, or as we like to call ourselves, a Visual Content Engineer.

I've been working mainly on the recreation of various structures from a Nisga'a village. Some buildings that I've done so far are a longhouse, three varieties of smokehouses, an elevated food storage structure, several different totem poles, and a few others. For renders of the current state of some of these models, check out our project Wiki at:

http://wikis.arts.ubc.ca/ancient_spaces/index.php?title=3D_Modeling

Next up, after I've finished a few more types of buildings I'll be moving on to creating a terrain of a Nisga'a village. I'll also be making some plant and tree models for use around the village.

Hi there! I am Tom Wu. I am in my fourth year of Engineering Physics at UBC. My position is 3D artist, texturer or just Visual Content Engineer(VCE) so far...

My assigned academic is a Fine Arts professor for the Incan Architecture, so I am in charge of creating 3D models and textures for the Incan ruins and the reconstruction of Incan cities. The city I am working on is Machu Picchu. It has some very unique characteristics; for example, terraces built on 60-80 degrees sloped mountain surfaces and weird stone pieces that perfectly interlocks each other so that the ruins have been around for a few hundred years.

I started off with the Three-Temple group structures in the West Side. I did the Sacristy first, and then the Principle Temple. Matt, another VCE, did the Temple of Three Windows and the Pirca. Each structure has its own unique characteristics, especially the stone sizes, patterns and colours. Each stone tells a story. I will only go as far as that...

As of now, Matt and I have completed all structures in the Three-Temple group and we are working on the terrain for scene so that when the editor is ready, we can start placing buildings in the whole area.

For now, I am taking a break from the terrain and moving onto the buildings on the Intiwatana hill. Buildings are more fun to do than terrain because the terrian plans aren't completely accurate. Nevertheless, textures are the toughest part of my tasks. Believe it or not, they can take as much time as 5x of modeling. Extreme PS skills needed.

Anyways, this project so far has been fun and challenging, although texture editing could become tedious... sometimes... It's still a great learning experience.

I'm Matt, an Electrical engineering undergraduate doing my first CO-OP work term here at Ancient Spaces. I've been doing modeling (with Blender) and texturing of objects and scenes.

So far I have been working on the reconstruction of a part of Machu Picchu. We decided to focus on the 3 window group and Intiwatana sections, shown below.

Now Tom, another modeler/texturer and I have been working on texturing this model. This is taking far longer than expected because there are so many custom textures for each building!

One really strange thing I ran into while constructing the Machu Picchu model was a top view I was given appears to be quite... wrong.

The red circled part should actually be going inwards. All the on site photos support this as well, and the model reflects this.

Could there have been a land slide and a reconstruction? or is the drawing just incorrect. We don't really know.

Salutations,

I am Dieter, co-founder of the original Ancient Spaces project and lead developer (i.e. glorified codemonkey). We have been working furiously this Summer to come up with the Ancient Spaces world editor, nicknamed ASEditor. It is modelled loosely after UnrealEd.

Most recently, I have been working on serialization, which is a fancy name for saving and loading. This has proven to be very painful indeed. So far it has consisted of little more than wading through a panoply of mystifying errors, such as:

(Sorry for the sucky inline images, this blog does not seem to like onClick event handlers.)

Sadly it would seem that the chief difficulty in getting serialization to work lies in getting a good library actually to build and link properly. When we have this working, much of the rest will be donkey work. Naturally in modern languages such as Python (yay) and Java (ugh), serialization is built in. Enough ranting for now.

Until next time,
~ Dieter

I'm a Computer Science undergrad and Co-op student doing development with the other two programmers on the editor. I'm working here on my second Co-op work term, coming straight from another company where I spent a few months working with Java based internet poker.

I've spent much of my time doing development on the interface, most recently finishing up work on the camera movement and control. I've been continuously bugging the artists to try out each iteration of the camera interface, and I've been making changes and improvements based on their input. Right now we seem to have some pretty solid camera controls.

That's all for now.
-Simon

Hi,

I'm Glen, a SDE (Software Developement Engineer) for Ancient Spaces UBC. I just thought I'd leave the first blog on programming and let people know what I'm up to.

I'm currently working on the editor, and I'm trying to integrate some widgets I wrote for ogre into the latest codebase. Widgets allow the movement scale and rotation of objects that are added to the 3D scene. It's taking a while because many things are diffent (architecture wise) from the original I wrote just for Ogre. But it's coming along.

That's it for now,
Glen

Hi folks,

A warm welcome to the new Ancient Spaces blog. Those of you who have been keeping track of us (through several recent articles and this site) will already know what we're trying to do: in the long run, AS is meant to become a virtual 'multiplayer' world based on ancient civilizations. As a teaching and learning tool, this is a little different than most fledgling MMORPGs: our content will be vetted and continually improved by the academic community (in Greek, Roman, Egyptian, and First Nations Studies, among others), and built from the ground up by our students and its own players.

We've gone through some major developments since the site was last updated:

- Thanks to the modeling team, there are plenty of new 3D environments under construction for the pilot launch this September (mainly for application in courses), ranging from Egypt, Greece, Machu Picchu, and the Northwest Nisga'a First Nation in B.C. Check them out here.
- Thanks to the programming team, the Ancient Spaces platform is expected to go into alpha testing at the end of July, with the beta expected for the end of August. In about two months it will be ready to download as a Windows executable. It's based on OGRE 3D.
- Once the platform is in beta, we'll be sending a notice to our mailing list inviting participation (programming, modeling, and academic).
- The UBC programming & 3D modeling team will now be blogging here on a weekly basis, so I hope there will be enough updates and material to give you plenty to look at in the weeks ahead.

In the meanwhile, check out the website, read more about our team, and let us know what you think so far.

Michael Griffin
Project Mgr.