“Hull form modeling in Conceptual design by assembly …vikorasmussen.com/modship/Master_Thesis_Viko_2009.pdf · Øyvind Viko Rasmussen Master Thesis NTNU 2009 I “Hull form modeling

Øyvind Viko Rasmussen Master Thesis

NTNU 2009 I

“Hull form modeling in Conceptual design by assembly and modification of 3D Hull Modules” Master Thesis in Marine Systems Design - Stud. techn. Øyvind Viko Rasmussen

Spring 2009

1 Background

The development of hull forms in conceptual ship design can be a time-consuming and tedious task. Newer and more effective methods for early hull design can have numerous benefits. In my project thesis during written in fall 2008 I proposed a set of new methods that can be used to make this stage in hull design faster and easier. These methods included an approach where a hull is modeled from modules that can be changed individually after assembly. Other possible changes are the use of a hierarchical system for manual edit of the hull surface, and a stack-based system for organizing the actions on the modules. Optimally, the modules could be created parametrically, with parameters that can be changed even after assembly of the modules.

2 Overall aim and focus

The overall aim of the thesis is to further investigate the methods presented in the project thesis. This includes a discussion on whether it is feasible and practical to implement each of the methods. In addition each method must be investigated to see if it provides a real advantage vis a vis the old methods. A part of this work should be to develop and complete a simple use case that can demonstrate advantages and disadvantages for the selected methods. The thesis should then include a demonstration of how the use case would be solved with the help of the new methods versus the old method. If possible, the thesis could also include specific feedback from external professionals on feasibility and usability.


NTNU 2009 II

3 Scope and main activities

1. Describe the current commercial state-of-the-art and research development in hull design tools.

2. Describe the results found in the project thesis, and the possible new methods.

3. Develop a simple use case, and show how it can be solved with the old methods.

4. Present and visualize the optimal solution of the case using new methods.

5. Present differences between the two methods when used on the case

6. Develop a prototype application that utilizes at least two of the presented methods.

7. If the prototype is successful, get feedback from industry professionals on usability and feasibility of implementing any of the methods

8. Discuss and conclude on the possibilities and practicality of using the new methods to enhance the existing hull design process.

4 Modus operandi

At NTNU, Professor Stein Ove Erikstad will be the responsible advisor.


NTNU 2009 III

5 Preface

This master thesis was written during the spring semester of 2009. The inspiration for the thesis came from the work I did on a project thesis the preceding semester.

The project thesis was in turn inspired by a summer job I had completed earlier. In this job I was given the task of finding a way to model a moderately accurate ship hull from a set of General Arrangement drawings, and then calculate efficiencies and interaction effects for thrusters connected to this hull.

The job gave a new interest in ship hull modeling, but at the same time the end product left me feeling that there had to be an easier way of modeling ship hulls than the ones I had been using. As the scope of my project thesis I decided to find and describe one or more of these methods.

During this work I learned a lot about hull modeling in general, and also found a number of problems that had to be solved if any of the new methods were to be used. The end result of the project was a set of ideas and a faint idea about how they could be implemented in a prototype application.

In order to really evaluate the methods presented in the project, I would have to develop and test this prototype application. This was a suitable task to work on as my master thesis. Initially, my plan was to develop the prototype, and have a number of industry professionals give their feedback on things they liked and problems I had overlooked.

After a while, I became clear that I would not be able to finish the prototype in time for such a review, and no such section is included in the thesis. I still maintain that professional feedback is essential in order to find all the advantages and disadvantages of the prototype and the proposed methods.

The work on the new methods and development of the prototype has been rewarding, and I feel like I have improved on the methods proposed in the project in addition to tackling a number of problems regarding the implementation of these methods. The development of the prototype has also given me valuable experience in software development and the mathematics related to 3D geometry.

I would like to thank my advisor Professor Stein Ove Erikstad for helping me find an interesting thesis topic, and the other members of the industry that has given me valuable feedback throughout the process of writing this thesis.

Trondheim, 7th June 2009

___________________________

Øyvind Viko Rasmussen


NTNU 2009 IV

6 Summary

One of the earliest and most constraining tasks in the ship hull design process is the selection and modeling of a suitable hull form for the ship. A ship hull directly governs the ships stability and resistance in addition to the required propulsion power, maneuvering, sea keeping and cost.

Currently available hull modeling applications are flexible and easy to use, but lacking in productivity when compared to similar applications used in other industries. It is clear that the introduction of more productive methods for hull modeling would be beneficial in many ways. Faster creation and modification of the hull model could allow more time for optimization, resulting in reduced costs over the lifetime of the ship almost without increase in design costs. In this thesis, a number of methods are proposed that aim to improve upon the existing methods and increase productivity in the modeling process.

The most significant change is the introduction of hull modules that can be created parametrically or selected from a library and combined into a full hull surface. The module based approach allows for easy reuse of older hulls, large scale modification by replacement of whole modules, and local modification of one module without affecting the rest of the hull.

Additional improvements to the module based method can be achieved through the introduction of a modifier stack in the modeling application. The modifier stack allows for non-destructive editing of the hull surface, and a way to make manual modifications and transformations independent and systematic.

Performance estimation and feedback is an area with great potential for improvement. The introduction of cheap multi-core computer processors and algorithms running on GPUs1

A set of cases was solved using three different applications, including a prototype developed as part of this thesis. The result show that both a module based system and the modifier stack can bring significant improvements to the design process. However, feedback from design professionals is needed in order to get a better idea of whether the methods are practical in a real-world setting.

can allow for significantly faster evaluation of performance. This performance data must be presented to the designer in a way that is both clear and non-obtrusive, as a way to help both novice and professional designers make better decisions and optimizations.

As a conclusion, I would say that a module based approach should be considered for inclusion in some current hull-design applications. The modifier stack can bring many benefits, and would be very interesting to see in practice, but implementation of a modifier system has its challenges.

Any group investigating the addition of any of the methods should also carefully consider the cost of researching and implementing the method, versus the benefit that can be achieved. If the cost is high, the money might very well be better spent improving a later stage of the design process.

1 Graphics Processing Units


NTNU 2009 V

Contents

1 Background ................................................................................................................................. I

2 Overall aim and focus .................................................................................................................. I

3 Scope and main activities ............................................................................................................II

4 Modus operandi ..........................................................................................................................II

5 Preface.......................................................................................................................................III

6 Summary................................................................................................................................... IV

7 Figure list ................................................................................................................................. VII

8 Introduction ................................................................................................................................1

9 A short history of ship hull design ................................................................................................2

10 Commercial state of the art .....................................................................................................5

10.1 Manual creation ..................................................................................................................5

10.2 Modification of existing designs ...........................................................................................7

10.3 Parametric methods ............................................................................................................8

10.4 Performance based generation / Optimization .................................................................. 10

10.5 Combined methods ........................................................................................................... 11

10.6 Novel ideas and methods .................................................................................................. 12

10.7 Comparison / Summary ..................................................................................................... 13

11 New methods for the design process ..................................................................................... 15

11.1 Modular hulls .................................................................................................................... 15

11.2 Modifier stack ................................................................................................................... 17

11.3 Optimization and feedback in the modeling process .......................................................... 19

11.4 Common disadvantages ..................................................................................................... 21

12 NURBS math .......................................................................................................................... 22

13 Case studies .......................................................................................................................... 25

13.1 Case 1 – Initial creation of a ship hull ................................................................................. 26

13.2 Case 2 – Modification of existing ship hull.......................................................................... 26

13.3 Methods utilized when solving the cases. .......................................................................... 27

13.4 Case Solutions ................................................................................................................... 28

13.4.1 Case 1 – Rhino ........................................................................................................... 28

13.4.2 Case 2 – Rhino ........................................................................................................... 32

13.4.3 Case 1 – Virtual optimal application ........................................................................... 34

13.4.4 Case 2 – Virtual optimal application ........................................................................... 37


NTNU 2009 VI

13.4.5 Case 1 – Prototype application ................................................................................... 39

13.4.6 Case 2 – Prototype application ................................................................................... 43

13.5 Case solution comparisons ................................................................................................ 46

14 Prototype application ............................................................................................................ 48

14.1 Intro .................................................................................................................................. 48

14.2 Prototype scope ................................................................................................................ 48

14.3 Technologies and systems used ......................................................................................... 49

14.4 Main challenges................................................................................................................. 51

14.5 Problems, features and decisions ...................................................................................... 54

14.5.1 ArcBall implementation ............................................................................................. 55

14.5.2 Merging of the modules ............................................................................................. 56

14.6 What would I want to implement, given more time .......................................................... 58

14.6.1 Large changes, additional features ............................................................................. 58

14.6.2 Smaller additions ....................................................................................................... 59

14.6.3 What could be implemented in a better way? ............................................................ 60

14.7 How to use the application? .............................................................................................. 61

14.8 Prototype summary ........................................................................................................... 62

15 Conclusion............................................................................................................................. 63

16 Bibliography .......................................................................................................................... 65


NTNU 2009 VII

7 Figure list

Figure 1 - Splines and Ducks ................................................................................................................2Figure 2 - Half-hull model ....................................................................................................................2Figure 3 - NURBS surface with control point grid .................................................................................3Figure 4 - Parametric hull generation in Maxsurf .................................................................................9Figure 5 - Hull generation in PolyCAD ................................................................................................ 12Figure 6 - Parameter sources for a module generator ....................................................................... 15Figure 7 - Module creation methods ................................................................................................. 16Figure 8 - Modifier stack in 3ds max .................................................................................................. 17Figure 9 - Example modifier stack for a hull module .......................................................................... 18Figure 10 - Optimization implementations ........................................................................................ 19Figure 11 - Possible feedback methods ............................................................................................. 21Figure 12 - Nurbs surface .................................................................................................................. 22Figure 13 - Rhino user interface ........................................................................................................ 28Figure 14 - Final hull developed in Rhino ........................................................................................... 33Figure 16 - Example module choice dialog ......................................................................................... 34Figure 15 - Global hull parameters .................................................................................................... 34Figure 17 - Final hull from optimal application .................................................................................. 36Figure 18 - Example interface for the optimal hull modeler ............................................................... 38Figure 19 - Initial prototype user interface ........................................................................................ 39Figure 21 - prototype hull before and after module merging ............................................................. 41Figure 20 - Module parameter grid ................................................................................................... 41Figure 22 - Final prototype hull shape ............................................................................................... 42Figure 23 - Final prototype hull in application ................................................................................... 45Figure 24 - Final prototype hull exported and opened in Rhino ......................................................... 45Figure 25 - Prototype layout overview .............................................................................................. 51Figure 26 - XML Module structure ..................................................................................................... 52Figure 27 - Module surface in prototype application and exported to 3dm format ............................ 53Figure 28 - Arcball ............................................................................................................................. 55Figure 29 - Blending and merging of two surfaces ............................................................................. 56Figure 30 - Merge parameter ............................................................................................................ 56Figure 31 - Surface turning back on itself ........................................................................................... 57


NTNU 2009 1

8 Introduction

One of the earliest and most constraining tasks in the ship hull design process is the selection and modeling of a suitable hull form for the ship. A ship hull directly governs the ships stability and resistance in addition to the required propulsion power, maneuvering, sea keeping and cost.

Several of the aforementioned characteristics can be estimated from empirical formulas and regression analysis, but a detailed hull model is absolutely necessary in order to get accurate values. This is increasingly true for ships with specialized and unconventional hulls, where the estimates from empirical formulas are less accurate.

In many cases, the final hull form is decided upon late in the preliminary design phase, in order to avoid the frequent changes in form as other ship design parameters are decided upon or changed. Part of the reason for this is the time-intensive work currently required to change a hull shape after its creation. The most popular hull design applications in use today are generally very flexible when it comes to early modeling and design of a hull. However, this flexibility increases the workload and time required, both for initial creation and modification of the hull model.

In an increasingly marginal market, there is a need for designers to create better designs in a shorter amount of time. It is clear that the introduction of more productive methods for hull modeling would be beneficial in many ways. A more effective design method for initial hull design can allow the designer to make new hull shapes faster than before. A more productive method for modifying an existing hull could allow the designer to spend more time trying out new concepts and optimizing the hull surface. Good methods for feedback and help from computer aided optimization can help improve the hull even further. Such optimizations to the hull could give significant savings and positive value over the whole lifetime of the ship, without increase in the design costs.

My task in this thesis is to review some new methods that can be implemented in order to make the design process more productive. I will discuss the methods used today and how they were invented, before presenting a set of improved methods. These methods will be evaluated qualitatively by comparing them to each other and the existing methods.

