Web-based 3D CAD Model Visualization and Markup

A **DRAFT** Project Proposal by Dennette@WiZ-WORX.com
(Version: 2006-04-08)

 

 

1)               Problem:

 

a)                The client's enterprise involves 3D CAD models of ships (naval architecture). They need to communicate models with their customers in digital form for viewing and markups. They would like to use a platform independent, Web accessible tool to perform walkabouts, to select parts for markup, and update a history of changes by multiple users.

 

b)                The client would like to create a data base that tracks markups to the models in a neutral format, most likely an extension of an existing standard to accommodate their product information requirements, some of which may not be inherently supported by commercially available utilities.

 

2)               Goals:

 

a)                Although the emphasis is on mega-structures (models the size of a football field, rather than the size of a football), there is a desire to preserve micro details.

 

i)                  For example, in a walkabout on a below-deck corridor, a bulkhead could be resolved to the size of individual bolts if the CAD models used to construct the assembly supports that level of detail.

 

ii)                A good hierarchical model would have a library of bolts, hinges, etc. ... you need this to do a bill of materials or an inventory on a compartment.

 

b)                (As an aside, I had a benchmark part for a facilities layout translator in 1985 ... it was a factory floor that covered several acres, with all the machines and furniture tagged to generate an inventory ... in the break room, there were four figures seated around a table playing cards ... when you zoomed in, you could read the suits on the cards in color, and the player with his back to the door was holding Aces and Eights!)

 

c)                Markup information must be archived with the geometry without actually modifying the original part.

 

d)                The priority of Web accessibility has yet to be determined ... it is Highly Desirable, but it is not yet a deal-breaking requirement.

 

3)               Solution:

 

a)                In this implementation, at the highest level, parts are represented in the viewer with little detail, simply a hollow shell of the union of all of a part’s components, perhaps with a realistic texture map.

 

b)                Models are formed of parts, which are themselves simply instances of models. One of a part’s properties is its visual appearance when it is viewed at a higher level, i.e., as a part of a model or of some other part.

 

c)                Inherent in the walkabout paradigm is the ability to examine objects.

 

d)                Selection of a part opens a window that has the part at a finer resolution, and the ability to either change the part’s definition (so that all instances of the part in this model are changed), or else a copy is made, modified, and stored with a link to the instance that it replaces.

 

e)                Since there is a visual representation for each instance that is independent of its underlying geometry (although derived from it, possibly dynamically), then simply changing the texture map is how original parts can be distinguished from markup parts, and the viewer can either display them in coupled side-by-side windows, or toggle a single display between them under user control.

 

f)                  Such an implementation can be done either locally or remotely, since all that is saved is the markups as a specially labeled part attached to the model (which can be updated asynchronous and simultaneous by multiple users), and the original model is loaded by the next user who then has a choice of which markups to apply to their session before they start making their own markups.

 

g)                It should go without saying that walkabouts can be recorded, so the viewer can be used for off-line presentations without high computational overhead.

 

h)                Client versions of the tool will keep a local cache of parts in the model that are common to the family of model parts, e.g., there are classes of galleys … but some don’t ever include certain standard galley library parts, like particular sizes of sinks, stoves, or tables.

 

i)                  Algorithms for purging the local cache and any cookies will also deal with a lot of the security issues.

 

4)               Preliminaries and Questions (in no particular order):

 

a)                Some scenarios should be created for a verbal walk-thorough of the exchange path, e.g., from modeler to data base to The User, then back to data base and finally to the administrator (archive); this will help identify interoperability issues, as well as user interface requirements.

 

i)                  Estimate: 2 man-weeks, including a smoke & mirrors demo.

 

b)                A representative collection of benchmark parts should be created based upon the most commonly used sizes from micro to macro ... these will be used for walkabout demonstrations.

 

i)                  Estimate: 1 man-week.

 

