The Dome of the RockFinal Report

[ Abstract | Introduction | Goals | Achievements | Individual Contibutions ][ Lessons Learned | Acknowledgments | Bibliography | Appendix ]

Abstract

We have constructed a 3D model of the Dome of the Rock, an Islamic religious structure built inJerusalem in the 7th century. The structure is built around the tip of the Temple Mount, the "Rock" ofthe building’s name, which holds great religious signifigance and is the subject of several Muslimmyths. The structure itself is an octagon enclosing another octagon of columns enclosing a circle ofcolumns, which is the smallest enclosing circle of the rock. Our model captures not only the uniquegeometry of the structure, but also its interesting textures, as most of the inside of the Dome of the Rockis covered with mosaics and generously interspersed with marble. Given the information available to us,we made a model reconstructing as closely as possible the 7th century appearence of the building.

Team Members of Team 12

Michael A. Behr, mabehr@MIT.EDU Kari Anne Hoier Kjolaas, karianne@MIT.EDU Marleigh I. Norton, marleigh@MIT.EDU Tara B. Schenkel, etara@MIT.EDU

Back to top

Introduction

The Dome of the Rock, also called the Mosque of Omar, is one of the three most important religioussites to the Muslim religion. It was built in Israel in the 7th Century over the site of King Solomon’stemple. The rock after which it is named is supposedly the site from which Mohammed ascended toHeaven. In addition to its religious significance, the Dome is a beautiful example of Islamic architecture.Therefore, not only Muslim worshippers, but architecture students from all over the world makepilgrimages to this shrine.

Over the past centuries, however, the Dome of the Rock has been damaged, repaired, and modernizedmany times, the most notable of these revisions having been implented by Sultan Sulayman in the 11thcentury. Therefore, some aspects of the current Dome bear limited similarity to the Dome of the 7thcentury.

Our project was to make a computer model of the Dome of the Rock as it was originally built. Therewere several motivations for this project. The first was that, as has been mentioned earlier, the Dome is

located in Israel. For those who can’t make a trip to Israel, a computer model would be their onlymethod of interacting with the structure (looking at it from a different angle than any that arephotographed, for example). In addition, due to the current politics of the area, it is not necessarily safefor visitors to travel to the site in person.

Our other motivation was that if a historian or architecture student wanted to see what the Dome lookedlike in the 7th century, it would be impossible to do so. The best they could do is imagine what it musthave looked like, while we could show them instead. The 7th century version was also simpler than thecurrent version, which would allow us to possibly complete the project within the time alloted.

This project involved a lot of the topics covered in 6.837. This project was an example of computeraided design. By showing how a room, building, or area would look after implementing changes, weduplicate one of the major commercial fields utilizing graphics (though normally it involves futurechanges, not reconstruction). In addition, in constructing the model, we used 3D modeling, rendering(ray rracing), shading, image tapping, and procedural texture mapping.

Back to top

Goals

The goals of the project were straightforward. We split up the building into 4 simple sections, asoutlined in our proposal.

Mike: the outside wall and roof slanting up towards the dome, also the interior up to the first set ofcolumns Kari Anne: the inner set of columns and the walls up to the dome Marleigh: the dome, rock, and railings Tara: the middle concentric circle of columns

Checkpoint 1Friday, October 24

Turn in proposalPlay with AC3DFind the paper Prof. Teller said we should look at on texture mappingand look at it.

Checkpoint 2Friday, October 31

Have the basic geometry of the building doneFit the different pieces together

Checkpoint 3Friday, November 7

Have a complete modelImprove the geometry

Checkpoint 4Friday, November 14

Everything is scanned in, ready to be mappedHave a plan for places which we don’t have pictures ofLook at lighting and animation software

Checkpoint 5Friday, November 21

Inside of building completePlan for presentation (lighting, sounds, etc...)First draft of report done

Final Project Reports DueWednesday, November 26

Report all finished and turned inStart rendering

