Modeling Maynooth Castle Part 2 – Crafting the Walls

In my first blog on modeling Maynooth Castle, I discussed the goal of my final project for AFF621 and a little bit of the background regarding the castle itself.  As I began the process of modeling the castle, I decided the first place to start would be to model the walls, which is what I intend to discuss today.  However, before I get started, I’d like to take a few moments to discuss the planning of the model itself.

A Little Project Planning

Like some graphic design software, such as Adobe Photoshop, 3DS Max requires you to think through how the model is going to be constructed, so that you can be organise your scene.  In order to start this process, I started thinking about what kind of objects would be in my scene, and how I wanted to arrange them.  I came up with the following major items that would need to be a part of the scene:

  • the castle walls
  • the keep
  • the church
  • the gates
  • the living quarters / kitchens / etc.
  • miscellaneous buildings (such as the stables, barn, etc.)
  • the river(s)
  • misceallaneous nature (trees, grass, any other surrounding items, etc.)

Depending on how quickly I am able to execute on the model itself, I may or may not be able to complete everything, so I’ve decided to prioritise the first 5 items with the hope of adding the other objects should I have the bandwidth.

In order to facilitate this process, I decided I would keep each of the above mentioned-sections in their own layers.  This way I could easy turn off entire sections if needed (which could be helpful while fine-tuning other aspects of the scene). Additionally, by grouping them in layers, I can focus on each section at a time—very similar to how I would construct a physical model from legos or other building material(s). With these decisions made, I decided it was time to start the actual modeling process.

Constructing the Walls

I decided to start with the walls for two reasons:

  1. They would form the boundaries of the rest of the inner buildings of the castle itself
  2. They would most likely be the easiest thing to model

I decided to do a quick Google search to begin with just to see if anyone had modeled anything similar in 3DS Max and might therefore have some insight into the process of building walls.  I was lucky enough to happen upon a video that discussed how to construct a castle using 3DS Max.  I watched some of it and decided that it may be useful later, so I’ve filed it away for future use. I also found a script that was created to make the construction of walls easier.  I thought this might be the ideal script to facilitate the creation of walls, so I downloaded it and started using it in my scene.

Unfortunately, the script wasn’t quite what I was looking for.  It’s the kind of script that is great for creating brick walls, but one of the biggest problems I had is that, while it allowed me to set the number of segments for length and height, I couldn’t set the number of segments on the width.  Since I needed to create crenulations along the top of the walls, using this script would have meant manually creating individual crenulations as opposed to using some effects on the wall itself.  I also discovered the script was very computationally intensive and a single wall greatly reduced the processing power of my laptop.  Ultimately, I decided to discard the script and create my own walls from scratch.

I decided to start by creating a box that met the dimensions of the wall I was trying to construct.  I then gave the wall an appropriate number of segments for length, width, and height that would simulate brick work. For example, the south wall is 86.8 metres long, 3.51 metres wide, and 4.96 metres tall. As a result, I gave it 86 length segments, 3 width segments, and 5 height segments which makes each stone roughly 1 metre x 1 metre x 1 metre.  This was an arbitrary decision but one I felt was reasonable.

After drawing out the wall, I converted it to an editable polygon and then used the extrude tool to create crenulations along the top.  I decided each crenulation would be roughly 2 polygons wide and 1 polygon deep, and would be extruded by 1.016 metres.  I then built the remaining 3 walls following the same pattern.  When I was finished, the scene looked as below.  Note: each wall is color coded so I can easily keep track of what wall it is.  The south wall is red; the east wall is yellow; the north wall is green, and the west wall is blue.

Walls_Start

Next, I needed to fit the walls together.  The castle walls themselves do not form a perfect square, but rather bend at some points to create a sort of rounded, circular square.  There are also some breaks in the walls where the walls either protrude or where the walls are broken up by gates or other buildings. I accomplished this in a number of ways: by creating generalised boxes of the appropriate size as placeholders, by cutting up the walls to create the protrusions, and by using soft selection to bend sections of the walls. The outcome can be seen below.

Walls_Connect

As you can see, there was a drastic change in the state of the walls from their first construction.  It’s slowly starting to come together.

Further Struggles

One of the things I’ve struggled with a bit is the application of materials. I have some images of the castle walls themselves. I was hoping to apply them as both a bump map and a diffuse map to create the illusion of stone on the walls.  Unfortunately, it hasn’t worked so well.  Either the images tile too much and look fake, or they blur and, well, look fake.  This will be something I’ll have to work on more later.  I’m sure I’ll blog about it in future posts.

Next Steps

Next, I’m going to focus in on the castle keep and the enclosing walls. Hopefully this will be a little easier than the outer walls, especially now that I’ve picked up a few tips and tricks. More to come later . . .

Modeling Maynooth Castle Part 1