ii)                In keeping with the earlier analogies, a “tanker” model should have “football” part on one of the decks, which ultimately resolves to four panels of different colors/textures, stitching, and a valve … and a “porthole” or “hatch” part used in defining “bulkhead” parts should resolve into glass, frame, hinges, nuts, and bolts.

 

c)                Decisions will have to be made about model resolution, e.g., is a bulkhead just a NURB surface with a hole in it, or does it contain a "porthole" object with information such as the tensile strength of the glass it contains, and a part number for the hinge. {Well, I think this one has been pretty much answer now.}

 

d)                Assuming a hierarchical model based on the STEP Application Protocols for Naval Architecture and Construction, the intermediate database format should support all of the relationships that can be created in the native system that implement the AP as part of it's schema, or can be applied manually by an intermediate tool.

 

e)                The available utilities and open-source libraries must be cataloged and evaluated.

 

i)                  Estimate: 2 man-weeks

 

f)                  A proper statement of project requirements, with at least two proposed solutions.

 

i)                  Estimate: 1 man-week

 

g)                A formal definition of The User, including a profile.

 

h)                How will object selection for markup be made?

 

i)                  How do you perform a change to a 3D trimmed NURB surface that's a face on a shell?

 

ii)                Do you have to have access to the dimensioned "draughting" view of the part to make selections?

 

iii)               How do you select "hidden" parts in the model?

 

i)                  How much of the user input functionality of the base CAD system has to be supported?

 

i)                  How do you manipulate a b-spline curve?

 

ii)                Do you simply delete it and draw another one?

 

(1)                    You'll only need to provide DeleteEntity and AddEntity methods.

 

iii)               Or, do you grab its control points and manipulate them?

 

(1)                    You'll have display methods if this information has been preserved or can be generated, but you'll need more of the native API, or clones thereof.

 

j)                  Guestimate the product life cycle.

 

i)                  Is something better going to come along in the next 5 years?

 

ii)                Will it still be in active use a decade from now?

 

k)                Does The User require Real Time Gratification (RTG), or can they push a few buttons and then go get some coffee or a smoke?

 

l)                  Does The User download the model to their machine for local viewing and manipulation, or are they manipulating a model that resides on the client's server? {Actually, it looks like a combination of the two; offline viewing is a non-negotiable requirement.}

 

i)                  There are flexibility issues that are solved by both methods, but there are also data security issues to be addressed. (And not just the https:// kind … how can the absence of corruption be verified before appending markups to the data base?)

 

ii)                The Wikipedia paradigm should be investigated. (This is the free encyclopedia that anyone can edit in real-time.)

 

m)              How much training will be required by The User to operate the interface on a casual basis?

 

i)                  Will they use it daily, rather that once a week?

 

ii)                How long will an average session last ... five minutes or five hours?

 

5)               Suggestions (in no particular order):

 

a)                Models/Parts are either ARCHIVED (which means that even an administrator cannot modify them), or they are ACTIVE.

 

b)                LIBRARY PARTS are archive parts that can be referenced by any model, and can reside in local cache with a persistence based on frequency of use, subject to periodic verification with the remote database.

 

c)                Each model class can have it’s own default library of parts that can be affected by “global” markups so as not to impact the archived library … each instance (reference) specifies the Universal, Class, or Model version of its definition, so there is no confusion during viewing and markups.

 

i)                  As an example, there might be 7 standard hatches for bulkheads, but oil tankers only use 3 of them, while stacked container carriers use 3 different ones, and LNGs use 4 that overlap the other two classes.

 

ii)                Models of a specific type of LNG could remove the windows from HatchType4, or dimensions of HatchType6, without affecting the versions used by any of the other classes of models.

 

d)                My algorithm for data exchange translators and viewers has changed little since my days at Xerox in the 70s:

 

i)                  Open input file

ii)                Read an entity

iii)               Massage the entity

iv)              Write (or display) the modified entity

v)                Loop until done

vi)              Close and save the output file

 

This project adds a few more steps before the final one (between v and vi):

 