Final Project PresentationsSaturday, December 6

Present our project

Some of these goals had to be modified as we went along due to unforseen difficulties with the modelingtools avaliable to us.

Back to top

Achievements

All, in all, we managed to finish almost all of what we intended to do, despite some serious setbacks.We built a model of the Dome of the Rock that is geometrically precise and that is textured in anapproximation to the actual structure. The fully textured model is not yet complete, but most of the workis done. In particular, a portion of the interior texture mapping is incomplete, but will be finished andimages of it rendered in time for our final presentation.

Our plan was to create the geometry in some modeling language, port the model to RenderMan and addtextures there. RenderMan is a ray tracer with powerful features for texturing, allowing proceduraltexturing, bump mapping and displacement mapping. We decided not to model the geometry directly inRenderMan since RenderMan is not "interactive" in the way that other modelers such as AC3D andInventor are, since a camera angle must be specified for each individual image produced by rendering.This makes modeling in RenderMan time consuming, since one has to render several images of anobject to look at it from different angles.

The first main issue that we faced was deciding what language to use for modeling. AC3D wasrecommended, so we tried to use that. Unfortunately we discovered that we couldn’t be accurate enoughusing it. The AC3D language is based on a "click and drag" interface. For example, one can’t specify anexact rotation, translation, etc. within the program, and the AC3D file format is not amenable to directmanipulation. Because of these problems with AC3D, because we were all familiar with Open Inventor,

and because we found it much easier to specify precise measurements in Inventor, we decided to switchmodelers. The rock was still modelled in AC3D, however, since it was easier to create objects one doesnot have measurements for in AC3D. We were a bit concerned about combining Inventor and AC3Dobjects, but we managed to do so with very minor difficulties.

We were about a week behind schedule because of the modeler switching, though we weren’t tooworried about that. Kari Anne, Tara, and Marleigh completed their geometry at about the same time,though still a week behind schedule. Fitting pieces together was suprisingly trivial, since we’d all usedthe same scale (meters), direction (z is up, y is north), and measurements from the same blueprints. (Seefigures from Creswell included below) Mike was poked about getting his geometry done and we split upwork again. Things looked ok for texturing when The Great QuadMesh Fiasco occured.

Tara introduced us to an elegant way of coding in Inventor using QuadMeshes. QuadMeshes mostly takea long string of ordered points and turn them into an object. This prevents constant calls toIndexedFaceSet. It’s quite handy on curved surfaces. We all used them extensively in our code.Unfortunately, the IV to RenderMan converter couldn’t handle QuadMeshes. Lots of our code brokewhen ported to RenderMan and needed to be redone. Tara fixed it with RenderMan code, but it set usback quite a bit. In the meantime, Mike still hadn’t gotten his geometry done.

The outside of the building, rendered after the following transformation: Translate 0 -10 45, Rotate -90 1 0 0.

A view from just inside of the south door, rendered after the following transformation: Translate 0 -5 22, Rotate 45 0 1 0, Rotate -90 1 0 0

The inside of the building, a closer view, rendered after the following transformation:

Translate 0 -3 18, Rotate 90 0 1 0, Rotate -90 1 0 0

Because of the problems in converting our geometry, we ended up with only about one week to texture,and Mike’s geometry still wasn’t done. Finally, Tara and Kari Anne ended up finishing most of thegeometry originally assigned to Mike.

One of our original goals was to model the structure as accurately as possible. We encountered somedifficulty in doing so, however, since we obviously did not have direct access to the structure we weremodeling, and therefore, couldn’t take any measurements that we found to be lacking in thedocumentation that we did have. By searching through several different books, we were able to findmeasurements for almost all of the geometry of the building, although in some cases, we did makeeducated guesses.

Floorplan of the dome, to scale (From Creswell).

Cut away side view, looking north, to scale (from Creswell).