For my final project for AFF621 – Remaking the Physical, I was tasked with creating a 3D model of a cultural heritage object.  After considerable deliberation, I selected Maynooth Castle, which is a castle that once stood in the heart of Maynooth and was a major seat of power in Ireland from its construction in the latter part of the 12th century until its seige and destruction in 1534.  I selected it for two primary reasons: my love of ruined castles and the lack of information showing what the castle likely looked like during the height of its power, prior to its destruction.

Over the course of several blogs, I will recount the steps I have taken to produce the model and what trials and tribulations I have endured.  This is my first forray into creating 3D models, and while I’m excited to see the final output, I must admit to some trepidation regarding the scope and ambition of my project.  But I have always risen to a challenge, and this time is no different.  Hopefully, my efforts will be met with success, and by documenting my process and trials as I go, hopefully not only will I learn something from the experience, but so, too, will my readers.

Researching the Castle

The castle itself was originally built in the latter part of the 11th century and was a seat of power for the Fitzgerald family.  While I will save much of the formal history of the castle for my official report, I will note that the castle stood as a whole for nearly 300 years.  It fell in 1534 after a 10-day seige by the British, thanks to the rebellion of Thomas Fitzgerald, 10th Earl of Kildare.  While the castle was restored in 1630, it was destroyed again in the 1640s during the Irish Confederate Wars.  Since then, the castle has remained in ruins and is now run as a cultural heritage site by the State. It is open during the summer months for tours.

Unfortunately, due to the age of the castle, not much information remains regarding what it may have looked like during the height of its power, so most of my model is based on speculation of architects and other historians much more qualified than I.  I will be building my model based on their work, and my report will detail those sources in depth.

Some of the information I received was from some older documents stored in the special collections area of the Maynooth University library.  These included a map of County Kildare (which had a lovely write-up regarding the history of the castle), as well as some hand-drawn images of the castle ruins at the time of publication in 1783.  Additionally, the library was also able to provide me with a development plan that was created for the Office of Public Works in the mid 1990s that included some architectural plans that were drawn up during the castle’s first reconstruction in 1630. Additionally, this document also contained some speculation from the architects creating the development plan as to what the castle may have looked like in the 15th-16th century prior to its fall.

Looking at the Models

Another source of information was the model housed within the castle.  When Maynooth Castle was converted into a cultural heritage site, a scale replica of what the castle likely looked like was created.  This scale model is housed within the keep (which serves as a type of museum for the castle itself).  Catherine O’Connor, the supervisor of the site, was gracious enough to provide me with early access to the castle keep (which is currently closed for the season) so that I could photograph the model and take measurements of each of the buildings.  This will allow me to construct my 3D model as accurately to this model as possible.  Ms. O’Connor was also able to provide me with some additional documents that detailed an archeaological excavation of Maynooth Castle that was conducted in June of 2000. Finally, Ms. O’Connor also provided me with contact information for one of the architects who worked on the development plan.  I will be reaching out to him over the next few days in hopes that he can provide me with any further information that may be of use.

Next Steps

The next thing I will begin tackling is the creation of the model itself.  I will likely begin by trying to create the outer walls, as well as the keep.  I will be doing this from the ground up in 3DS Max.  My next post will be written after I have begun tackling some of these aspects and will detail what struggles (and hopefully triumphs) have resulted from this endeavour. Stay tuned . . .

Perils of Project Planning

For my contribution to the Woodman Diary, which is the project we are creating for Digital Scholarly Editing, I took on the role of Project Manager.  I thought I would take a few moments to discuss something that is often discussed but overlooked in any software project:  project planning.

What is Project Planning?

Project Planning, as defined by Rouse, is “a discipline for stating how to complete a project within a certain timeframe, usually with defined stages, and with designated resources.” [1] The three components—scope, schedule, and resources—mentioned by Rouse are often referred to as the “Scope Triangle” or “Triple Constraint”. The notion of the “Scope Triangle” dictates that the scope, schedule and resources form three sides of a triangle.  In the “Scope Triangle”, one of these resources is always fixed, and the other two, while flexible, move in proportion to the other.[2] For example, if schedule is fixed—meaning the delivery date of the project cannot be changed—then if additional scope (new features) are added, more resources (also sometimes referred to as budget) must be added to accommodate the increase in scope. The “Scope Triangle” is used to ensure both the stability and the overall quality the project and its deliverables.  After all, one cannot logically assume that a project, which was originally stated to take x number of months with y number of features given a budget of z, can still launch at the same time if the budget is suddenly reduced or if new features are added.

Consider this analogy. You decide to build a new home, and so you hire a company to do the work.  You agree with the company that they will build a 1,000 square foot home in 6 months for €100,000. Three months into the project, you decide 1,000 square feet isn’t big enough, and you wish to add another 500 square feet to the home.  Certainly you would expect it to cost more—and quite possibly take longer—than what was originally agreed to. However, for some reason, this notion often flies out the window with regard to software projects. Thus project managers are often brought in to ensure the “Scope Triangle” is adhered to, and the project remains on track with a high level of quality.

