Wednesday, 9 April 2014

What is essential is visible to the eye (if you're in my model)

I hope the ghost of Antoine de Saint-exupery won't haunt me for having played with the wise words of his Fox characters, inverting their meaning. I wasn't suggesting a triumph of shallowness and prejudice, but just introducing a brief premise about my 3D modelling process. 

F. Piranesi's hypothetical restoration of the Iseum (detail)
showing the roof's supporting structure.
From builtindex
I have said that the first phase of my modelling will focus on the present archaeological evidence in situ. I might have called it “what is still there”. The expression is not entirely correct because what I am going to model is actually what we can see of what is there (assuming that we were free to  explore the whole Iseum as much as we like). 

In practice, this means that, for example, I am going to model the Purgatorium's underground space, even though it is not immediately visible and it is not accessible to modern tourists without a permit, but is potentially both visible and accessible.

On the other hand, I won't model what is not visible. To explain ti better, I can use an hypothetical example: let’s imagine that the roof of the Temple had survived. In that case, I would model only the ceiling (which is what an observer could see from inside the Temple) and the external elements such as the tiles or the architrave (which is what an observer could see from the outside of the Temple). But I wouldn’t model the (invisible) supporting structure. 
I am sure that modelling what actually allows a roof to stand (for many centuries!) is of massive interest in the study of architecture and ancient building techniques. 
As I am more interested in how a building was seen and experienced by people (either at as a Roman Temple or as a modern Touristic Attraction), I have decided  to include in my 3D model only what is accessible to the eyes of a human being that is allowed everywhere in the modelled space. 

The matter would be different if the hypothetical roof would be damaged. Then, the internal structure would be visible to visitors and part of their experience (and, therefore, object of my representation).

Tuesday, 8 April 2014

Everything has (at least) two faces: about walls and normals

At the walls, by S. Bakalovich
from wikipedia
 To explain how I am going to deal with constraints, I will use the simplest, and most common, type of them: walls. Although they often look just as think lines on a plan, walls cannot be represented as flat two dimensional areas. That would contradict our experience and wouldn’t make any sense geometrically, as walls are three dimensional objects with different depth. 
It is possible that at the very beginning of your 3D modelling career you are tempted, quite naively, to simply trace the shape of your walls and extrude them as a solid. In case, the puzzled expression of your supervisor and the question “what is that supposed to be? Minecraft?” will quickly tell you that you’re on the wrong track.
What you are supposed to do (or, at least, what I am going to do) is to build two separate surfaces, one for the interior and one for the exterior, without modelling what is in between (i.e. the actual thickness of the wall).

There are a few reasons why I agree it is a sensible approach.
First, walls (as well as every other constraint) may display different material or decorations on the inside or the outside. So, in the model, they will probably have different textures assigned. 

Also, as we were discussing in the other posts, there is a logical (or ontological, in the linked data meaning of the word!) benefit in it. A wall often delimits two different spaces. But, more specifically, one side of it delimits one space and the other side delimits another space (or spaces). For example, the wall that separates the ekklesisaterium from the sacrarium, is the internal southern wall of the ekklesiasterion on one side, but, on the other side, it is the northern internal wall of the  sacrarium.

It may sound confusing at the beginning, but, after you get used to that, it is a simple yet effective convention that has proven his usefulness in my previous models already. I think it will also suit well the RDF modelling and help dividing meaningfully my digital archive.

If there weren’t enough reason to justify a separate management of the two surfaces of a wall (or other constraint), game and VR engines give us another good one: normals. Surfaces are visible only from one view, either from the interior on the exterior. Even if we had a wall with the same identical texture (let’s say a generic masonry), to allow a 360° virtual view of it, we still would need two surfaces: one looking towards the interior and one looking towards the exterior. This is the only way a character (or a camera) can have a realistic view of a virtual building when it is walking into a space as well as when it is walking around it.

Monday, 7 April 2014

Academic guilty pleasures: inventing words and making lists

What I needed in order to start, was a general name to identify everything that is in model. I know that even such an apparently harmless sentence can hyde insidious philosophical controversies. At this stage of my modelling, what I want to represent (both visually and conceptually) is the archaeological evidence, i.e. what can be still seen (and potentially measured) in situ at Pompeii. Further layers of visualisation that involve a bigger amount of speculation and interpretation, will be analysed (and modelled) later on.

Classification of the Greek Orders
from wikipedia
 The terms that I am using are just draft, at the moment. I hope to find something better in the future or even to discover that someone else has already worked out a more convincing naming system and is willing to share it with me.

The word I have chosen for all the components of the model is «element». I think it is abstract and general enough to be associated with pretty much anything (in any 3D model) and it covers logically both the tangible and intangible domains. 
There are no limits to the number of elements in a model or to their size.
After a certain amount of head-banging against the screen of my computer, I think I have identified three different categories of elements. I have tried them against both the Iseum and the House of Orpheus. It seems to me that they kind of work, and cover all the possibilities in a relatively sensible way. But I wouldn’t be surprised if someone pointed out some discrepancy. 
The three groups are:

1) spaces
2) constraints
3) transitions