In addition, a prototype application will be developed and used to solve two design cases. The same cases will be solved using two other applications, to allow for further comparison of the advantages and disadvantages of each method.


NTNU 2009 2

9 A short history of ship hull design

In earlier times, the design of a ship hull was a tedious and time consuming process. Design was performed by experienced draftsmen using long lasting traditions, and the development of new hull shapes were mostly a result of trial and error. The designers or loftsmen used long, thin and flexible wood planks to sketch up the ship lines. These planks were known as splines, and their shape was modified and locked in position by the manual placement of weights, known as ducks.

With the increase in intercontinental trade came the need for larger and faster ships. The merchant with the freshest cargo could demand higher prices, and larger ships allowed for fewer trips. This development pushed the need for a more organized approach to ship hull design optimization.

The first significant effort for decreasing hull resistance came with the completion of early tank experiments on ship models. These experiments allowed designers to verify the knowledge they had through their

experience, and create new larger and faster ships.

As more effective shapes were developed, there was a need for a new method of sharing the shape throughout the shipyard. This need resulted in the development of half-hull models. A half-hull model was a scale model of a ship hull, divided into horizontal sections. A designer with access to this model can measure each section, and scale it up to get dimensions for the full scale hull. This method for representing a hull was used all the way through the 1840’s and 50’s, but the accuracy was too low for the design of the new iron steam ships that arrived around the 1870’s. (1)

Development of hull shapes through experimentation really got underway when the more modern iron hulls took to sea. Numerous tank experiments led to the development of mathematical techniques for generating good hull shapes. These techniques in turn lead to the numerical hull design utilized at the beginning of the 20th century. The first real systematic study on the influence of

hull shape on resistance was completed by D.W. Taylor around that time. (2). Taylor measured resistance and stability for a number of models with systematic parametric variations, and the series of results formed a good basis for investigating a new mathematical relationship between shape and

performance.

The evolution of mathematical representations and relations for hull shape went on up to the 1960’s, when the introduction of computing technology prompted the creation of software for hull creation and analysis. The first breakthrough of this evolution was the introduction of conformal mapping of hull surfaces, which significantly

Figure 1 - Splines and Ducks

Figure 2 - Half-hull model


NTNU 2009 3

increased the efficiency of hydrodynamic calculations for a hull form. Unfortunately, the method had accuracy that was insufficient for use as a good hull description, and further development had to be completed. These developments lead to the first systems where a hull shape was created and represented by polynomials and parameters; thus the first parametric hull design tools had been created.

Even the use of polynomials for hull shape representation proved insufficient as demands for accuracy got higher. Fortunately, in the early 1970’s, the development within the CAD community had lead to the creation of Bezier curves, a free form curve generation technique. Bezier curves were originally used in computer aided car design at Renault, but they had several features that made them well suited also for hull design.

A Bezier curve was immediately recognizable for ship designers, since the shape of Bezier curves are decided by the placement of a number of control points, much the same way as the wooden splines used earlier were shaped by the placement of heavy weights. However, a problem that showed up when using Bezier curves was the fact that the resulting mathematical order of a Bezier curve was directly dependent on the number of control points used to define the curve. A higher order makes a smoother curve between control points, but each point has less effect on the curves overall shape.

In addition to the problem with dependency between control points and order, came the fact that circles and conics are very hard, or in some cases impossible to accurately represent using only Bezier curves. These drawbacks pushed the development of a more advanced curve representation.

The breakthrough came with the work done by a combination of people through the 70’s. Most prominently Riesenfelds work on B-spline Curves, which in turn was based on the work by de Boor and Cox on the evaluation of splines, combined with Beziers method for curve representation. This B-spline representation was then extended into

Non-Uniform Rational B-Splines, normally referred to as NURBS. (1)

NURBS contain Bezier curves as a special case, but also incorporates improvements that allow the curve order to be independently of the number of control points. In addition, NURBS allow simple representation of conics and circles. This allows sets of NURBS curves to represent almost any surface with sufficient accuracy. NURBS surfaces are a good choice for ship hull design because of the intuitive results the user gets with the movement of the control points for the surface, and the relative ease of fairing hulls. This is especially true as computers get more powerful, and the design process gets more interactive.

As a result of their suitability in ship hull modeling, NURBS curves and surfaces are now the predominant way to model ship hulls in CAD systems, and several standards for exchange of surface

Figure 3 - NURBS surface with control point grid


NTNU 2009 4

data, such as STEP, IGES and PHIGS natively support NURBS surfaces. A later chapter will discuss both NURBS and data exchange in greater detail.

One downside to the discovery and standardization of NURBS was that research into other methods for hull representation was significantly reduced. This has resulted in the situation we see today, where many hull design tools seem to have stagnated in their development. Comparison to design tools used in other industries such as Aviation and Automotive design shows great potential for improvement. When we compare the usability and graphical capabilities of current dedicated hull design programs to the found in modern 3D applications for animation, visualization and even computer games, the difference is surprising. Luckily, this only shows us the potential for improvement in hull design, and what we should expect and demand from the future of hull design applications.


NTNU 2009 5

10 Commercial state of the art When NURBS surfaces had been developed, selecting them as a representation for hull form was a down to a simple comparison of advantages and disadvantages. Another issue that had to be dealt with was how to create the hull shape in the first place. A number of different design methods have been proposed and researched and each have their advantages and disadvantages when it comes to usability, versatility and quality of the resulting hull shape. With the flexibility of NURBS came more complexity in both implementation and use of each method. What follows is a short description of the different approaches used for obtaining a ship hull form, with focus on strengths and weaknesses for each method.

10.1 Manual creation

A NURBS surface is directly defined by its control points, and the most basic way of shaping this surface is to manually add, move and remove these points until the desired hull shape is obtained. Earlier, this required the designer to input the coordinates of each point as numbers in a file, and thus modify the ship shape through a text-editor. This was a tedious and error-prone process, with little or no direct feedback to the designer about how the hull would react to a change in coordinates for a single point. It also required intimate knowledge about NURBS by the designer.

At a later time appeared graphical user interfaces that allowed the user to interactively modify the surface control points using a mouse. This has made it a lot easier to learn and use the modeling applications, but at the same time requires increased computing resources.

A NURBS modeling application is not required to make any assumptions about the shape of the surface being created, or the method used to obtain this shape. This makes manual creation of surfaces extremely flexible, and allows surfaces of very good quality and complexity. However, the process of doing everything manually is also time consuming, and good results require an experienced designer. This is true even for relatively simple hull shapes. After the hull is created, there are also problems when the user wants to make systematic changes to the surface in order to optimize the shape. A method where the computer has more knowledge about the specific role of each part of the surface can allow for a larger degree of automated optimization.

An advantage when it comes to manual hull modeling is the freedom the designer has when selecting a modeling application. The designer is free to select any of a number of general 3D modeling applications, since the application is not required to know anything about a ship hull. These 3D applications might implement more efficient user interfaces and newer technology than the specialized hull design applications. The downside to selecting a general 3D application is the lack of ship specific parameters when the hull surface is exported, and a lack of a number of small “helper” features for hull design that is normally found in the specialized applications.

Create surfaceDrag points to

achieve good hull shape

FairingSurface ready for

performance estimation


NTNU 2009 6

In later years, there has been a development where established, more general purpose 3D applications have created expansions or plug-ins that allow easier creation of ship hulls. In addition, the plug-ins can give information about the performance of a hull, and help maintain information about the hull when it is exported to other applications. Good examples of such plug-ins are Orca3D and RhinoMarine, created for Rhino3D. (3) (4) (5)

Another way to implement manual creation of ship surfaces is by using curves to represent the ship lines in three dimensions. Some hull design packages even allow the creation of a hull from a network of curves on arbitrary axis. The curves method is more analogous to the splines and lines plan used earlier, and may therefore be easier to use and visualize for some designers. In addition, a curve-based method makes it easier to specify knuckle lines or surface edges.

An irregular curve network also allows for easier addition of local appendages, where the designer can simply add more curves around an area where higher detail is needed. This curve network method is both highly flexible and very productive, but the downside is that experience is needed in order to create a good curve network. In addition a modification of one curve might propagate into required changes in several other curves, and the total work required for the modification goes up significantly. More capable applications could reduce this problem, but current curve-network implementations are not yet good enough. (6)


NTNU 2009 7

10.2 Modification of existing designs

Manual hull shape design also includes the commonly used method where the designer uses a previously modeled hull and changes it slightly to suit new requirements. This obviously reduces the time required for a new hull significantly, but the method is not always possible to use, and comes with a few potential problems.

Small changes to the hull shape are quick, easy and work well, but when larger changes are required, such as with the addition of podded propulsion, the designer may run into problems where the placement of the curves of the old hull model are not optimal for modification of the new hull. In some cases, it might even be easier and faster to build the new hull from scratch if larger modifications are expected.

A common way to modify old hull shapes is though the use of specialized transformations of the surface. If you want the same general shape as the old ship, but slightly longer and wider, this is a good solution. However, simply stretching the shape linearly in the required direction is not encouraged. More advanced transformation functions have been developed that allow the designer to change the basic dimensions and volume distribution of a hull without significantly distorting appendages and other important features. These functions can be considered core tools for any designer that wants to modify an existing hull shape, but they are limited with regard to flexibility and possible changes to the hull shape.

A common problem with all hull shapes based on earlier designs is that the new hull can contain some features that were optimized for the old hull shape, and are no longer optimal for the newer hull shape and ship role. A hull generated from scratch could in many ways be optimized for its new use by being more specialized and incorporating new knowledge, but with a trade-off in the time required for design. This leads us to the same optimization challenge as for manually created hulls; Since each change to the hull shape will be relatively time intensive, the user will have time for a smaller amount of optimization iterations, possibly resulting in a less than optimal hull shape. Automatic optimization of manually created hull shapes is also very hard to achieve.

Find hull model of similiar ship

Drag points to achieve new hull

shapeFairing

Surface ready for performance

estimation


NTNU 2009 8

10.3 Parametric methods

An alternative to manual hull modeling is the use of a parametric method. Parametric hull generation takes input from the used in the form of numeric form parameters and control functions, and then creates a hull shape that correspond to the given parameters.

As mentioned earlier, much research was devoted to development of parametric methods. After the introduction of freeform surfaces, the intensity of this research went down for some years, since many believed that a good modeling solution had now been found. Recently, the interest in parametric methods has grown again, with the desire for quicker design proposals and their potential use with automatic optimization.

Most modern parametric tools have embraced NURBS as the freeform surface of choice, and several new programs incorporate ways to start out with a list of parameters of a set of form curves, and get a crude NURBS hull surface which can then be further modified. (6) (7). An interesting example of parametric hull generation is described by J.H. Jorde in Mathematics of a body plan (8). Here he shows a functional parametric hull generation technique implemented in Microsoft Excel.

In the ideal case, a parametric method has great advantages through its ease of use. In the best case scenario the designer can simply enter a few parameters and get a well suited, finished hull surface generated by the application. Optimization of the hull should be quick and easy, as the user can set a parameter to a range of values, and see how the performance of the hull changes. This optimization process could even be performed automatically by the computer. As with many other ideal cases, this is rarely the way it works out in practice.

The designer usually needs to input a high number of parameters in order to get good control over all parts of the surface. Some of these parameters have an effect of very specific parts of the surface, and some have more wide effects on the whole hull. It can be hard to predict the effect of parameters that control curvature and fullness of the hull, and there are few ways to know how modification of a parameter will affect the final hull.

Parametric methods are also generally inflexible. There are a large number of characteristics that vary from one ship type to the next, and it can be very hard to find a mathematical formulation which can create good surfaces for even moderately different ships. This means that a parametric tool must be created either as a general purpose tool that can create many hull variations but require manual modification afterwards, or a specialized tool for one kind of hull, with reduced flexibility.

Another problem appears when a parametric tool is created, and the creator must select which parameters to use in the tool. Main dimensions and volumetric coefficients are obvious choices, but there is usually need for additional parameters in order to vary the hull shape and fully define the hull shape. Bulbs and skegs usually require many different parameters, and some features of the hull like the curvature of the bow and aft would be a lot more intuitive to modify directly and

Input requested parameters to application

Application creates hull according to parameters

Change parameters if hull

is not accepted

Surface ready for performance

estimation


NTNU 2009 9

interactively. However, manual modification of the generated surface usually means that the design can no longer be changed through the parameters, and then many of the advantages of parametric design will disappear.

Figure 4 - Parametric hull generation in Maxsurf