We also used a bit of artistic license in applying textures to our model. We did have an abundance ofscannable images, but when we actually went to apply textures, we found that there were some surfacesfor which we didn’t have a picture, or for which the pictures that we did have were unusable. In thesecases, we either repeated a similar pattern that we did have a photo of, or we used procedural texturing.For example, there are many surfaces (such as the interior of the outer walls, and the lower portions ofthe piers) which have marble inlays, or pieces of quartered marble. Since we didn’t have photos thatwere sufficient for image mapping, we procedurally textured these surfaces.

Despite the numerous problems that we encountered, we’ve completed all of the geometry and much ofthe interior texturing. We plan to complete the interior texture mapping and render our final images overthe break in order to have the interior completely textured by our oral presentation. We also hope tohave time to do some lighting and shadowing as well.

Back to top

Individual Contibutions

Michael Behr

Mike was originally in charge of the geometry for the outer octagon of walls, windows, and doors, theinner ceilings, and the angled roof going up to the dome.

The major cause of his delay was the fact that he was introduced to the miracle of QuadMeshes almost aweek after the others were, and was playing catchup from that point on. It was found to be impossible toinsert window holes into walls made out of primitive cubes. Just as Mike figured out how to useQuadMeshes and started implementing them to accurately reproduce the actual walls within .04 metres,the Renderman/Quadmesh incompatibility was discovered, leaving him with the original dillema ofinserting window holes into walls. Once Tara showed Mike basic renderman skills, constructing thewalls, ceilings, and roof became ridiculously easy.

A view of the fully assembled outer portion

The walls were each rectangular solids with seven window holes poked out. The inner and outer ceilingsof different heights were approximated by one single ceiling, due to the fact that had both heights beenused, they would have cut off part of Tara’s arches. The slanted roof was modeled by a cone with acylinder cut out of the center (octagonal pyramids with cylinders cut out of them left an artifact hangingin midair).

Once the geometry was done and fitted with the rest of the model, he concentrated his efforts ontexturing. Because Mike had keys to LCS and was able to use the public workstation during the weehours of the morning when it would not interfere with LCS-related use, he was delegated the task ofscanning in most of the pictures that would eventually be used as texture maps. He was also responsiblefor touching up those photos which Marleigh didn’t.

During the final week of the project, we found that figuring out how to texturemap was not going to beas easy a task as was originally thought. After consulting with Michael B. Johnson of Pixar Studios , hefound the proper C coding and RIB encoding for applying texturemaps in Renderman. He created hisown shader, some procedural texturers, and textured the ceilings and the entire inside drum whileKarianne volunteered to use procedural texturing to cover the insides of the octagonal walls with marble.

Textured Ceiling

The Outside of the Textured Drum

Kari Anne Kjolaas

Kari Anne was in charge of the geometry for the inner circle of columns and the wall of the inner drum.

After completing this, she took on the modeling of the window screens in order to make the other teammembers able to concentrate on texturing.

Segment of the outer wall with windowscreens, procedurally textured.

After finishing the geometry, Kari Anne took over responsibility for the procedural texturing from Mike.She was alrady in charge of bump mapping for the Rock. She rewrote shaders form the RenderManCompanion in order to create several different marble textures for the outer walls, the floor, the base ofcolumns and the window screens. She created a copper shader for the outside of the Dome and the top ofcolums. The wood shader from RenderMan Companion was modified to simulate a lighter shade ofwood and applied to the railing around the rock. The granite shading was rewritten and applied to therock itself.

While doing this Kari Anne eded up adding doors to Mike’s geometry and adjusting the position of theouter walls. She was also in charge of rendering a series of images to be used for the paper and finalpresentation. This took some time since the complete model takes 20 min to render, and the cameraangle needed to be adjusted several times for each image. She also scanned in the first set of images andtransferred them to imagery4 (slow....).

Kari Anne’s geometry, snapshot for Inventor

Marleigh Norton