To be completely honest, this is probably all I need to assign meaningful names to the elements in my 3D model or to catalogue my digital archive of resources. But I thought it was useful to refine the classification a little bit, thinking of a future (potential) higher complexity. 
(The fact that I actually enjoy making lists has absolutely nothing to do with it)
The classification itself, is very likely to be influenced by my 3D modelling experience and by the way I had been taught to approach ancient buildings (especially Pompeian ones) and their components.

Plaster cast of a Pompeian door.
Photo by Günther Einhorn
via Pompeiiinpictures
I call «spaces» the elements that allow activities to happen within them. Very straight forward examples of spaces are all sorts of rooms but also gardens, portici, courtyards, etc...
«Constraints», on the other hand, are elements in which activities cannot take place, and usually serve as boundaries for spaces. The most common type of constraints are walls, but colonnades, podia and roofs will be considered constraints as well. A space is supposed to be delimited on each of its sides, although not all the constraints are tangible. A change in the mosaic pattern can delimit a space, even if there are no walls to mark the separation. To be precise (and slightly pedantic) the tangible constraints can be divided into permeable and impermeable. To the latter clearly belongs plain walls or high gates. To the former, belong colonnades. Although some constraints (such as colonnades) are physically permeable, I suspect that they were not always considered as such in practice. I can hardly imagine someone being allowed to jump down the Temple of Isis’ podium  through the pronaos’ colonnade. However, I will consider only the material qualities to assign the constraint to one or the other category. All the ones we have mentioned so far are permanent constraints (both tangible and intangible), but we know that Romans had temporary ones as well, such as curtains or removable fences. The existence of temporary constraints implies, I guess, the existence of temporary spaces. As I am currently working only on the present archaeological evidence, temporary constraints or spaces are not object of my attention now. 

Last, «transitions» are those elements that connects spaces and, as such, they do not belong to either of the two elements they connect, but are independent. We will consider two kinds of transitions: the ones that allow physical access from one place to the other (such as thresholds or stairs) and the ones that allow visual access from one place to the other (such as windows). Likewise the other two elements, they can be permanent (a stone staircase) or temporary (a ladder). 

Spaces, constraints and transitions can all have «features». Features is used, as the dictionary suggest, to indicate “a distinctive attribute or aspect of something”. 
Features often pertains to the decoration of a space, or a constrain, or a transition. It is easy to identify constraints features, as they are basically contiguous. For example niches in the walls, engaged columns, mosaic floors. But also transitions’ features are usually easy to spot (windows moulding, or doors). Stand-alone features, that have no physical contiguity with any other element (such as altars or herms), will be considered features of the space in which are situated. So, for example, the altar in front of the Purgatorium in the Iseum is a feature of the cavaedium. 

Circular colonnade in the Temple of Vesta, Rome.
Photo by E. Trutat, Bibliothèque de Toulouse
Any element can be divided into sub-elements, according to the level of granularity that the research requires. The sub-elements can be either areas or constraints. For example, in the Iseum, the element space temple can be divided into sub elements pronaos and cella (spaces) and roof and podium (constraints). The Temple also has quite a few transitions: staircases, thresholds, etc...

The same constraint can delimit more than one space, especially when they are subelements of the same space. In the element Temple, constraint roof delimits both sub-elements space pronaos and cella.