NTNU 2009 10

10.4 Performance based generation / Optimization

Performance based hull design is a method where a computer tries to iteratively generate a good hull shape based on the performance of the hull. This is a relatively new method, and it can be seen as an extension of parametric hull design. The method is usually divided into three different steps that can be repeated any number of times. The first step is the creation of a hull surface based on a number of parameters. This hull shape is then analyzed to find its current performance. The third step is investigating whether the hull shape fulfills the required performance criteria, and whether this iteration of the hull shape is better than the last one. If a hull does not fulfill the criteria, the method returns to step one with slightly changed parameters that could improve the performance of the next iteration.

Modern version of this method generally utilize modern search algorithms like Genetic Algorithms, since the relationship between hull parameters and performance might be too complex to get good and reasonably quick results with simpler search methods. (9) (10)

One problem with performance based hull design is to find out which parameter to change from one iteration to the next. For a NURBS hull surface of reasonable complexity, there will be too many control points to effectively try to modify each one of them. This means that constraints must be added to the model in order to reduce the number of possible changes. The addition of such constraints has two major problems. First, it might be very challenging to make good constraints for special features of the hull, such as the bulb and propeller shaft appendages. Second, the constraints themselves will reduce the flexibility of the method, and the true optimal hull shape might not be found.

Another problem is that the designer has no direct control of the surface, other than through constraints and/or manual modification after the hull is created. As with the parametric hull method, the resulting shape might also be badly suited for manual changes at a later stage.

Create hull from parameters, or

load existing hull

Measure performance

Modify one or more parameters

to improve performance


NTNU 2009 11

There have been examples of systems created that successfully implement performance based design. (11) However, a better solution seems to be a system where the performance data is directly presented to the designer. The designer can then use his experience and skill to find the best way to increase the performance of the hull for the next iteration.

As available processing power increases, it may even be a good solution to let the computer calculate a few different changes to the surface with resulting performance. The application can then give “hints” to the designer on how to best optimize the surface, while still leaving it to the designer to make decisions and compromise between solutions.

10.5 Combined methods Two or more of the aforementioned methods can be combined in a single hull design application in order to combine the advantages of each method. An obvious choice is to start a design with a hull from an earlier ship or a parametric tool. This hull design can then be manually modified to meet new requirements, or entered into a performance-focused optimization tool as discussed earlier. Both of those methods can benefit from a high quality initial hull.

One problem with this approach was discussed earlier; one example is when the user has created a good initial hull shape with a parametric tool, and then wants to manually modify some small part of the bulb. Although the parametric surface as a whole is of good quality, the layout of the control points generated from parameters is probably not. This means the designer may have to modify many different points in order to get the wanted change, possibly ruining other parts of the hull in the process. This is a general problem for manually editing any hull not originally created directly by, or under close supervision of a human designer.

In some cases even manually created hull shapes may be unsuitable for modification into other hull shapes if the desired modifications are large. Examples of such changes are the addition of a bulb or change of propulsion system. This problem is mainly caused by the fact that areas of the hull surface that needs to be modeled in high detail must contain more control points per surface area. If these points are not carefully organized the result will often be messy, and modifications of such a surface could be hard or impossible within a reasonable timeframe. If the designer wants to add a new detailed feature to an existing hull he will also be forced to increase the control point density around the affected area. After a few changes to the surface, an overwhelming amount of control points might have been created. If the designer had created the hull from scratch, he could have planned the layout of control points from an early phase, and end up with a surface governed by significantly fewer control points, and probably a fairer hull.

A good method for reducing the overall number of control points while still maintaining good control over detailed features is to divide the hull into multiple surfaces. However, this approach removes some problems while a number of others are added. The main problem with this approach lies in the increased difficulty of implementing multiple surfaces during the development of a design tool.

The second large issue with a combined method is the exchange of the hull data itself between the different applications or tools. Simply transferring the hull NURBS surface is rather easily solved, as we will see in the later chapter on data exchange. However, the designer often wants to be able to


NTNU 2009 12

move the hull between the different methods several times, and have changes done in one of them retained when it returns to the other. This is a problem without an obvious solution, and a thorough assessment of advantages and disadvantages must be made before such a feature is implemented.

10.6 Novel ideas and methods A number of interesting ideas that improve upon the existing methods have been presented. One example is the work by Marcus Bole on creating an easy to use and flexible method for constrained parametric hull design (1). Bole proposed a method where the designer models a set of curves that define main particulars of the hull, with a method for easy definition and modification of the hull curvature between these curves. He also includes a numerical technique for merging the shape of other surfaces onto an existing hull surface, which allow for the addition of a bulb or other appendages.

Another paper by Bole and B. S. Lee describes a hierarchal method where every part of the hull geometry can be positioned in relation to another part. This may allow a designer to create a hull from a set of parameters and add some manual features or appendages. Later the designer can change the original parameters, and have the hull surface update accordingly, without destroying the added features of the hull (12).

Many of the ideas presented by Bole have been implemented in PolyCAD, a free ship design application developed by Bole (13).

Figure 5 - Hull generation in PolyCAD

There are also some examples of work where the early hull design is based on a partially modularized method where the hull surface is assembled from surface parts. One example from an article in the


NTNU 2009 13

Journal of Ship Production describes a technique where the hull is divided into five areas, the stem, run, parallel midbody, entrance and bow (14). The designer can then pick a bow and stern from a library, specify a parallel midbody, and control the rest of the hull shape through the modification of a desired SAC curve.

Other interesting research is done on the evaluation of NURBS and newer methods of interacting with a NURBS surface, one example that could have a future is D-NURBS, which describes a way to interact with NURBS in a more physically intuitive way (15).

The field of surface representations is also evolving. One of the most interesting results is the development of T-splines, a merge of subdivision surfaces and NURBS that have a number of advantages over both, while still remaining forward and backwards compatible with NURBS (16).

10.7 Comparison / Summary We have now seen a short introduction of some different methods used to create and modify ship hull surfaces. There are naturally a number of other methods and combinations used in hull modeling applications, but the basis of most of them can be put into one of the four categories which were presented. A thorough review of some of these applications can be found in (1).

The general conclusion that can be made is that every method has some features that are worth bringing on in a new method, and some serious problems that restrict their usability. Another conclusion I have made is the fact that many of the implementations of these methods fail to make use of the improvements that have been made in the computing industry in recent years. For several of the applications it might be necessary to completely overhaul the way the designer interacts with the surface in order to increase productivity. This is especially true for the cases where the user interacts with the surface through textual commands, rather than direct interaction. The developers of those applications should take a look at some newer general purpose CAD and 3D applications for hints on how to improve the work-flow in their applications.

One of the main features I would like to retain in the new method is the advantage of reducing the need to redo work by reusing features of earlier hull designs. I also want to incorporate parametric design methods because of the possibility for quick generation and modifications to the hull surface. A performance based method can give valuable information to the designer during the optimization of the hull, but I think it is very important to include the designer in the decision process in order to include human experience and common sense in the design.

Some way to incorporate appendages and local features to an existing surface would be nice to include. Last I would like to combine some of the methods that are related to hierarchical geometry with direct manual manipulation of the hull surface. I my opinion manual modifications are absolutely necessary as a way to increase the flexibility of the method. These considerations must be kept in mind when the new method is developed.

The next table displays the largest advantages and disadvantages for the presented methods.


NTNU 2009 14

Manual Creation

Modification of an existing surface

Parametric Generation

Performance based design

Advantages

•Flexible - any hull surface is possible

•General purpose 3D applications can be used

•Local appendages are relatively easy to add

•Can use a curve based method for easier local detailing

Disadvantages

•Time-consuming

•Needs experienced designers

•Little to no feedback on performance

Advantages

•Very quick initial hull modeling

•Hull transformation tools make some modifications very easy

Disadvantages

•Not all modifications are possible

•Similiar hulls are not always available

•Little to no feedback on performance

•Less flexible than other methods

•Can retain some less optimal features of the original hulls

Advantages

•Quick initial creation

•Good possibilities for manual and automatic optimization

•Easy to learn and use

Disadvantages

•Some parameters may be unintuitive

•Too many parameters can be confusing

•Less flexibility

•No manual modification of the surface

•Separate parametric generators are needed for each ship type

Advantages

•Can provide well optimized hulls

•Can be interactive, and work in combination with other methods

Disadvantages

•Needs large amounts of time and/or computing power

•No direct control over the hull surface

•Some hulls might be optimized, but unsuited for construction or break real-world limitations

•Less flexible than other methods

•Needs flexible performance evaluation methods


NTNU 2009 15

11 New methods for the design process It has become clear that all of the presented methods have disadvantages that could be reduced or eliminated. In my project thesis I presented a number of new methods that could help with these disadvantages. The methods can be implemented by themselves, but the best results must be expected from implementing several in combination. I hope to show how these methods can use the increase in available computer processing power to help the designer be more effective and create better ship hulls.

11.1 Modular hulls The first area of improvement lies with the implementation of a modular hull surface. The idea behind this method is that the designer can select a number of hull modules from a module library and combine these modules to a final hull. This approach should allow for a very short time from clean slate to the first complete hull surface.

In the best case scenario, the designer would only have to select a module for a bow, midship and aft, input length, width and draft for the whole ship, and have a finished hull. If one of the requested modules is not available in the library, the designer will have to create it from scratch, or modify an existing module. The new module can now be saved to the library and used in later designs.

Modular ship hulls also have advantages when it comes to modification of the hull shape. Large scale changes can be implemented by exchanging a whole module for a better one. This can be done without affecting the parts of the hull surface belonging to the other modules.

Local modification is also easier, since the designer is sure that a change in one module does not affect the surface in the other modules. In most cases, local changes will be done as modifications directly on the affected module, and larger changes will warrant a module change.

One problem with the module based approach is the creation of modules that cannot be found in the module library and have to be created from scratch or by modifying an existing module. The creation of modules is an added level of complexity in the hull modeling process. In addition, having to create all the modules of the hull before they can be combined into a hull is generally more time-consuming that simply creating the hull without the use of modules.

This extra work will be worth the effort because of the possibility for reuse of modules through the library. Each bow type, midship type and aft type needs to be modeled only once, and can then be used directly, or modified into new modules as many times as wanted.

An even better way to create modules comes with the implementation of a parametric module

Parametric module

generator

User specified parameters•Bilge Radius•Bulb size

Global ship parameters•Length•Breadth•Depth Parameters from

optimization process•Hull fullness•Angles

Figure 6 - Parameter sources for a module generator


NTNU 2009 16

generation tool. Such a tool could create accurate, high-quality modules very quickly and even allow the designer to change the parameters after the module has been added to the model. An even more advanced implementation of parametric modules would be a system where the designer defines some parameters that are general to the ship model, e.g. Length, breadth and depth. These parameters can then be used by the module library to create modules that will automatically fit the ship hull without further modification, and allow the same modules to be imported into a wide range of ship sizes almost without manual intervention.

Other advantages of parametric modules include the possibility of automatic optimization and potentially smaller storage space requirements for the modules since only the parameter values need to be saved.

There are of course also disadvantages with parametric modules; the largest problem is the implementation of the parametric module generation tool in the first place. The application programmers must make a specific module generation tool for each type of parametric module and find a delicate balance between tool that create is good at creating a specific module with good quality, or one that creates a wide range of modules with higher flexibility, but lower quality. A new parametric generator can probably not be made by the designer himself, but requires extra work by the application programmers.

Other problems are the ones shared with parametric methods for full surfaces, with too many required parameters, of which many may be unknown to the designer at the time of module creation. The possibility of doing manual modifications to the surface while still having the possibility to go back and change parameters later would be a great advantage, but this would require the implementation of a hierarchical or modifier based method in addition to the hull module system.

Figure 7 - Module creation methods

Module library

Manually created modules

Parametrically created modules

Modules created by

modifying an existing module

Modules imported from

hull models


NTNU 2009 17

11.2 Modifier stack The request for a way to combine manual modification with parametric modules brings us to a new design method, the modifier-stack. The idea of a modifier stack comes from its implementation in general purpose 3D applications, most notably in Autodesk 3ds Max (17) (18) and the open source application Blender3D (19) (20).

The modifier stack allows for non-destructive modification of a 3d object through the use of a stack of modifier functions applied to the object. Each modifier works on the result from the last function, and the designer can thus perform powerful modifications to the object in sequence. Since the modifications are non-destructive, the designer can go back at any time and change the settings for one of the modifiers, and thus change the end result without redoing all of the other modifications.