Marleigh’s original responsibility included several things, such as geometry for the dome, rock, andrailing, the self-imposed task of "Web Guru", and texturing.

The dome was written in OpenInventor using QuadMeshes for the ribs and IndexedFaceSets for the rest.Unfortunately, QuadMeshes do not translate into RenderMan that well, so the final product wasmodified in RenderMan by Tara. The actual dome consisted of many rectangles of burnished metal.Marleigh attempted to capture this by making the dome out of rectangles instead of the Sphereprimative. The finial on the dome was a guesstimate of the original finial, as neither pictures normeasurements exsist of the original. The finial in Inventor was a typical finial of a mosque, a spire a fewmeters tall topped by a cresent moon facing upward. Unfortunately, this moon was also made using aQuadMesh and therefore was not translated into RenderMan well. Tara made an approximation toMarleigh’s Inventor-modeled moon in Renderman.

The dome in Inventor (left) and the textured dome in RenderMan(right).

The inside of the dome was a disc and a wedge cut out of a hemisphere rotated and copied in order tomake an inverted bowl, coded in Inventor. Doing it this way instead of just making a hemisphere wasintended to make texturing easier (which it did), since the goemetry was repeated in the same manner asthe pattern of the texture. Of course, the wedge used QuadMeshes, so Tara corrected the code inRenderMan.

The hemisphere of the inside of the dome, textured.

The rock was done in AC3D by taking an outline of the rock on a transparency, holding it up to thescreen, and clicking around the edges. This was the only coding done in AC3D. Marleigh insisted onusing it because it is much easier to construct irregular objects in AC3D than Inventor. The rock is notexact, as there are very few pictures of the rock and no exact measurements.

The rock as viewed from the AC3D viewer.

The railing was Marleigh’s interpretation of the original railing. After asking advice from ProfessorRabbat, she was told:

"The early sources speak only of a railing made out of some fragrant wood, something like

ebony, but no shape or pattern are known."

The railing was made in Inventor, but using the points from AC3D that defined the rock .

The textured railing.

Marleigh was also surprised to get the task of adjusting the scanned images to be textured. She did thisusing Photoshop. Tasks included correcting skew, erasing glare, removing all but the part of the imageto be textured, cropping, and backing up the orginial scanned images so the locker wouldn’t overloadand crash.

Finally, Marleigh’s was the "Web Guru". She took it upon herself to make templates for everything weput on the web, taking occasional pictures to put in the final report, and generally making sureeverything looked aesthetically pleasing. She also ended up trading her texturing with Tara for takingover more of the final report, though she intends to work on texturing after Thanksgiving. Marleighwrote the "Achievements" and "Lessons Learned" sections of this report, as well as her own and Tara’s"Individual Contributions".

Tara Schenkel

Tara’s model of the Octagonal Arcade

Tara’s contributions include:

Geometry: the Octagonal Arcade (and much of the geometry originally assigned to Mike,including one instance of the outer wall, the floor, and ceiling) IvtoRenderMan

changing the quadmeshes in everyone’s geometry to RenderMan code adjusting parts of the model that didn’t transform to RenderMan correctly

Resident RenderMan Expert Image Mapping Some manipulation of photos in PhotoShop

Tara was assigned the Octagonal Arcade (middle concentric circle) of the Dome. She modeled thisgeometry in Open Inventor.

Tara was then put in charge of converting all of the Inventor code to RenderMan code. She correctedscale and translation bugs that popped up during conversion. She was also the one who discovered thatthe converter couldn’t handle QuadMeshes. Luckily, she learned enough of RenderMan that she wasable to fix the code that used QuadMeshes by replacing it with RenderMan primitives. She fixed herown, Karianne’s, and Marleigh’s code. After fixing the QuadMeshes, Tara also wrote a large portion ofMike’s geometry.