It could be argued (especially after a couple of drinks) that the part of a constraint, let’s say a wall, that delimits a space, is conceptually different from the part of it that delimits a contiguous space (such as the wall shared by three of the private rooms in the Iseum). 
In this case, 3D modelling’s logic has stepped forward helping me in two ways. In the first place, reminding me the practicality (even the “materiality” if I can use this word) of the process. Digital 3D models should be optimised for Real Time engines or any other platform that makes them explorable by the users. Therefore it is crucial to keep the number of polygons under control. The less polygons, the faster is the loading process and smoother the character/camera movement.
Also, a limited number of polygons ensures a better control on the file for both the original author and the potential other researchers that want to build on top of it.
On the other hand, I will deal with the conceptual separation of constraints through their internal and external surfaces.

If what I have just written sounds a bit sibylline, I am going to explain myself better in the next post.

Thursday, 3 April 2014

Breaking down reality

Greek philosopher Parmenides
image from wikipedia
Dividing the Iseum in its main components and work out a naming convention that made sense in the 3D modelling context as well as in the RDF one, seemed a sensible starting point to me. 
However, reality is a continuum and every attempt to break it down according to our logic(s), and partly to our needs, is bound to result in long hours of discussion, over-consumption of coffee, and a severe headache. The meaning of words and concepts gets challenged over and over again in endless loops, going inevitably back to pre-socratic questions about «being» and «existing». 
The point is that every division and classification is artificial, no matter how much we are fascinated by The Myth of Perfect Consistency or how much we try to be objective.

Objectivity is, probably, a common self-delusion among ontologists. In my opinion, personal and cultural biases can be partly counter-balanced through collaboration and the expression of multiple hypotheses and interpretations. However, at this stage, I have to work on my own in order to produce a proof of concept. So, the best I can do is to record my methodology, so that I can revise it after having received feedbacks.

About naming convention: I was tempted, at the beginning, to use human readable names. I thought it would have made my 3D model much more accessible and easy to look at for other modellers. I had even thought of using Latin to label well identified areas, and more generic names, always in Latin, for the one that have not been identified yet. After discussing it, I have decided to abandon the idea for two main reasons:
Colour map of the elements of the Iseum
1) it is not always so straightforward to label a space. The fact that I am mainly working on the Iseum can be deceptive under this respect. Roman sacred architecture tends to be quite formalised. So there is little to argue if I want to call the pronaos «pronaos». However, it’s not the case for every building in Pompeii. 
A look at my comparative example, the House of Orpheus, proved to be very useful. There are many spaces that do not have an agreed identification, and different scholars refer to them with different names. Not to mention that the upper story(ies) are entirely hypothetical. 

2) Giving a meaningful label means already to make assumptions about the use of a space. And I am trying very hard not to express interpretations at this level. 

In the end, I have opted for a more abstract convention and I will simply use letters (in the English alphabet) to label the components of my model. 
Through RDF triples, I will then express that, for example, room A is type kitchen according to scholar 1 and that the same room A is type storeroom according to scholar 2.

About identification of elements: In the case of the Iseum, the identification of the main components didn’t seem very difficult to me. The different blocks stands out fairly clearly. Even before making (or agreeing on) assumptions on the use of the spaces, they look pretty much neatly separated from a geometric and structural point of view.
I’m using the first published plan of the Iseum ever published (Saint-non’s one) to illustrate the first division into the main elements. In order to avoid confusion, I have erased from the original map the letter-based naming convention that Saint-Non himself used. Next to the letters, I am listing in the legenda also word labels for the sake of clarity, following a widely accepted convention about the Iseum.

Some of the elements can be divided in sub-elements or grouped in super-elements (the relationship being very easily expressed through properties such as :isPart Of or :hasPart). Some of this relationships are very quickly recognisable looking at the plan. The element C (Temple), for example, can be divided into element H (pronaos) and I (cella). The latter, also contains a sub-element J (cellar). Likewise, space G can be divided in several sub-elements.

Close up of the Temple of Isis
However, buildings are not flat, and spaces are not divided only along an horizontal axis. If we look at a cross-section of the Iseum, then we will notice that the Temple is not only made by pronaos and cella, but also by a podium and a roof. And the Purgatorium has a ground level room as well as an underground one.
Last, we can hypothesise the existence of a second story for at least one of the rooms of the private area, although it isn’t in any plan or blueprint of the Iseum.

So, the whole list of the elements in which I have divided the Iseum is a bit longer than the one showed above, but it is probably not interesting to publish it here.
If reading this post you have started mumbling things like: “do a roof and a room belong to the same category”? “what about stairs?” “what about the altars and the statues?”, I know exactly that feeling and this is why I have spent a few nightly hours searching for some convincing answers (that I will publish soon).