3ds max’s implementation of the modifier stack can be used as a good example. In the figures shown, it allows for the parametric generation of a box, with parameters for size and segmentation. The modifications start at the bottom of the stack, and each modification works on the object returned by the modifier below it in the stack.

Figure 8 - Modifier stack in 3ds max

After the creation of the box, we can add a few modifiers, the first being a stretch modifier. This modifier performs a scale transform along one axis. We can then add a new modifier above the stretch modifier which converts the stretched – parametric box into a surface patch, which can then be manually modified using 3ds max’s surface tools. Note that we can go back to at any time and


NTNU 2009 18

change the parameters used to create or stretch the box, and the changes will propagate up to the surface patch representation. We can also delete the stretch modifier, or add a new one at any time, and the patch surface would update accordingly.

To show how this can be useful in a ship design process, I present the following module – modifier stack. The designer starts off with a parametrically generated ship midsection of normalized size. He then adds a modifier to scale it to the required size, and a modifier that allows him to manually

modify the surface. After doing some minor manual modifications in order to get the surface just right, a fairing modifier is added, and finally a modifier to connect the module with some other modules. The last modifier would be common for all the modules that should be connected together, and thus both selects which modules should be merged, and allow the designer to specify parameters regarding the merge process. This modifier is marked as blue to signify that it works on several modules at the same time.

Manual edits to the surface could also be divided into separate Manual edit modifiers. The designer can now first create a parametric surface, then create a Manual edit modifier and slightly change the fullness of the surface. A new Manual edit modifier can then be added on top of the old modifier stack and some other change can be made. Let’s say the designer decided to manually change the angle of the bow. The two manual changes are now independent, and the designer has the possibility of going back and deleting the fullness-change modifier, while still preserving the change in bow angle. In other hull design tools, the designer would either have to undo both changes and then redo the angle change, or reduce the fullness by manually modifying the surface back. This would effectively be doing the same work again, only backwards, versus a simple delete operation on the modifier stack.

An even more advanced example could allow the addition of a parametric or manually created bulb through the modifier stack. The user could then add a bulb to the surface, add a Manual edit modifier and change some other features of the ship bow surface, and then remove the bulb or change its parameters without undoing the bow changes. The addition of an undo or at least save function in any application allows the user to experiment safely and confidently. In the same way this method will give the designer the confidence and ability to try out many different small changes and combinations of changes in a shorter amount of time.

It is still easy for the designer to go back and change the parameters used to create the module, the manual modifications, or the parameters that size the module to the rest of the model. Thus, this solution can provide significant improvement to the modeling process if it is implemented well. The largest problem with modifier stacks is the increased complexity in the modeling process. Implementing modifier stacks is also not trivial, but the successful implementation in 3ds max and Blender (20) shows that it is definitely not impossible.

Merge modules

Increase fairness

Manually modify

Scale

Parametric midshipFigure 9 - Example modifier stack for a hull module


NTNU 2009 19

11.3 Optimization and feedback in the modeling process

The mentioned methods can provide the designer with tools to facilitate quick generation and modification of a ship hull, but they provide little help in showing whether a modification increases performance or not. Optimization of the hull is very much a process of trial and error, and small possible improvements to the surface might be overlooked by the designer. Ideally, the increase in available, affordable computing power should be able to support the designer in more ways than just receiving a design and drawing it to the screen.

Some dedicated applications calculate the performance of a given hull, and many hull design packages have stability and hydrostatics modules built-in. This has allowed the designer to see the effect of smaller changes to the hull surface, and create better designs. However, the feedback on hull performance often requires the user to export the hull to the dedicated application, or start the separate performance tool. This extra step can break the “flow” of the design process, and reduce productivity.

Figure 10 - Optimization implementations

A better solution would then be to provide the designer with a form of continuous feedback about hydrodynamics and resistance while he shapes the hull. Modern computers could be able to perform simplified calculations of this sort in a very short time, especially if only approximations are required.

Another method would be to give the designer feedback about what a change of a parameter would do to the performance of the vessel. One example is where the program monitors what parameter the user wants to change, and gives the feedback in the form of “if this parameter is increased, the GM will rise. If it is decreased, the GM will go down”. This feedback will require fewer calculations than real time feedback, but it could give very good help to the designer when optimizing the hull. However, it is very important that this information does not get in the way of the designer or make the application harder to use by introducing “clutter” into the user interface.

One example implementation that could work well is where the application provides sliders for manipulating parameters. The user selects some parameter he would like to optimize for, e.g. “Resistance at 15 knots”. With two calculations per parameter slider (one with the parameter decreased, and one with it increased), the application can then guide the user with a green and red direction on the slider. The parameter with the largest effect on resistance will have the brightest color, and parameters without effect will have no colors.

Manual optimization from

feedback and modification

Automatic optimization tool

Automatic optimization stack-

modifier


NTNU 2009 20

This system would allow the designer to easily see what changes will make the biggest differences towards reaching the goal he has set. In addition the application help less experiences designers make better decisions, without disturbing more experienced that already know what changes they want to make.

A feedback system could also possibly be included into a modifier stack system as a performance modifier, which calculated the performance of a ship at a given position in a modifier stack. This could allow a designer to easily see the performance before and after a modification.

If a more accurate method for performance feedback is found, it can be used for automatic optimization through the use of an optimization function in the application, or possibly a “optimize for …” modifier in the modifier stack. Automatic optimization can allow for solutions that the designer had not considered, or a quicker optimization phase.

The first problem with performance feedback comes with implementation. Creation of performance approximation programs is far from trivial, and a system that calculates sufficiently good results in near real-time could prove very difficult. This is a problem that is limited by the available computing resources, which in this case is assumed to be a modern workstation computer. The problem could be simplified somewhat by reducing the number of calculations needed, or the accuracy of these calculations. In the case of feedback sliders, the program only needs to calculate whether the performance will increase or decrease, so the demand for accuracy is very low, but the number of calculations are higher, since two are needed for each slider.

There is a trend in computing towards multiple processors or processor cores, which allow a number of calculations to run in parallel. Modern computers are already more than capable of processing simple input and calculate modifications of hull surfaces, so the increased processing power of the extra cores can be used to run performance calculations in the background, without interrupting the user’s workflow. The results of the performance calculations can also be shown as they are finished, rather than on demand by the user, this would minimize user disturbance.

This would be similar to the current situation for video processing applications, where the computer renders video effects in the background while the user is working, with rendered video ready when the user needs it. Compare this to the old method where the user first edited a movie, and then had to request a render of the clip, and wait for it to finish, before the end result could be seen.

Another development that supports the development of background performance calculations is the increase in use of Graphics Processing Units for general calculations, a field known as GPGPU programming. GPU’s are generally specialized in massively parallel floating point calculations, and a suitable algorithm running on a GPU could run orders of magnitude faster than when using the computers CPU (21).

This kind of “behind the scenes” processing and user support through performance feedback is something that can greatly improve the user experience and productivity of a designer.


NTNU 2009 21

Figure 11 - Possible feedback methods

11.4 Common disadvantages

The presented methods can all contribute positively to the design process if they are implemented in a way that balances complexity and flexibility. Each method comes with its own advantages and disadvantages, as described above. In addition we see a set of disadvantages that are common for all the proposed methods, and indeed for any new method included in the design process.

The first disadvantage arises where the hull design application should interact with other applications. Any new feature added will not have support in existing applications and file formats, and this means that any parametric model stops being parametric the moment it is exported as a surface. The same thing is true for the modules and modifier stack. The only viable way to transfer hull surfaces is as NURBS surfaces with little to no additional information attached.

The next disadvantage comes with the fact that all older hull designs will have to be converted to a format that is usable with the new methods. Not all hulls are possible to convert using the new methods, and if no old designs are converted, it would mean that we are basically starting to build a hull library from scratch again.

The third large disadvantage concerns the need for re-training of designers. The new methods must be thought and used for a while before the advantages become apparent. The designers might have significantly reduced productivity while they try to learn how to best use the new methods.

Real-time feedback during

modification

Feedback on parameter

sliders

Feedback calucation stack-

modifiers


NTNU 2009 22

12 NURBS math

In order to better understand later parts of the thesis, a little further information on NURBS can be useful. As mentioned, NURBS were developed between the 1950’s and 60’s, but the first commercial ship design application that utilized them were not released before 1985.

A NURBS curve is created as a parametric curve, defined by a set of control points. A NURBS surface is defined by a net of control points, and two parameters. In general, each control point lies either on the surface or act as if it is connected to the surface by a rubber band.

Each of the control points of a surface also has a defined weight that defines its influence on the surface shape in comparison to the other control points. The weights allow NURBS to precisely define conics and circles.

NURBS have a set of advantageous features that has contributed to their success;

First, they are invariant under affine and perspective transformations. This simply means that rotations and translations can be applied to NURBS surfaces simply by applying them to the control points of the surface.

Next, NURBS allow for a common mathematical form for representing both analytical and free-form shapes, thus providing the flexibility to design almost any shape. Since the control points and weights define a full surface, memory consumption can be lower than methods where all points on the surface must be stored.

Finally, NURBS can be evaluated quickly by numerically stable and accurate algorithms (22).

The basis of the math behind NURBS curves is that the curve should be defined by the control points, but that each control point should only affect the part of the curve that is close to it. A NURBS curve is defined by a parameter, usually called u, with values between 0 and 1. These values represent each end of the curve, with the values between describing a position along the curve.

In order to limit the effect of a control point, the parameter space is divided into a number of intervals. A basis function is then defined, which makes sure that for a curve of degree d, each control point will only affect the curve within the d+1 closest intervals. This feature is known as local support and is a very useful property when modeling. How much a control point affects the curve within these intervals is defined by a polynomial function, known as the basis functions.

The values that define the end of one interval and the start of a new one are known as knots, and they are stored in a knot vector. The number of knots is directly related to the number of control points, and the desired degree of the curve. Another important feature of a NURBS curve is its order. A curves order is the number of points that affect the curve at any given parameter value, and it is

Figure 12 - Nurbs surface


NTNU 2009 23

equal to the degree of the basis functions plus one. For a curve with linear basis functions, each point on the curve is affected by only two control points, and ends up lying on a straight line between these two points. If these control points are at the same position, the only remaining option is for the curve to also go through this position. Thus, we can make the curve pass through the control points by placing a number of them at the same place, with number being equal to the curves order. This allows us to make creases and corners on an otherwise smooth curve. (23)

A way to simulate many control points at one position is to add several knots of the same value to the knot vector, resulting in a number of zero-length intervals. Since each control point affects the d+1 closest intervals, this can make sure that the curve at this position is defined by only one control point, effectively placing it at the control point’s position. The downside to this method is a loss of continuity in the surface, just like when several points are placed at the same position.

The degree of a curve basically defines its continuity, or how “smooth” it is. For surface modeling, cubic curves are most commonly used, these curves are defined by third degree polynomials, and they ensure curvature continuity at all parts of a surface. This will often result in a fair surface without too much modification.

In order to calculate a NURBS curve, one simply needs to calculate the values of the curve for a number of values of u. The easiest solution is to divide the parameter space into equally long intervals, and then calculating the values at each of these intervals. The number of intervals used will then define how accurate the curve is. A second solution is to adjust the number of parameter values according to the shape of the surface. By calculating the curvature of the surface, and then evaluating the curve using more points at positions with higher curvature, we can get a curve that has high accuracy at points with much detail, without having to calculate as many points in the remaining areas.

For each parameter value, the basis functions have to be evaluated, and then multiplied by the control points coordinates. The sum of all control point positions multiplied by their basis functions results in a set of coordinates that represents the curves position at this parameter value.

The mathematical formula for the NURBS curves is as following:

Here, C(u) is the parametric representation of the curve, using u as the parameter. Pi is a vector contacting the coordinates X, Y and Z of control point i. Ri,n are the rational basis functions, which work as basis functions adjusted to allow control points to have assigned weights, that allow some points to have a higher affect on the curve than others.

Ni,j are the basis functions, defined as:


NTNU 2009 24

where

and

ki is the value of the i-th knot, with i being the knot interval that contains u.

The calculation of the values of C(u) can be done effectively by the use of the de Boor algorithm. The de Boor algorithm is described in detail in (22) and (23).

The calculation of NURBS surfaces is similar to the one for curves, but with the addition of a second parameter v. For surfaces, we then have a net of control points instead of a row. Calculation of points on the surface can be done at regular intervals of u and v, just like we do for a curve.