Finally, Tara has been working on texturing. She has done most of the image mapping on the model.Originally, Marleigh was also supposed to be texturing as well, but Tara traded her portion of the paperfor Marleigh’s texturing. Tara is likely to continure texturing after this paper is turned in. She also wrotethe "Appendix" portion of this paper and modified both the "Achievements" section and the descriptionof her own contribution.

Back to top

Lessons Learned

The one main thing we all learned well was that projects always take longer than they ought to. Due totechnical difficulties, lack of information, and other infinite frustrations previously mentioned in thereport (the QuadMesh Fiasco comes to mind), we ended up behind schedule.

We all learned how to model from blueprints. Each of us (mainly Kari Anne) did research on the Dometo find measurements and pictures. We also discovered that not everything was mesured orphotographed to our specifications, so we learned to take creative licence and guesstimate in order tomake things look right. Prof. Rabbat in the Architecture Department was a great help in figuring outgeometry. His guesses had the advantage of being more educated than our own would have been.

As for technical skills, we all honed our coding in OpenInventor. Tara introduced us all to a fabulousconstruct in Inventor called QuadMeshes, which we all became adept at using. We also learned enoughabout AC3D to realize that it was almost completely unsuited to our needs. The one hold out wasMarleigh, who modeled the rock in AC3D. She learned a great deal about the tool in the process, andcurrently scorns it almost as much as the rest of the team. Mike and Marleigh also learned what theysuspect they should have gotten out of Problem Set 3A, that being using C code to generate Inventorfiles. This method was used extensively by all members of the team.

Dealing with images was another big time sink. Kari Anne learned to use a scanner and Marleigh hadher first experience with Photoshop, which she became rather good at using. She also saw her first zipdisk. Mike also used the scanner and Photoshop a bit, but already knew how. The big lessond from thispart of the project are to check for corruption of files after ftp-ing them and that it can take an hour todownload a single image over a modem.

Renderman was a language we all learned. None of us had any experience with it before this project.Tara is probably the resident expert, since she also had to deal with the IV to RenderMan converter andfixing it where it messed up. Mike and Kari Anne are also fairly knowledgable about the language.Marleigh learned enough of Renderman to move things around and take nice pictures. She intends tolearn more of the language after Thanksgiving break. Kari specialized in bump mapping and proceduraltexturing. Mike read up on procedural texturing. All of us are likely to work on texture mapping afterThanksgiving break.

Back to top

Acknowledgments

Prof. Rabbat - helped with library research and patiently answered questions Jon - what a TA was meant to be, offered lots of advice Prof. Teller - pointed us to resources along the way Laura Baldwin - lent Marleigh her computer, Photoshop advice Kate Mahoney - Photoshop advice Michael B. Johnson - Renderman advice

Back to top

Bibliography

Allan, James and Creswell, K. A. C., A Short Account of Early Muslim ArchitectureCairo: American University Press, 1989 Creswell, K. A. C., Early Muslim Architecture, vol. 1

This is where we found the blueprints for our geometry Ettinghausen, Richard and Grabar, Oleg, The Art and Architecture of Islam: 650-1250London and N.Y.: Penguin Books, 1987 Grabar, Oleg, The Shape of the Holy: Early Islamic JerusalemPrincetorn, N.J.: Pronceton University Press, 1996

A lot of the photos we used to texture the building came from this book. Nusbeibeh, Said, The Dome of the RockNew York: Rizzoli, 1996

A lot of the photos we used to texture the building came from this book. Prochazka, A. B., MosquesZurich: Muslim Architecture Research Program, 1986 Upstill, Steve, The RenderMan CompanionAddison-Wesley Publishing Company, 1990

Some of the shaders we used for procedural texturing were modified versions of shadersfound in this book.

Some sites found on the Web:

A 3D model made b y ArcVertuel, Inc (no textures) Dome of the Rock web page, created by Roger Gaudy Islamic Association for Palestine page of Islamic Holy sites, several photos University of Texas Muslim Students Association architecture page, several photos o f interior andexterior On-line guide to the Noble Sanct uary Photo of facade, Great Buildings Index Detail of facade, Great Buildings Index Photo of the Noble Sanctuary, Great Buildings Index Renderman Toolkit Documentation