vii)             Select an entity from the displayed model. (This might require the activation of a drafting or 3D wire-frame view for accurate selection of geometry in the part.)

viii)           Record and display user modifications

ix)              Loop until done

 

e)                Web accessibility and platform independence (but not both) imply Java as the development language. (This is Easy Money, were I a betting man. :-)

 

f)                  There are several open source tool kits, vendor supplied APIs, limited license tools, and "plugins" available, which can be used as baselines for development:

 

i)                  http://www.jtopen.com/

ii)                http://www.ultrablue.com/dan/vxml/home.html

iii)               http://www.3ds.com/3dxml

iv)              http://david-lu.net/v4/work/3dxml/

 

g)                The use of contractors for development implies their availability throughout the entire product life cycle ... their heaviest use should be during the first two years after the initial release, as user sophistication increases and the initial design requirements prove inadequate for their new requests.

 

i)                  There are things that The User won't even imagine wanting to do until after they've had it in their hands and played with it for a while. (“Hey, I didn’t realize that it could do this; so why can’t it also do that?”)

 

ii)                At least one permanent resource from the client should be included from womb to tomb in the product life cycle, if only as a part-time liaison with contractors during the maintenance phase, but it's vital that they be identified before the forest is cleared (i.e., prior to laying the groundwork.)

 

h)                Several of the 3D adventure game engines provide ideal walkabout capabilities, and some offer adequate object selection capabilities. The best known Web based engine is the kind used in ActiveWorlds and Outerworlds (3D virtual reality chat environments), which also has an integrated Web browser frame ... one of my Round Tuit projects is to create some scenery objects for it from IGES files.

 

i)                  It is perfectly safe to download and install either of these browsers, and you can painlessly uninstall them after you’ve experienced the virtual 3D environment.

 

i)                  For markups, it's best to store the changes as objects appended to the model as tagged entities to associate them with the originals...

 

i)                  Displaying one as RED and the other as CYAN (possibly flashing deleted ones, which implies a DELETED object) is a simple visualization technique.

 

ii)                This also implies an ADMINISTARTOR mode and a USER mode to make changes permanent.

 

iii)               Since each user who makes one could tag their markups, this implies a rich history mechanism that could be preserved even after integration, thus allowing the administrator to back off from changes (undo) by traversing the history in reverse.

 

j)                  The sequence of markup changes must be preserved so that the history is just another sub-part in the assembly

 

i)                  This allows displays of markups to be animated

 

ii)                Applying markups to a model is just duplicating the users markup commands in the same sequence.

 

iii)               I also envision multiple windows showing markups by each different user so that an integrated, changed model can be designated the Current Master Version.

 

6)               Summary Thoughts:

 

a)                As Will Smith said to Jeff Goldblum in the movie Independence Day, “So, can you really do all that stuff you just said?”

 

b)                Yes, this can be done within 12 calendar months, with sufficient dedicated resources, like 5-7 warm bodies (3 full-time and 2-4 part-time.)

 

i)                  Whoever negotiates with tool kit suppliers (for licenses, access to proprietary APIs, and upgrades to them), should not also be responsible for the delivery of major programming contributions because of conflicting deadlines, e.g., they may have travel requirements that could severely impact schedules for coding, debugging, etc., due to unforeseen circumstances like weather delays.

 

ii)                People who write performance appraisals should not write code (although they must read it), and vice-versa.

 

7)               Accounting

 

a)                So far, this document represents 10 man-hours of work performed intermittently over two calendar weeks. It breaks down as follows:

 

i)                  Two half-hour phone calls on different days, one with the recruiter and one with the client.

 

ii)                Three hours researching and composing the first email draft, with one-third of that time researching topics on the Web to provide links to relevant sites.

 

iii)               Four hours revising and formatting this document, with about half of that time spent brainstorming and doing additional Web research.

 

iv)              Two hours additional brainstorming and reformatting as an HTML document to create a Web-accessible version.