The NURBS evaluation in the prototype application uses a de Boor algorithm that works on a regularly spaced set of the u and v parameters. The number of parameter values used is defined independently for each module, and this allows the designer to increase the detail level of modules with more curvature and local features, and reduce the detail in modules with less detail, keeping the number of calculations down. A curvature based method could allow for automatic adaptive detail level for the surface, but is significantly harder to implement. More information on adaptive NURBS evaluation can be found in (22). A less technical, but easier to understand description of NURBS curves can be found at (24).


NTNU 2009 25

13 Case studies

In order to compare the different hull-modeling methods, I will set up a number of cases. These cases are to be solved using a number of different methods. The end result and workflow can then be compared in order to find differences in productivity, flexibility and ease of use for each method.

In order for the cases to serve as a good comparison for the methods, they need to be realistic and cover a wide range of tasks. In addition, each case should be simplified into short and easily repeatable tasks. It would be possible to make a more advanced set of cases, that included performance evaluation or a full project cycle, but this is beyond the scope of this thesis. More advanced cases would be significantly more time consuming and large parts of the case solutions would be similar or identical between the methods.

As part of the simplification of the cases, I will try to make a scenario where I consider only the process of modeling the ship hull, and not the process of calculation stability and performance. This means that the case is considered solved when a faired hull surface is available. It is assumed that such a surface can easily be exported to a format where it can be utilized by an external application for assessing the performance of the hull.

The end result of each case will thus be a single NURBS surface, saved in the .3dm format which can be opened by Rhino3D.

One important consideration that must be made when reading the cases is that it is not the resulting hull shapes that should be compared, but rather the methods used to obtain them. The resulting surfaces will be of reasonably low quality, since they are made by a non-professional designer as a first draft. The time dedicated to modeling each hull is also relatively short. Higher quality hulls could certainly be created if more time was used for tweaking them.


NTNU 2009 26

13.1 Case 1 – Initial creation of a ship hull This case will consider the initial creation of a ship hull shape from scratch. The designer in this case is given a list of main particulars for the hull, and must create an initial hull shape. The resulting hull shape shall be the basis for a further optimization process to optimize stability, and reduce cost and resistance. The main particulars for the hull are as follows:

Length: 185 m Breadth: 33 m Depth: 18 m DWT: 60.000 tonnes

The hull shall include a bulbous bow.

13.2 Case 2 – Modification of existing ship hull

The second case concerns the modification of an existing ship hull. For simplicity, the hull to be changed in each case will be the one created in case 1. This assures that the hull is representative for the method that will be used. If the same existing hull file was used for all the cases, one might be at an advantage towards the others.

The hull shape created in case 1 included a bulbous bow and a relatively wide stern. The new model should have a sharper bow without a bulb, and a slimmer stern. The rest of the hull should remain mostly the same.


NTNU 2009 27

13.3 Methods utilized when solving the cases.

Each case will be solved three times. The first solution is created by using the general purpose 3D modeler Rhino3D (5). Rhino is a popular surface modeling application used for a number of purposes. It is easy to learn and use, and includes especially good support for a wide range of popular file formats. In addition, there are a number of marine design related plug-ins available for Rhino, most notably RhinoMarine (25) and Orca3D (3).

The second solution will be based on a “best-case” scenario. The case will be solved with a make-believe application that implements all the new methods presented in this thesis in the best possible fashion. This solution can be an example of the vision I had when the methods were presented. The description of the work done in this solution will include a set of prototype images for how I imagine the application could look, and how certain key tasks will be performed by a user.

The third solution of the cases will be performed using the prototype application I have created as part of my thesis. A thorough description of the prototype is given in a later chapter, including comments on why certain functions are implemented the way they are, or in some cases not at all.

The prototype is in no way a fully featured hull design application in its current form, but can be seen as a crude example of what is possible to implement within a relatively short amount of time. The application itself will be published with the Master Thesis. In addition, the application is based on open-source libraries and the source code itself will be released as open source. This means that anyone can continue working on improving the application or use it as a building block for creating and testing other hull design methods.


NTNU 2009 28

13.4 Case Solutions

13.4.1 Case 1 – Rhino

The first hull is manually created in Rhino3D by lofting a set of curves into a NURBS surface. The process is outlined below.

First, Rhino is started up, and we are greeted with an empty scene:

Figure 13 - Rhino user interface

The next step is to create the lines that shape the midship section. This is done in the front viewport. Only the port side of the hull surface will be created, since the hull is assumed to be symmetrical. The Starboard side can easily be created later by mirroring the port surface.

This curve is then copied three times to create the shape of the parallel midship section. We then add a curve that defines the bow shape, and a curve to define the transom. We now have six curves that specify the main particulars and shapes of the ship hull.


NTNU 2009 29

Although the six curves define the hull partially by themselves, we need to add five more in order to control the final shape of the bow and aft of the ship. Of these five curves, one controls the bulbous bow shape and angle, three control the shape of the bow, and one shapes the aft. For further control over the surface, even more curves can be added. More curves generally increases the complexity of the surface, and reduce the fairness, eleven curves is therefore a good number at this stage.

The creation and modification of the curves is a quite time consuming task, with little feedback with regards to how the end surface will look. It also requires a little experience to know how many curves to create and where to place them.

When the eleven curves have been created, we need to join them together to form a surface. In 3D applications, this process is known as lofting. (This name actually originates from the lofting done in boatbuilding).

We select all the curves and run the lofting tool included in Rhino. The lofting tool allows a surface that runs through all points on all curves, with straight sections between, the end surface with this lofting tool will look like this:


NTNU 2009 30

This is clearly not a fair hull shape, so a better option is not to demand that the surface goes through every curve, we just use the curves as guides and try to get the fair surface that best approximates the curves. This is called “loose” lofting, and the end result looks like this (after mirroring).


NTNU 2009 31

This hull clearly needs some work with regards to fairing and general shape, but it is a good example of what it is possible to achieve as an inexperienced ship hull designer in Rhino. The hull surface can now be exported to another program for performance estimation, and the results can be used to further improve the hull. It becomes clear quite quickly that while this method works, it would be much easier if the application showed the surface at all times. The way it is now, even a small change requires you to delete the surface, change the curve, and then re-loft the surface to see how the change affected the surface.

It could seem that it would be easier to start out with a surface that was modified directly, but then we lose the direct control over factors such as bilge radius and bulbous bow shape early on. While starting out with a surface is certainly doable, it requires an experienced designer and a good plan.


NTNU 2009 32

13.4.2 Case 2 – Rhino

We start out with the same hull model that was the end result of case one. The lofted hull surface is then deleted, and we are left with the curves that defined it.

The first change that has to be done is the removal of the bulbous bow; this is done by deleting the two curves that make up the current bow. A new pair of curves is then created and placed at roughly their new position. One curve is needed to define the new bow shape, and one that helps define the fullness of the bow.

The third curve from the front is also slightly modified in order to accommodate the new shape of the bow.


NTNU 2009 33

The curves could now be lofted together again if only modification of the bow was desired. In our case, there was also a need to have a slightly slimmer stern. This is rather easily obtained by modifying the last two curves of the hull, and moving their outer points about one meter towards the centerline of the hull.

The curves can now be lofted together and mirrored like described in the previous case, and the resulting surface is presented in the figure below.

Figure 14 - Final hull developed in Rhino

Solving case 2 by this method is relatively easy to learn and perform, but the problems appear as more accurate and fairer hulls are required. The largest problem is the problem with visualizing how the surface between the curves will behave. In order to get the surface “just right”, the designer will have to modify a curve, loft the surface and see how it looks, before deleting it and doing a new modification to a curve.

The deletion and re-lofting of the surface is an extra unnecessary step that significantly reduces the productivity of this method. In addition, the lack of a visible hull surface while the curves are modified makes it hard to see the results of each modification. These two downsides make this method for modeling a ship hull less suited than it would otherwise be.

The Orca3D plug-in reduces these problems by allowing modifications of the surface through a number of points, but at the same time, you lose the ability to easily add and delete curves when a modification of the surface or areas of added detail are desired.


NTNU 2009 34

13.4.3 Case 1 – Virtual optimal application

This solution will represent how the case could be solved with an optimal application that implements all the methods described earlier. The target of this chapter is to show how the design process can be made quicker and easier with the new methods and at the same time provides inspiration for implementation of

these methods.

The first task when generating the ship hull is to input the ship-specific parameters that the application can use to scale the imported modules.

The next step is then to select a bow from the module library. In the optimal situation all modules are of normalized size and they will be scaled according to the ship parameters upon import. The addition of a bulbous bow will be implemented as a module modifier, so all modules will be without bulb. The window for selecting module could look something like represented below.

Figure 16 - Example module choice dialog

When “Parametric Bow” is imported into the model, a new parametric bow will be created from a set of default parameters, and then scaled automatically to fit the global ship size. The parameters for

Figure 15 - Global hull parameters


NTNU 2009 35

the module define the fullness of the bow, and the angles and shape of the area where the bow meets the midship module.

After the bow module has been imported and the parameters modified as desired, the same is done for the midship and stern. The midship will include parameters for bilge radius and keel angle, and the stern some parameters for transom shape and size, plus propulsion method. We now have three modules of the right shape and size in the model, but they are not yet connected together. There is also no bulbous bow yet.

The bulb is added by selecting the bow module and adding a “bulb” modifier to its modifier stack. This modifier will include all of the parameters related to the bulb, such as radiuses, angles and position. Adding the modifier to the bow module will immediately add a bulb to the bow module’s surface, and the bulb will update in real time as the modifiers parameters are changed.

With the modules each correctly shaped and with a bulb added comes the time to connect them together. This can be achieved simply by adding a Merge modifier to the stack of each module.

A merge-modifier will have a main ID parameter. All modules that have a merge modifier with the same ID value will be merged together to form a common surface. In addition to this parameter, the merge modifier will have some options concerning the method used to merge the modules together. This way, the smoothness of the resulting surface can be affected, much the same way as when lofting the curves when modeling with Rhino.

If the hull is not as desired after the modules are merged, we now have the option of adding a hull transform modifier to the active modules. One example of a useful modifier is one that allows you to pick a requested centre of buoyancy. The modifier will then try to modify the surface until this center is where the modifier desires, within the constraints set by ship size and the module parameters.


NTNU 2009 36

Another option for the designer for modifying the surface is to add a “manual modification” modifier to the modifier stack. Such a modifier would let the designer tweak the control points of the merges NURBS surface of the hull in order to make it “just right”.

The last change can be the addition of a “fairing” modifier that allows for a small smoothing of the parts of the surface with sharp transitions. A single or a few parameters can be used to control which parts of the surface will be smoothed, and how much. An example of the resulting hull surface is shown below.

Figure 17 - Final hull from optimal application

One important thing to remember is that the designer can go back at any time and change a parameter of a module, the bulb or the merging process, and the change will propagate upwards through the modifier stack and change the final surface. This will prove useful in the next case.

In general this method seems well suited for the task at hand, and every change and modification is easy to perform. This is of course to be expected from an “optimal” application.

The downside to this method is that it requires retraining and learning the concepts of modules and the modifier stack. The modules must also be available in the module picker dialog, so any moderately unconventional modules must be created manually, or a new parametric module generator must be made for that module type.


NTNU 2009 37

13.4.4 Case 2 – Virtual optimal application

The modification case shows the real advantages of this method. As a start, we open the file from the previous case. Removal of the bulbous bow is done by simply deleting the bulb modifier that was applied to the bow module. This can be done in a matter of seconds. If a slightly modified bow is desired, it is still simple to change the parameters of the bow module for fullness and angles.

Slimming of the stern is equally easy, and requires only a change of the parameters of the stern module parameters in this case.

All the other modifiers and parameters will remain the same, and the hull is thus similar to the old one, with the exception of the bulb and slimmer stern.

The figure on the next page is an example of how the user interface of the optimal application could look.


NTNU 2009 38

Figu

re 1

8 - E

xam

ple

inte

rfac

e fo

r the

opt

imal

hul

l mod

eler


NTNU 2009 39

13.4.5 Case 1 – Prototype application

This solution to case 1 is created by using the prototype application developed as part of this thesis. It is supposed to show which advantages and disadvantages a limited implementation of the module based design application can have, and at the same time review the usability of the prototype.

As described earlier, a modular approach is only really effective if some of the modules are already created. In the case where no modules are available, the method will only add an extra level of complexity, although modification of the surface may still be easier.

With this in mind, I created modules for the bow and midship modules that were ready for import to the application. The stern will be created as a part of the case solution.

When the prototype is started, we are greeted with the following window, containing a model with two example modules.