Perils & Pitfalls

Most think of project planning as creating Gantt charts and putting dates on deliverables. And while that is certainly a component, it is far from the only aspect. Below, I’ve listed some of the most common mistakes that can be made in regards to project planning:

  1. Thinking Too Small – project managers need to think big, and I don’t mean in regard to scope.  The biggest mistake that can happen while project planning is not considering all of the possible avenues. What if we lose some of our resources due to illness or vacations? What if the server blows up, and we need to buy a new one? What if some feature we really like isn’t technically feasible? All possible avenues need to be explored during the planning phase.  There is no scenario too far-fetched.
  2. Making Assumptions – often, we make assumptions about the projects we are working on. “The computer centre will set up that server for us.”  “That feature is very easy to implement—I’ve seen it done before.” “That software is easy to customise.” The list of examples is endless. But what if the computer centre is unable to set up the server due to their own time or resource constraints? What is the software isn’t so easy to customise or is restricted due to licensing constraints? What if that feature seen elsewhere took months to build and isn’t distributed and thus must be recreated? All of these items can have a significant impact on a project and cause it to derail.  Therefore, it is important to identify assumptions early on and plan accordingly.  Making assumptions is not necessarily a bad thing, but failing to identify them is a major problem.  If they aren’t identified, then contingency plans cannot be created.
  3. Failing to Identify Risks – every project has risks.  Some are obvious: loss of resources due to illness, scope creep (the subtle addition of new features that, while individually seem small, cumulatively add considerable scope to a project), scheduling constraints, etc.  Every project, however, has risks that are unique to the project itself.  For example, while planning for the Woodman Diary, we identified a risk regarding our software implementation.  At the time, we had yet to choose a software package for the diary, so there was a risk that the package we chose could have an impact on our schedule, as it could potentially be more difficult to implement that we assumed (also, for further emphasis, see above item regarding assumptions). Identifying risks early on allows the team to research mitigation tactics.  In fact, not only should every risk be documented, but a mitigation plan should also be created for each risk in order to identify how likely the risk is, what its impact on the project overall could be, and how the risk will be mitigated. By doing so, the team reduces the potential number of surprises that could arise during implementation.  The fewer surprises, the smoother the implementation.
  4. Forgetting the Goal – every software project has a sense of excitement about it.  The team is creating something new and many participants want to innovate or make something that has that “wow” factor.  Thus, it’s easy to get caught up in the “glitz and glamour” and forget about the goal. Whenever the team is considering adding a new feature or changing an already defined feature, the first question that should be asked is: does this change bring us closer to accomplishing the goal of the project? If the answer is “no”, then the feature should be scrapped.  It doesn’t matter how “neat” the feature might be; if it doesn’t serve the goal of the project, the feature is ultimately a distraction.  Of course, if the team answers that question with “What is the goal?”, then a much bigger problem exists.  Before project planning even begins, a goal must be clearly set out and communicated to—and agreed on by—the team.

Conclusion

Project planning is a vital process of any endeavour, especially when creating or implementing software (and ultimately, every digital scholarly edition is, at its heart, a software project).  It should never be ignored, lest the project fall to chaos and disarray. That said, it is important to remember that it is about more than just marking down due dates next to features and holding the project team to a schedule.  Project planning is also about seeing the big picture and knowing how to respond to various situations that may arise that were unexpected.  Project planning is much like warfare—considering all the various angles and developing strategies for dealing with the enemy. However, in the case of project planning, the enemy is often ourselves and our own failures to look ahead.

References

[1] Rouse, Margaret. “What is project planning?“. Whatis.com. March 2007. Web. 19 April 2015.
[2] Jenkins, Nick. “A Project Management Primer: Basic Principles – Scope Triangle“. ProjectSmart.co.uk. n.d. Web. 19 April 2015.

Further Reading

Haughey, Duncan. “Project Planning: A Step-by-Step Guide”. ProjectSmart.co.uk. n.d. Web.
Kerzner, Harold R. Project Management: A Systems Approach to Planning, Scheduling, and Controlling, 11th Edition. Hoboken, NJ: Wiley & Sons. 2013. Print.
Project Management Institute. “The Project Management Office: Aligning Strategy and Implementation“. PMI.org. April 2014. Web.
– – -. “The Value of Project Management. PMI.org. 2010. Web.
Sylvie, George, Jan LeBlanc Wicks, C. Ann Hollifield, Stephen Lacy, and Ardyth Broadrick Sohn. Media Management: A Casebook Approach. New York, NY: Taylor & Francis. 2009. Print.