Back to top

Appendix

Rendering Description and Instructions

Our model of the Dome of the Rock is written in the RenderMan interface language. The geometry isspecified with the positive z axis pointing up and the positive y axis pointing north. The mean floor levelis at z=0. Our entire model is contained in one RIB file, which was created by cutting and pasting eachof our individual RIB files. The still images in this paper were rendered on an SGI Indy using the rendershell script, (i.e. render dome-of-the-rock.rib) which submits the RIB file to the default RenderManrenderer. Although the renderer outputs TIFF files, we converted to GIF and re-sized most of the imagesincluded in this document in the interest of saving space. (Images not from RenderMan are so noted inthe caption.) Thus, the images included in this document are of lower quality than our actual results.

The various camera angles for each still image were specified inside the RIB file directly. TheRenderMan camera is always at (0, 0, 0) pointing along the positive z axis: as a result, most of ourimages are rotated -90 degrees around the x axis to make our "up" direction actually point up, and thenfurther translated and/or rotated to adjust the view. (Note that rotations around the axes follow the "lefthand rule" in RenderMan.)

Our procedural shaders were written in the RenderMan shading language. The shading language sourcefiles (*.sl) are compiled using the shader command, resulting in the files (*.slo) suitable for execution inthe renderer’s run-time environment.

The original scanned images that we texture mapped onto our geometry were converted to theappropriate format for textures (*.txt) using RiMakeTexture(), a RenderMan subroutine.

Notes on the Individual Contributions Writeup

There have been severe problems with individual performances during this project. The rest of the groupfeels that Mike’s write-up of his individual contribution does not accurately reflect the work actuallydone. He was not willing to change the segment, so we are writing this note in order to give what we feltis a more accurate view of how the group worked on the project.

We would like to specify that Marleigh Norton had left for Thanksgiving before Mike posted his part ofthe paper. Although she has expressed some of the same concerns, she was not part of writing thisaddition.

Kari Anne told Mike about Inventor QuadMeshes at the same time that she and Marleigh learned aboutthem. Not knowing about QuadMeshes can in our opinion not be used as an excuse for being late withhis geometry. Furthermore, to our knowledge he never had an Inventor file for his assigned geometrythat used quadmeshes, and we can’t see how the trouble converting to Renderman effected his work atall.

We feel very strongly that the sentence "Once Tara showed Mike basic renderman skills, constructingthe walls, ceilings, and roof became ridiculously easy." is incorrect. Tara met with Mike to help himover one week after his geometry should have been done. She feels like she did not show him skills, butin fact did his work while he watched, creating the inner ceiling, floor, and one instance of the wall. AllMike had to do was repeat and rotate the wall, and complete the roof. This was done incorrectly andKari Anne had to change the translation of the walls because they were not aligned properly. She alsoended up adding doors to four of the walls. As a result of this, the geometry of the outer walls is lessdetailed than that of the rest of the building.

We all agree that Mike has spent time scanning. However, we feel that this time is in no waycomparable to the time the rest of us has spent modelling and texturing. Mike also has explained that hehas spent significant amounts of time learning to use the tools. This may be correct. However, herepeatedly refused offers of help from the other team members.

Early in the project Kari Anne took on the additional modelling of the widow screens in order to makeMike able to concentrate more on texturing. She feels like this agreement has not been honored. Mikewrites "After consulting with Michael B. Johnson of Pixar Studios , he (Mike) found the proper C codingand RIB encoding for applying texturemaps in Renderman. He created his own shader, some proceduraltexturers, and textured the ceilings and the entire inside drum." None of the team members have yetseen any texturing done by Mike. All of the texturing seen in this paper is done by either Kari Anne orTara.

Kari Anne Kjolaas and Tara Schenkel

Back to top