Figure 19 - Initial prototype user interface

The first thing we do is import the existing bow module. The import function is available under the Module menu. When the option is selected, an ordinary file selection dialog shows up that allows us to choose a module file we want to import. In this case, we select the file named “Bow”.


NTNU 2009 40

The module is now imported, and we remove the two default modules by selecting them one at a time and selecting Remove module from the Module menu. After removing the two modules we import the midship module. We now have a model with two separate modules.


NTNU 2009 41

In order to get a stern module, we can either create a new module from scratch, or import one of the other modules, and modify it into a stern module. In this case, I will import the midship module again, and then modify the curves into a stern shape.

When the stern module has reached its desired shape, it’s time to merge the modules together to form a common surface. This is done by selecting each module, and setting the MergeWithModel property to true for each of them. In addition, I turn off the ShowSurface parameter for each module, so only the merged surface will be visible in the viewports.

The figure below shows the model before and after the module parameters were changed.

The figures show that the merged hull surface is a smooth single surface, which does not diverge too much from the surfaces defined by the modules. The next task that is performed is to save the stern module to an XML file for later use, and saving the whole model so it can be opened again later. This can be done from the Model and Module menus.

Figure 21 - prototype hull before and after module merging

I will also export the merged surface to a .3dm file by selecting Model -> Export as 3dm from the menu. The resulting surface in Rhino is shown below.

Figure 20 - Module parameter grid


NTNU 2009 42

Figure 22 - Final prototype hull shape


NTNU 2009 43

13.4.6 Case 2 – Prototype application

To solve the second case using the prototype, we first open the model file we saved in the last case. The file loads with a hull merged from three modules, a bow, a midship and a stern. The task at hand is to remove the bulb from the bow section, and create a slimmer transom.

The first thing we do is to select the bow module, turn off its MergeWithModel property, and turn on the ShowSurface property. This allows us to modify only the bow module and see how its surface reacts to our modifications in real time.

Just as when we removed the bulb in case 2 using Rhino, we can now modify the curves that define the bulb shape, and create a smooth bow without it. The prototype shows how the surface is affected from all angles in real time as we modify a point on the curve. This makes it relatively easy to get the shape of the bow the way we want it, without spending time changing parameters or lofting curves into surfaces between each modification.


NTNU 2009 44

Next up is the modification of the stern. We first change the parameters of the bow back to re-merge them with the surface, and then un-merge the stern section in order to work on it. In order to highlight a new feature of the modular design flow, we assume that we have another stern module with a slimmer transom available in the hull library.

Thus, instead of manually modifying the stern module, we just remove it from the model, and import the one with the slimmer transom.

Merging the modules back together is a simple task of changing the properties of the newly imported stern to merge it with the others and hide its surface. The merged surface is then exported as a 3dm file again. The final merged ship hull without bulb and with a slim transom is shown in the images below, in addition to the exported 3dm file, opened in Rhino.


NTNU 2009 45

Figure 23 - Final prototype hull in application

Figure 24 - Final prototype hull exported and opened in Rhino


NTNU 2009 46

13.5 Case solution comparisons

After the two cases were completed with the three different applications comes the time to compare them to each other in more detail. Although large parts of the process are similar for some of the methods, some significant differences can be shown.

The method that ends up being most productive and flexible is not surprisingly the “optimal” application. That being said, it is not without its disadvantages and limitations compared to the other two. The most significant advantage with this application is the short time it takes to create a new module with the parametric module creators. The fact that these parameters can be changed at any time later in the process does not only allow for easy modification of the surface, but also makes both manual and automatic optimization significantly easier. If the case included performance evaluation, this advantage would be even more apparent.

The possibility of adding a manual modifier to the modifier stack also makes sure the flexibility to manually change the surface is the same as with the other methods. The only downside to this modifier is the fact that it lets you modify the surface control points, instead of curve points. Curves allow the designer to add more detail in some positions by adding additional curves around that position without disturbing the rest of the curves.

Naturally, the optimal application has problems with the new concepts that are introduced, and the radical change in workflow that some of them bring. These changes require retraining, and although parametric systems are generally more user friendly than 3D editing, the concept of the modifier stack might be hard to grasp for new users.

Modules for which there are no parametric generator will also require manual creation much in the same way as the other applications use, and in that case, the advantage would be a lot smaller than with parametric modules.

Last, but not least comes the question about whether it is feasible to implement the features of the optimal application in a real program. The time and cost required to do so might very well be better spent on optimizing other parts of the design process for a new ship. In some cases, the implementation of a feature might not even be possible.

The second best solution seems to be the prototype module application. The advantage here comes from the possibility to import and export the modules, in addition to work locally on a module without affecting the others. When manually editing, the prototype takes the advantage of curve based tools and combines them with real time feedback on how the end surface will look. This makes it a lot easier to modify the surface than with the delete – modify – loft method used in Rhino.

The negative parts of the prototype are very similar to the ones found in the optimal application, namely increased complexity, learning requirements and doubt as to whether implementation of the method is feasible.

The prototype itself can be criticized somewhat for a lack of features or a bad interface, but this is more a complaint of the implementation done by me, and more or less irrelevant to the discussion


NTNU 2009 47

about whether the method is good or not. Some of these shortcomings are discussed in the following chapter on the prototype.

The least productive method used for solving the cases was the purely manual curve method used with Rhino. Rhino itself is a very capable curve and surface editor, and the generation and modification of the curves is easy to learn and perform. However, since Rhino is a general purpose modeler, it makes no assumptions about the end product, and contains no function that makes the creation and modification of a ship hull easier.

This is especially apparent when smaller changes are made to the surface. The designer has to modify the curves, and more or less guess how the lofted surface will look afterwards. He also needs to do the steps of deleting the surface and re-lofting the curves each time he wants to do a modification and see it affect the surface. These two steps are quick to perform, but quickly become tedious compared to the prototype application, where the surface is updated automatically in real time.

The advantages of this method are that it can be used by anyone who knows curve modeling, using any modeling application which supports lofting of curves. Thus it is easy to learn, relatively easy to use, and very flexible. Implementation is also not an issue.

In general, the basic curve approach is flexible but time-consuming. Addition of new features such as modules, parametric generators and modifier stacks increase makes creation and modification significantly easier. At the same time they increase complexity and needs careful thinking in their implementation.

When comparing the two best methods, it becomes clear that the introduction of parametric modules brings great advances in creation and optimization, and that the addition of a modifier stack opens up for a bundle of new functions and flexibility.


NTNU 2009 48

14 Prototype application

14.1 Intro Inventing and investigating new modeling methods is interesting as a thought experiment, but the only good way to see if a new method is really feasible is to try it in practice. In order to do this, I gave myself the task of creating a prototype hull modeling application that implemented some of the methods presented. As shown earlier, I would then attempt to use this prototype to solve the presented cases, and while doing so, find new advantages and disadvantages I had not considered earlier.

In addition to the feedback I get when I use the prototype, valuable information can be extracted from the process of coding it in the first place. Implementing the methods is code requires careful planning both when it comes to the required algorithms, and the way we present the tools to the user through a user interface. This information can be very valuable for others that try to implement any of the methods themselves, since they can avoid doing some of the mistakes I have done early on. It can also serve as a guide to what parts of the implementation that needs more work to be viable. These parts could be possible subjects for further project or master work.

14.2 Prototype scope In my initial plans, I hoped for the possibility of creating a prototype that could encompass all parts of the hull modeling process, from initial hull creation, through performance calculations, and export to structural modeling. Indeed, one of the improvements presented concerns the calculation and feedback of stability and resistance values directly in the hull modeling tool.

After working on the prototype for some while, I realized that the inclusion of performance calculations would take more work and longer time than I had available, and I set a new goal for what the prototype should accomplish. Under the new goal, the prototype should be able to create and modify a module based hull shape representation, and export this representation to a format that can be imported in commonly available performance estimation applications. The results from the performance estimation can then be used to further improve the hull in my application.

After reducing the scope this much, I was expecting it to be possible to implement the two remaining methods in a reasonable amount of time, and then be able to try them out in combination. In the end, the focus of the prototype ended up within modular design. It is described later why the development of the prototype did not go directly according to plan.

First, a word of caution: I am neither a professional programmer nor mathematician, and there are probably several places where the decisions I have made are questionable or plain wrong. A dedicated team of professionals must be expected to reach a better result in a shorter amount of time than I have used. That being said, I still believe that the prototype is useful for evaluating the use of module based design, and I will try to explain the basis for my decisions as we go along.


NTNU 2009 49

14.3 Technologies and systems used When I was planning the creation of the prototype, a number of preliminary questions needed to be answered, the largest initially was the choice between implementing my prototype as a standalone application, or as a plug-in to an existing tool.

The creation of a plug-in seemed initially like the best choice, for a number of reasons. First of all, working with an existing 3D modeler would mean that I would not have to implement the code used to calculate and display the 3D data from scratch. I would have access to all the existing features of the application, and could start working on implementing features, rather than worry about the display of graphics and creation of a User Interface. Some applications would also include the necessary tools for modifying NURBS and API’s for calculating them.

Another feature I would get access to was the storage of my modules in the applications native file format. This seemed initially like an advantage, as it would save me the work with creating my own file format, but I realized later that the use of an existing file format could limit what parameters and modifier information I could include when saving the file. Trying to shoe-horn new pieces of information into an existing file-format could prove to be very difficult.

Export of the surface into a number of standard formats (STEP, IGES ++) is a feature that should not be overlooked. If I created a plug-in in an application with support for these formats, it would give me free compatibility with a number of other applications.

I did a quick review of the possible host applications for a prototype plug-in, and Rhino3D (5) immediately showed up as a good candidate. Rhino is a cheap general purpose 3D modeling application, and it has good support for plug-ins. In fact, several ship design related plug-ins were already available. Newer versions of Rhino also supported development of plug-ins using a managed language2

Rhino also has a relatively modern and effective user interface, and very good support for a number of file formats. In fact, some people use Rhino as a converter to help get 3D data from one application to another because of its good file format support.

based on Microsoft’s .NET platform, which I had worked with previously.

All in all, writing my prototype as a plug-in to Rhino seemed like the ideal solution, so I started development, and then quickly found some problems with my plan.

The first and most important problem faced with implementing a plug-in, is the fact that you are completely reliant on the documentation given by the application you are writing applications for. In the case of Rhino, I found this documentation lacking. Many reasons can be found for why the documentation was not good enough, not least of which is my inexperience as a programmer. The relatively short time since the introduction of .NET support in Rhino also meant that the documentation had not had time to mature yet. I also realized after a while that it could prove hard to try to implement my methods for module based design and modifier stacks into Rhinos existing User interface and workflow.

After a short while of trying to get Rhino to do what I wanted, I looked towards creating the prototype from scratch. Using Rhino’s user interface would mean I avoided the need to “recode the

2 A language where memory management is handled automatically.


NTNU 2009 50

wheel”, but at the same time, my own additions would tend to clutter up the interface and working my way through documentation and Rhino’s way of doing thing proved to be very time consuming.

Another discovery I had done while researching Rhino helped convince me. The creators of Rhino3D, McNeel Associates, had released an open source library called openNURBS (26) that would allow me to implement export and import of Rhino’s file format in my application relatively easily. This meant that I could create a new hull in my prototype, and then export it directly to Rhino’s native file format, from which it could be edited by Rhino and exported into all the formats that Rhino supported. In addition, I could select a file format for internal storage of models and modules without having to consider interoperability with other applications.

Thus, writing the application from scratch would now give me many of the same advantages that a plug-in would give me, although I would need to do some extra work on the user interface. The question now was what platforms and technologies I would use. My earlier experience had thought me that I was a lot more productive when I could write code in a managed language where I wouldn’t have to worry about manual memory management. The openNURBS library included support for the .NET platform, and I selected to work in C#, mostly because I already had some experience with it.

The next choice that had to be made was how to implement the user interface. Drawing of windows, buttons, and menus were easy through the use of Windows Forms, included in .NET. However, a 3D modeling application requires hardware accelerated graphics in order to be responsive. Currently, the only real options are OpenGL, or DirectX. The two are very similar, so it is hard to make a distinction between them.

The choice to pick one over the other came when I found a managed framework called OpenTK (27). OpenTK made it possible to quickly write OpenGL applications in C#. The library contains good documentation, and the resulting code was easy to understand and even cross platform compliant. OpenTK also included a small mathematics library for Vector and Matrix math, which would prove useful later. OpenGL itself includes some functions for evaluating and displaying NURBS, which seemed like a bonus to begin with, although I ended up writing my own NURBS evaluation code.

The choice had now been made, and the new prototype would be a Windows Forms application written in C#. OpenTK would be used to get hardware accelerated 3D graphics through OpenGL. The internal file format was yet to be decided upon, but export to .3dm files would be provided through the openNURBS library. A side-effect of these choices was that I had used only open-source libraries for my prototype, which meant that I could release my own prototype as open-source without problems.


NTNU 2009 51

14.4 Main challenges The next thing to do was to select how the user interface would look. I decided to go for a traditional modeler interface, where the window is divided into four viewports, viewing the model from the top, front and side, plus one view at an angle to show an overview of the hull. To the right of the four viewports is an area that shows information and possible actions on the currently selected module, plus available space for a modifier stack and information messages from the application to the user.

Underneath the viewports is a small area that shows the current coordinates of the cursor in the world, allowing accurate placement of points and surfaces. The final mockup looked like the figure below.

Figure 25 - Prototype layout overview

The next issue was to select a way to represent my model, modules and NURBS objects in the application. The prototype is written in an object-oriented fashion, so my modules and surfaces would be implemented as object classes that reference each other. In short, my hull is represented by a Model object, which contains a number of Module objects. Each Module has a NurbsSurface and a number of NurbsCurves that define this surface. The NurbsCurves in turn contain a set of NurbsPoints that define their shape.

OpenGL includes a separate library known as Glu (OpenGL Utility Library) that includes a set of functions for evaluating and drawing NURBS. I used these functions to draw my NURBS points, curves and surfaces initially, but after a short while they proved unsuitable for what I was doing, and I decided to write my own NURBS code, I will discuss this decisison in more detail later.

With a system set up for creating my surface objects and drawing them to the screen came the problem of navigating around in the 3D world. The main navigational features of every modeling application is panning, zooming and rotating the view. These three features had to be implemented in a fashion that was intuitive and easy to use, even without explanation. Panning and zooming


NTNU 2009 52

proved to be relatively straight forward to implement, but to get intuitive rotation of the view I had to use an ArcBall solution, and a lot of time was spent getting it to work correctly.

After the display and navigation was functional came the implementation of a system that made it possible to select the modules, curves and points. I had to try a few different methods before I found one that worked well, and ended up with color based picking of the objects. It was relatively easy to get moving of the points implemented after the selection code had been written. I now had a system where I could create and modify modules with surfaces, and look at them in all four viewports.

It became necessary to implement a save system after I had enabled the modification of modules. With save and load functions in place, I could easily continue working on modules after a restart of the prototype, and quickly get interesting modules to test new features on. The implementation of a file-format proved to be easier than anticipated. I settled on the use of an XML format for storage of both models and modules. One of the resons for this was .NET’s excellent support for XML serialization3

After implementing save and load functions for models and modules came time to add the possibility to export to the 3dm format for import to Rhino. Files that are exported to Rhino are only exported as NURBS surfaces, so there is no reason to load them back into the prototype. The export was enabled by the use of openNURBS, and thus required only a few hundred lines to implement. The added figures shows a surface modeled in the prototype (Green), and exported to Rhino (Gray).

. The XML format is also human readable, so if something didn’t work right it was easy to open the file in notepad and find the mistake manually. The figure shows how the xml file for a module would look when opened in Internet Explorer. It is easy to see the hiearchial structure of the module object, and even change it manually. We can also see the relation between the Module, NurbsCurve and NurbsPoint objects.

3 Converting objects to and from XML

Figure 26 - XML Module structure


NTNU 2009 53

With the export feature enabled came the time to properly implement the module merging system and modifier stack. Unfortunately, the work up until this time had already taken longer than anticipated, and the remaining time to implement these features were shorter than I had hoped for. In the next chapters, I will present which features took the most work, which features I didn’t have time to implement, and where effort should be focused for further work on the prototype.

Figure 27 - Module surface in prototype application and exported to 3dm format


NTNU 2009 54

14.5 Problems, features and decisions The first problem that took more time than anticipated was the evaluation and display of NURBS curves and surfaces. As mentioned, I initially used the included Glu functions to evaluate the surfaces, but this was not without its problems. The first and largest problem was the fact that I had to call the Glu functions that calculated the surface each time I wanted to draw it to the screen. With four viewports, this meant that I recalculated each surface at least four times each time something moved on the screen. This was true even when the surface was unchanged, but the camera rotated or panned. All surfaces would also be recalculated while one surface was being modified. This worked when only one or two surfaces of low quality was shown, but another solution was needed for display of multiple higher quality surfaces.

The only sensible solution is to calculate the NURBS surface only when it is modified, and then store the calculated surface somewhere it can be reference when it is time to draw it to the screen. The Glu functions allow the return of a calculated surface, but only in a format that would need extra juggling about to be usable. I also had some problems where an old version of the Glu library on some computers4

The mathematics behind NURBS is described briefly in an earlier chapter, and it should suffice to say that my code is based on a recursive version of DeBoors algorithm, as described in (22). The function calculated the NURBS surfaces each time the surface is modified. The function proves to be more than sufficiently fast even for high quality surfaces, but it could be optimized even further by adding caching of the calculated basis functions.

would return incorrect surfaces after evaluation. In the end, I decided to write my own code for evaluating NURBS. This would clean up my code considerably, allow me full control over the calculations, and allow for optimization of NURBS display. In addition, writing my own NURBS evaluator was a good way to deepen my understanding of NURBS before deciding on a module-merge method.

In order to speed up the rendering of the surfaces, they are immediately transferred to a buffer (Vertex Buffer Object) in video card memory after calculation. Each module contains a reference to the position of the surface data in video card memory, and thus the surface can be drawn simply by sending this reference to the video card, where the data is immediately available. The implementation of this system resulted in a much more responsive application, especially while a nurbs point was dragged with the mouse, with results shown in real time in all four viewports.

As an added bonus, the surface for each module is available in memory for use in performance calculations or similar tasks.

4 An outdated version of the Glu library is usually included in a windows installation


NTNU 2009 55

14.5.1 ArcBall implementation The second task that took longer time than anticipated was the implementation of rotation of the model views. In order to get intuitive rotation of the model I had to code an ArcBall implementation. ArcBall rotation is a fairly standard method for rotating a 3D view with a mouse, but the implementation itself proved to be tricky.

The basis behind ArcBall rotation is the placement of an imaginary sphere over the viewport where the rotation

should take place. The user clicks somewhere on this imaginary sphere with the mouse, and drags the mouse. The resulting rotation is intuitive, because it seems to the user like a ball is placed around the object in the viewport, and the viewport rotates with the ball just like it would in the real world.

The problems with implementing the ArcBall came with the need to transfer between the 2D coordinates of a mouse click on the screen to the 3D coordinates and rotation in the model coordinate system. In theory, the arcball also has infinite different ways to rotate a point on the surface from the first mouse click to the mouse position. We are obviously only interested in the shortest rotation. Finding this rotation is relatively easy, but converting it to an inverse rotation of the whole model coordinate system required the use of a mathematical concept known as quaternions (28). These rotations were hard to get working right, and the relatively advanced mathematics made it much of a trial-and-error process for me to implement. Luckily, it worked very well in the end.

Figure 28 - Arcball


NTNU 2009 56

14.5.2 Merging of the modules After the basic manipulation of the module surfaces was implemented, came the task of creating a system to connect the individual modules together. There are different ways that this task could be solved, depending on the desired flexibility of the merging process.

One solution would be to maintain separate surfaces for each of the modules, and then connect the module surfaces with a set of blending surfaces, that go from the edge of one surface to the beginning of another. This solution has the advantages of keeping the module surfaces exactly as they were before they are merged together, and it allow precise control over the continuity of the blend between surfaces.

The disadvantages of the method is that it is relatively advanced both to use and implement. The designer must manually control that the merging surface is smooth, and adjust it accordingly if it is not. The resulting model will also consist of a number of surfaces instead of a large continous one, which could make the process of exporting it and modifying it in other application more complex.

Figure 29 - Blending and merging of two surfaces

The second solution, and the one used in the prototype, treats the curves from each module as a curve on the merged surface. Each module is given a parameter that decides whether it is a part of the merged ship surface. This parameter is either true or false. The application then collects all the curves from all modules where the parameter is true, sorts them according to their position along the ship, and creates a new surface that is defined by them.

This approach is easy to implement, it creates fair surfaces, and it is easy for a designer to add and remove modules

from the merged hull. It also makes sure the whole ship hull consists of one large continous NURBS surface that is easy to export and keep fair in other applications.

One downside to this method is that the surfaces of the merged hull might not be exactly equal to the surface defined by the module before it was merged with the others. This happens because the merged surface flows smoothly from one curve to the next, while the module surface stops abruptly at its end curves. This is not a very significant problem, considering that we are aiming for as fair a surface as possible. The curves of each module can also be interactively modified even after the module is merged, and the changes to the merged surface can be seen in real time. This allows the designer to fix unwanted results of the module merge.

Figure 30 - Merge parameter


NTNU 2009 57

Another potential problem with this approach is the fact that the surface can not bend back on itself, since the curves are sorted by longitudinal position before they are merged. This can be fixed by having the designer select the order in which the curves are merged manually. In practice, no ship hulls have surfaces that bend back on themselves, so the automatic sorting was added as a way to save work for the designer.

Figure 31 - Surface turning back on itself

There are probably other methods for merging the modules that can be even more flexible, but I believe the one I have selected provides the best balance between ease of use, flexibility and simple implementation.


NTNU 2009 58

14.6 What would I want to implement, given more time There are a number of addition features I would like to have added if I had more time available. Implementation of one of these features would also be a good place to start for anyone interested in developing the protoype further.

14.6.1 Large changes, additional features The first additional feature would be the inclusion of a parametric module creator, with the additional changes that are needed to support modifications of the parameters even after the modules have imported to the model. Implementation of a parametric modules will require some knowledge of general parametric methods, and each module type would probably need a different module generator. Any implementation of parametric modules should also include parameters that are global to the model, such as length, width and depth of the whole ship. These parameters would then be used by all the modules for initial scaling.

I believe that the inclusion of a modifier stack in the prototype could be very interesting, especially in combination with parametric modules. The advantages of the proposed methods are largest when they are combined, and it would be worth doing a study on whether this is feasible, and worth the effort required to implement. The implementation of a modifier stack could get some tips from the implementation in Blender3D, where the source code is openly available (20).

The third large functionality that could be added to the prototype is calculation of the performance of the created hull. Integrated functionality for calculating stability and resistance would be a good addition, especially in the form described in the chapter about interactive feedback.


NTNU 2009 59

14.6.2 Smaller additions The following is a number of features that should be possible to add to the prototype relatively easily, since they would need no changes to the underlaying objects and data structures.

Transformations of the surface along the lines availaible in current hull design applications would be a good function to have, this includes full ship scale transformations with constant submerged volume and moving the centre of buoyancy around.

Additional changes that can be useful for manually modifying modules includes the possiblity to select more than one point at a time, functions for limiting movement of points to one axis or plane, and further options for adding and removing control points from the curves.

Addition of local appendages as part of the modifier stack could be a very good solution if possible. Functions for curvature analysis and further options for fairing would be welcomed by many designers, although the NURBS implementation delivers quite fair hulls directly.

It could prove useful to add better tools for importing hulls from other applications and file formats, in addition to an easier to use module library. A solution where the modules are presented with thumbnails that show how they look, and a some information about their scale and other data would be useful. Currently, modules are identified only by their filename, and it is up to the designer to give them good names when thay are exported.

Last, but certainly not least, comes the implementation of a good and robust Undo / Redo system. The chance to undo an action is invaluable if the prototype should be used professionally at some time. Existing methods and design patterns for undo systems should make sure the implementation is not too hard, although some changes to the current system for performing modifications must be expected.


NTNU 2009 60

14.6.3 What could be implemented in a better way? While I was working on the prototype, I realized that parts of it could have been implemented in a better way, and some things I would have done differently if I had started again today.

The largest difference would be to try again to get the prototype implemented as a plug-in to an existing 3D application. As mentioned before, the lack of documentation had me move away from this idea in the first place, but it could save a lot of time to avoid having to implement the display and calculation of NURBS, in addition to navigation in the viewports. The next release of Rhino, due out some time this year, might be more .NET friendly, and easier to write plug-ins for. If this is the case, implementation of further prototypes as plug-ins would probably be the way to go.

That beeing said, I feel that the current prototype application is a stable and solid platform on which to build further functionality. Most of the hard work regarding display and evaluation have been done, and the further focus can be on new functionality.

Scene graphs are a concept I would have liked to have implemented in the application. A scene graph is a data structure that contains all objects in the scene, and the relations between them in the form of parent-child connections between entities. A scene graph would simplify the addition of layers and selection of multiple objects in the scene, in addition to possibly making my drawing code easier to understand. More information on scene graphs can be found on the webpages for OpenSceneGraph and osgDotNet (29) (30).

The third thing I would change was to plan how to use my own code for evaluating and displaying NURBS right from the start. Using Glu made it easy to get things drawn on the screen, but I made a couple of assumptions and wrote some code that didn’t relly work well when I evaluated the surfaces myself later. This caused portions of functionality that was coded several times, and it took a lot of time that could have been better used somewhere else. Writing the display code manually from the start could thus give more time for optimization, and allow for faster rendering og higher quality NURBS surfaces. This is also true for the rotation and panning code, where I gradually changed functionality small steps at a time, instead of cutting out the old code and writing the new one properly right away.

I have only tested the application on the Windows platform, as far as I can see, there should be no problems running it on a mac or under Linux, since all the libraries I have used are cross-platform. It might be interesting to have the prototype run properly on all major platforms in the future.

I am sure there are parts of the user interface that are not considered intuitive by all users, but I did my best to make it self explaining and easy to use. A commercial modeling application should put effort into usability testing with both beginner and expert users, in order to make an application that is as easy to use as possible.


NTNU 2009 61

14.7 How to use the application? The best way to evaluate the prototype is to test run it. A copy should be included with this report, or be available at http://www.vikorasmussen.com/modship/

The prototype is only tested under windows, although it might be possible to run it under Linux or OS X by using the open source implementation of .NET (31). .NET should be included with any updated windows installation, the latest version is always available at:

http://www.microsoft.com/NET/

Using the prototype should be relatively straight forward, but a short introduction to navigating in the viewports might be useful.

To zoom in the viewport, scroll the mouse wheel. If no mouse wheel is available, Page Up and Page Down do the same job.

Panning in the viewport can be achieved by clicking and dragging with the right mouse button, and rotation works by clicking and dragging with the middle mouse button, or by holding down the Ctrl-key and right-dragging. If there are any problems with the view, the default layout can be restored by clicking the F5 key.

Modules, curves and points can be selected by clicking on them. The curves of a module can only be selected if the module itself is selected. Points can only be selected if the curve they belong to is currently selected. Points are only shown for the currently selected curve.

Points can be modified by clicking and dragging them with the left mouse button. Curves can be added and removed by using the buttons on the top right, above the grid that show the properties for the currently selected module. When a curve is added, its desired position along the ship needs to be selected in one of the viewports. Any new curve will be a linear combination of the two curves at each side of this position.

Modules can be created and removed from the Module menu, and the properties for the current module can be changed at any time from the grid of properties at the right side of the screen. One of the properties is called “Merge”. The module will be included in the final ship surface if this property is set to true.

The property named surfaceLevel decides the accuracy of the display of the module surface on the screen. This value can be decreased in order to speed up display of the surfaces on slower hardware, or increased for a more detailed surface. Notice that this value does not affect the quality of any surface that is saved or exported from the prototype, only the display internally.

The models and modules can be saved in the prototypes native format for loading at a later time, or exported as a 3dm surface for import in other applications. These actions are selected from the menu.

Some example modules and model files are included with the prototype.


NTNU 2009 62

14.8 Prototype summary The resulting prototype has successfully implemented systems for display and modifications of NURBS curves and surfaces. It incorporates a system for import and export of modules, and a way to connect these modules together and create a single surface ship hull. Both the modules surfaces and the merged hull surface can be exported as a high quality NURBS surface in the .3dm file format using the openNURBS library. This is a widely used format that allows the surfaces to be used in a number of other applications.

The native file format for the application is based on XML-serialization of the basic module and model objects. The XML format is human readable and easy to modify manually. In addition it is fairly straight forward to implement in the prototype.

The most time consuming part of the development process was the implementation of custom code for NURBS evaluation and display in addition to an Arcball system for intuitive rotation in the viewports.

The addition of parametric modules and module generation tools would be very interesting to implement in the prototype, had more time been available. The same is true for the modifier stack presented earlier in the thesis, and an interactive system for evaluation and display of hull performance, both in terms of stability and resistance.

Smaller changes that might be worth looking into is implementation of undo / redo, selection of multiple objects at a time, easy creation of local appendages and additional hull transformation tools.

Some areas of the implementation could also be rewritten in order to increase performance, maintainability or cross-platform support. These areas include more effective NURBS evaluation, inclusion of a scene-graph system. If a rewrite of the prototype is desired, a good approach might be to implement it as a plug-in to an existing 3D-modeling application.

All in all, I feel the prototype does its job and does it well, although there is certainly room for improvement and additional features.


NTNU 2009 63

15 Conclusion

Development and utilization of new methods for ship hull design will be an essential part of saving cost in a future of increased competition and lower margins. A method that increases productivity in the hull modeling phase can provide substantial savings. The more productive methods provide these savings not so much by reducing the time spent in early design phase, but by giving the designers more time to optimize their designs. A better optimized hull will lower cost over the whole lifetime of the vessel.

A set of methods were presented as possible improvements to the design process. The major method that was investigated in the thesis was hull modeling using a set of modules. These modules can be loaded from earlier designs, and provide advantages to both initial creation and modification of a hull. The ability to change part of a hull surface without affecting the rest is one advantage with modules, another is the possibility of exchanging a whole module for another one if larger changes are needed.

Even bigger improvements could come from the introduction of parametric modules. Parametric modules are faster to create from scratch than manually created modules. In addition, these modules allow for systematic variation of the hull surface by manipulation of the parameters, which in turn can make optimization faster and easier.

One downside to using a module based method is the increased complexity that is introduced. Another is the fact that parametric module generators must be made for each type of module. The selection of a method for merging the modules is also an area that needs careful consideration in order to get the best results.

The second improvement that was presented introduced a system called the modifier stack. This stack would allow a number of modifications to be added to a hull or hull module. The modifications will be completed in order relative to their placement in the stack, and each modifier works on the resulting hull shape from the previous modifier. The modifier stack allows non-destructive editing of the ship, in addition to a system for separating the different changes that are done. Modifier stacks have been implemented to great effect in other general purpose 3D modeling applications, and the addition would probably bring many benefits also in ship design. The modifier stack is especially useful when it is combined with the modular method.

The last subject discussed in the thesis was the evaluation and display of performance data for the created hull. The evolution of modern computers with multiple cores and use of GPUs for parallel calculations could speed up performance evaluations significantly. The performance data should be presented to the designer in a non-obtrusive way, and give both new and experienced designers help with making qualified decisions in the modeling process.

All the presented methods have common disadvantages when it comes to lack of support in existing applications, the need for re-training of the users, and an increase in the complexity of the design process. There is also a careful balance between flexibility and ease of use for each method. More specialized methods can bring productivity benefits and better usability, but reduce the range of hull


NTNU 2009 64

shapes that can be modeled with the method. This is especially true when using parametric hull generation.

The case solutions show that the addition of a module based workflow can indeed provide higher productivity in the modeling process. The “virtual” optimal application completed some of the tasks in a number of seconds, where a curve based method could use minutes or hours to complete the same task satisfactory.

It is clear that a further investigation on any of the methods is absolutely reliant on feedback from professional hull designers and users of the currently available applications. This feedback could be gathered by distributing a prototype application to the professionals and ask for their comments, although that approach might result in feedback on the prototype interface and lacking features, rather than on the method presented.

As a conclusion, I would say that a module based approach should be considered for inclusion in some current hull-design applications. The modifier stack can bring many benefits, and would be very interesting to see in practice, but implementation of a modifier system has its challenges.

Any group investigating the addition of any of the methods should also carefully consider the cost of researching and implementing the method, versus the benefit that can be achieved. If the cost is high, the money might very well be better spent improving a later stage of the design process.


NTNU 2009 65

16 Bibliography 1. Bole, Marcus. A Hull Generation Technique Based on a Form Topology and Geometric Contraint Approach. s.l. : University of Strathclyde, 2002.

2. Taylor, D.W. Calculations of Ships' Forms and Light Thrown by Model Experiments upon Resistance, Propulsion and Rolling of Ships. s.l. : International Congress of Engineering, 1915.

3. Orca3D Marine Design Software. [Internett] www.orca3d.com.

4. RhinoMarine - Yacht. Ship & Marine Design Software. [Internett] http://www.rhinomarine3d.com/.

5. Rhino3D. [Internett] www.rhino3d.com.

6. Bole, Marcus og Lee, Byung-Suk. Integrating Parametric Hull Generation into Early Stage Desing. Ship Technology Research. 2006, Vol. 53.

7. Harries, S. Parametric design and hydrodynamic optimization of ship hulls. Berlin : Mensch & Buch Verlag, 1998.

8. Jorde, J.H. Mathematics of a body plan. The Naval Architect. 1997.

9. Goldberg, D.E. Genetic Algorithms. s.l. : Addison Wesley, 1989.

10. Lowe, T.W. og Steel, J. Conceptual Hull Design Using a Genetic Algorithm. Journal of Ship Research. September, 2003, Vol. 47, 3.

11. Standerski, N.E. The Generation and Distortion of Ship Surfaces Represented by Globel Tensor Product Surfaces. s.l. : TU, 1988.

12. Bole, Marcus og Lee, Byung-Suk. An hierarchial approach to hull form design.

13. PolyCAD. [Internett] [Sitert: 5 6 2009.] http://www.polycad.co.uk/.

14. Nam, Jong-Ho og Parsons, Michael. A Parametric method approach for Initial Hull design using NURBS representation. Journal of Ship Production. 2000, Vol. 16, 2.

15. D-NURBS: a physics-based framework for geometric design. Qin, Hong. 1, s.l. : IEEE Transactions on Visualization and Computer graphics, 1996, Vol. 2.

16. T-splines. [Internett] [Sitert: 5 6 2009.] http://www.tsplines.com/.

17. CGSociety. 3D Studio Max Modifier Stack. [Internett] [Sitert: 26 May 2009.] http://wiki.cgsociety.org/index.php/3ds_Max_Modifier_Stack.

18. Autodesk - 3ds max. [Internett] [Sitert: 26 May 2009.] http://usa.autodesk.com/adsk/servlet/index?id=5659302&siteID=123112.

19. Blender 3D. [Internett] [Sitert: 26 May 2009.] http://www.blender.org.


NTNU 2009 66

20. Blender 3D - Modifier Stack Implementation. [Internett] [Sitert: 26 May 2009.] http://wiki.blender.org/index.php/BlenderDev/Modifier_Stack_Implementation.

21. General-purpose computing on graphics processing units. Wikipedia.org. [Internett] [Sitert: 26 May 2009.] http://en.wikipedia.org/wiki/Gpgpu.

22. Peigl, Les og Tiller, Wayne. The NURBS Book, 2nd ed. Berlin : Springer-Verlag, 1997.

23. Marsch, Duncan. Applied Geometry for Computer Graphics and CAD. Berlin : Springer Verlag, 2004.

24. Schneider, Philip J. NURB Curves: A Guide for the Uninitiated. Apple; Developer Connection. [Internett] [Sitert: 31 May 2009.] http://devworld.apple.com/dev/techsupport/develop/issue25/schneider.html.

25. RhinoMarine. [Internett] [Sitert: 1 June 2009.] http://www.rhinomarine3d.com/.

26. openNURBS. [Internett] [Sitert: 27 May 2009.] www.opennurbs.org.

27. OpenToolkit. [Internett] [Sitert: 28 May 2009.] www.opentk.org.

28. Wikipedia - Quaternions. [Internett] [Sitert: 29 May 2009.] http://en.wikipedia.org/wiki/Quaternions.

29. OpenSceneGraph.org. [Internett] [Sitert: 29 May 2009.] www.openscenegraph.org.

30. OpenSceneGraph - .NET wrappers. [Internett] [Sitert: 29 May 2009.] http://www.openscenegraph.org/projects/osgDotNet/.

31. Mono. Mono is a cross platform, open source .NET development framework. [Internett] [Sitert: 1 June 2009.] http://www.mono-project.com/.

Documents

“Hull form modeling in Conceptual design by assembly …vikorasmussen.com/modship/Master_Thesis_Viko_2009.pdf · Øyvind Viko Rasmussen Master Thesis NTNU 2009 I “Hull form modeling