Patching a Hole 2

[treddie]

Hello all.

I have this helmet bubble that I built from a VSS. But due to its odd shape, there was no way to terminate the bubble cleanly at the top. So an irregular hole is at the very top. I sliced the top just slightly larger than the hole with a cut so that at least the irregular hole was 2-dimensional. I can fill that hole boundary to make it a flat surface, but so far have not found a way to create a smooth patch to satisfactorily follow the bubble tangencies all the way to the apex of the bubble. In other words, I thought maybe I could apply a freeform blend to the flat surface, but the problem there is that the freeform surface that results does not terminate on the irregular hole boundary; it becomes a warped mesh rectangle instead that floats over the hole.

I also tried Edit>Extend, but that only allowed me to extend the bubble surface about .2 inch. My hole is a good 1 inch across.

Is there any procedure that works to fill up irregular (or even symmetrical) holes in geometry in ProE? A mesh would be fine I suppose, but at least a mesh whose boundary points land on the hole boundary.

Thank you very much,
treddie

 

[jeff4136]

By definition all NURBS surfaces are four sided
(a useful tidbit to tuck away for future ref).
Trim your opening so you have four edges / sides
(2 U or first direction, 2 V or second direction,
adjacent edges cannot be either tangent or
anti-tangent; for what I'm imagining your shape
looks like projecting a rectangle should work
well) and Boundary Blend.

> freeform blend to the flat surface ...
> a warped mesh rectangle instead that floats over the hole

A Fill surface with an irregular boundary creates an oversized
rectangular (maybe skewed) surface and trims it to the boundary.

 

[treddie]

Hi jeff4136.
Thanks for responding.
When you mentioned the square cut deal, and NURBS always having 4 sides, the first thing that went through my mind was "Boundary Blend" which you went on to suggest. I kept thinking I would have to make in the least, a circular cut, so I wasn't thinking Boundary Blend, but who cares? Square is just fine. So I thought, "That's it!" and went to work only to have ProE spit in my face. Because ProE "seamed" the helmet shell into 2 pieces, where the sides of the square cut across those seams, ProE would force a break in the edge of the square for that direction; one direction always worked, but for the other direction, it kept wanting to break up those boundaries into 2 segments each. So I thought, "no problem...I'll just have two attached curves for each side of the hole for that direction". But then ProE keeps saying the curves don't form a continuous loop and fails regen. I then rotated the square so that I could force 2 opposite corners of the square to land right on the seams, because that's where the curves were being broken in two. But it failed again, because one of those corners didn't ALIGN with the seam; it was off by a hair. Need to get to bed and tackle this tomorrow.

 

[jeff4136]

> Need to get to bed and tackle this tomorrow.

Sometimes that's the best deal going. ;^)

Sounds sorta like what you need to do is project your VSS seam
edges as Sketcher Reference entities and align trim curve
definition vertices (end points of your Sketcher entities) on
them. Neither the trim definition sketch nor the resultant quilt
trim needs to be strictly 'regular' (i.e. perfectly rectangular)
though keeping it as simple as possible is usually best;
intersection of adjacent edges square +/- 20 or 30 degrees so
blend isoparms don't get bunched up or adjacent continuity
constraints have to fight one another. Nor do the edges have to
be straight but avoid radical curvature fluctuations. Following
isoparm flow is often advisable (your analysis tools; Offset or
Curvature graphs will indicate flow).

Could be, as well, that you can create Datum Points on the seam
edges, Datum Curves from those (either free space and pull back
to surface or constrained (isoparm flow is important) to
surface.

If you can't get something going post the model or neutral
format translation somewhere (here? mcadcentral?) so someone
that's interested can see what you're working with. May be you
need to create the base quilt differently to get a 'nice' shape.

-Jeff (using wf2)

 

[treddie]

I didn't think about the projection of the seam edges in Sketcher. That will really help out because otherwise, placing datum points on the seams was not a "snappable" thing. So I had to zoom all the way in to get a datum point on, or as close to being on a seam as possible. But the problem is that ProE can't "see" the seams as an edge to build a projection from. So I'm trying a Thicken for the helmet surface now, and then I'll have a real edge to work from.

Which brings up a point. Is there a way to make a datum curve out of a feature edge, quickly and painlessly? I've tried searching for a way but there is nothing like "Make Datum Curve from Edge" or anything like that which I find truly odd.

 

[treddie]

Your idea worked perfect.
But to get that seam into sketcher as a reference and do the B-Blend, I had to:

1. Thicken the surface first to give me a physical edge to click on.
2. Publish the Thicken feature, then CopyGeom it back in to break any existing refs.
3. Delete the original Thicken and Publish features.
4. Use the edge from the CopyGeom'd feature as Sketcher ref via Sketch > Edge > Use.
5. Delete the "physical" edge in Sketcher while leaving its ref.
6. Build the 4-sided cut.
7. Publish the new cut surface.
8. CopyGeom it back in.
9. Delete all pre-existing surfaces, leaving only the final one.
10. Doing the Boundary Blend, and presto/changeo! Perfect patch completed.

I might add that I am a saving fool so that I can always go back into the history if I screw up somewhere.

So that concludes my 10-step plan for people with Post-ProE-Traumatic Stress Disorder (PPTSD).

Thank you very much for your help jeff. Without your assistance I would still be blubbering my way through this.

<treddie

 

[jeff4136]

Glad you got something going. You shouldn't have to jump thru all
those hoops, though. If you can read WF2 and want to look at a
helmet-ish shape ...

http://www.mcadcentral.com/proe/forum/forum_posts.asp?TID=33379&PN=1&TPN=20

 

[treddie]

Thanks for the links. I downloaded the helmet zip and the NURBS guide.

I think that in my situation, the problem was more difficult because rather than building from scratch, I had to reverse engineer this helmet (an Apollo space suit bubble helmet for a book project I am working on). To go back to the beginning, I essentially had only three choices to approach the helmet:

1. Scan the helmet with a 3D scanner which would have cost me $15,000 to $30,000 to buy the scanner (actually found one now for $2500 w/ .005" acc. which will be my approach next year).

2. Build an elaborate mechanical measuring jig to locate individual points on the shell
Surface.

3. Rotate the helmet in 10 degree increments and take digital photos of each turn, with the camera as far back as possible (w/ zoom all the way out so that the helmet fills the frame).

Method 3 was the approach I had to go with due to the cost of Method 1 and the time I had with the helmet shell, but has two problems:

a. Unless the camera is infinitely far away from the subject, true orthographic projection is impossible (there will always be some perspective distortion).

b. Unless you have a very special lens, there will always be some lens distortion in the field of view.

c. Grabbing the helmet cross-sections in this way has varying degrees of accuracy depending on its shape (see attached file Bad, “Helmet XSections.pdf”). If the helmet had the exact same cross-section no matter which angle it faced the camera, Method 2 offers a pretty accurate method of reconstructing it. However, per the discussion in the attachment, if the helmet has different cross-sections for each rotation, then the cross-section that the camera sees is NOT a crossection through its rotation axis. In fact the camera’s “cross-sections” are not flat surfaces at all, but “serpentine”, 3D surfaces. In my case, the only two reasonably accurate cross-sections were from the side, front, and back views. Fortunately, this helmet does not diverge TOO much from ideal, so that even though the cross-sections were not true 2D sections through the rotation axis, they weren’t too inaccurate.

Thus, I was really forced to rely on using the camera “crossections” as trajectories for a VSS. The result was faithful to the original, just not THE shape (see .jpg in the zip file). If you built a bubble from my ProE model and put it next to a real one, I think you would be hard pressed to notice the differences. The differences would be most noticeable only if you compared actual true crossections from both.

Don't know of any other way I could have approached this, but learning of a cleverer way would be nice.

 

[jeff4136]

> the problem was more difficult because rather than building
> from scratch, I had to reverse engineer this helmet

Indeed. Interesting project and a novel approach.

For what little it may be worth, I wouldn't have done it that way
although I might do something similar for 'supplemental reference'
data, nor would I scan it the way most(?) people would envision
going about it. That's predicated on [1] the assumption that there
are three key features (the lock ring and two 'conicoids',
probably ellipsoids) you want to capture, define and blend, and
[2] the shape definition rule of thumb; less is better.

Many objects are not so 'freeform' as we might think. Where they
are not; if we can identify the general nature of the shapes we
can capture, by whatever means, the important curves. The rest
will come naturally and can be verified with the 'supplemental'
data, assuming it's accurate enough to be more than a source of
confusion. That is especially relevant if the data is going to be
used to manually model the objects without the surface fitting
algorithms in the more expensive reverse engineering software
suites.

There are a few people that frequent McNeel's Rhino forum using
less expensive digitizers and software. Might be a decent place to
dig around or seek advice.

> for a book project I am working on

Cool. Something I might be interested in? ;^)

 

[treddie]

Well...it may be novel, but there is a ton of either isoparm bunching in the top 3rd, or simply slight inacuraccies in the cross-sections that go undetected until render time. I think it is the prior because there is no bunching at all in the lower 2/3; very smooth. I was afraid this would happen, but not sure how to fix it. My only other option was to mesh it all and take it into Lightwave or something and doctor the mesh until it's right.
A very long and tedious proposition.

I like your idea about simplifying the helmet to basic primitives and working from that, but it is extremely difficult to figure out what those primitives are when you have this freeform shape in your lap and no way to know just how those primitives "land" on the shape. There are no reference points to measure anything against. But also, this helmet shape was designed in the mid-sixties without computer graphics, so I imagine the master was hand-crafted by a really good craftsman, perhaps from bare-bones details about what was required of the shape. What would be your judgement?

The book project is a thing I started back in 1998, and covers Apollo spacesuit development during the 60's-70's. Mostly a very detailed illustrated account of how everything worked and was assembled. I have essentially finished reverse-engineering all of the hard components for the ILC A7L/A7LB lunar suits (which pretty well covers most everything back to the A5L (1965), by disassembling/measuring each part.

Why space suits? The reason is that my BIG goal was to do pretty much a similar thing with all of the Apollo hardware, spacecraft, launch vehicle. When trying to figure out a good starting point, I figured that the spacesuit would be the "easiest" project to tackle first. Although I still think that is the case, I must say that the old saying that anyone wanting to write a book doesn't know what they are getting themselves into is certainly true. I knew that going in and was prepared for it, but you can't REALLY appreciate what it means until you're in the thick of it.

The book will cover the ILC/HS line back to 1959.

 

[jeff4136]

> extremely difficult to figure out what those primitives
> are when you have this freeform shape in your lap and no
> way to know just how those primitives "land" on the shape.

True. It's very often not easy; trying to second guess the original
definitions, usually devolving into experimenting with what seems to
make 'sense', trial and error approximations. What you're really
looking for is uninflected areas, max and min curvatures and rates.

> imagine the master was hand-crafted

Good point. Really, though, it doesn't change a lot. You should (or I
would) still break the shape down into sections that could be
approximated with analytic shapes or shapes with similar characteristics.
You'll still have to fit and refine curves, but fewer of them, and the
discrete surfaces can be tweaked and refined to adjust local curvature
and rate of change.

The attached file has a couple of 'rough draft' variations on what I
imagine the shape to be. The Boundary Blend group may be something
you can incorporate into your existing model (create a new 'cap',
blend between it and the lower portion of your surface). If you can't
get something you think is acceptable and can let me have your wires
I'll see if I can't whip something up.


> The book project

Well, that is interesting and quite an undertaking. You have to
really love the stuff. ;^)

 

[treddie]

Thank you for the file. I will check it out tomorrow after I get some sleep.

I did take a quick look at it though, and it dawned on me that maybe the reason I'm getting bunching in the top third is that sections at 10 deg. intervals may be a little too much for ProE to handle gracefully. Maybe if I backed off to one section every 18 degrees (5 sections per 90 deg).
At any rate, it seems ridiculous that ProE can't just create it's own "hidden" closed spline for each step up the central origin trajectory. Since each spline would be completely convex, I don't see why it wouldn't work. Bunching seems stupid to me.

At any rate, I quickly checked out what looked like notes for a relation in your file. I'll take a closer look tomorrow.

Attached is a Maxwell rendering of the bubble. You can't really see the bunching issue in this image due to the angle of view, but it's definitely there.

 

[treddie]

Actually, check this out, too. Here you can clearly see the bunching (Top image, Maxwell...bottom image, ProE).
Please note, I'm using the term "isoparm" rather loosely here. There isn't really much "Iso" going on in radial crossections, I suppose.

 

[treddie]

Now that I did this test, It's clear that there aren't ENOUGH radial cross-sections. This approach to a VSS means that the starting section shape wants to "leak out" between the trajectories. I really feel this is an unfortunate bug in ProE only because it is counter to user-friendliness; in other words, if you want a section to be constrained to secondary trajectories, the VSS should take into account the relationship or intent BETWEEN those trajectories. Or rather, ProE should offer the option of choosing which way you want to go...leak, or smooth-constrain. I suppose that would be the better, more versatile way to go. But if that is the case, ProE doesn't even do the LEAK very well, for to be consistent, the shape should leak-out between ANY spacing of cross-sections and my VSS should not have been even remotely successful as it stands.

But, I'm not going to add more cross-sections for the very reason that I could only hope to diminish the problem, not remove it entirely. And who knows what ELSE would crop up, after adding more secondary trajectories.

Since this is a reverse-engineering problem, I feel it is important to stay faithfull to the original design, and trying to find the primitives to build it from will only add error, since these primitives could only be approximations based on assumptions about the true, radial cross-sections. The only way to get true cross-sections of any orientation would be to spray coat the helmet with a non-reflective coating and put a laser to the helmet. But then we're back to 3D scanning. What I WOULD like to do is 3D scan the bubble, and slice through the surface model in various ways and look for accurate primitives based on the sections. Fortunately, I have time to play with this thing; I can always work on other parts and wait to get back on site and scan the helmet later.

For the time being, I am going to try a rotational blend and see what happens.

<treddie

 

[jeff4136]

> try a rotational blend and see what happens

Unfortunately I don't think you'll find much relief there. The problem is the curves. There are only a few ways to get ideal curves; i.e. extract them from an ideal surface or define them with the same mathematical function that would be part of the surface's definition. Free hand doesn't work for the average person using average tools. Tracing scan points only works well if the scan is close tolerance and the scan line corresponds to a natural isoparm flow for the surface (not a problem with shapes as 'regular' as the bubble but important for more intricate shape combinations). Increasing the frequency of nonideal curves just increases the frequency of the waves which may further degrade the surface's appearance, and given the right circumstances can actually increase the wave amplitude. Thus the 'less is better' rule of thumb.

Just as an FYI: An isoparametric curve; a.k.a. isoparm, is a trace of a constant surface U or V value. All surfaces have them and, like points on a line, they are infinite in number. I suspect what you are referring to as isoparms are visible curvature irregularities. There is a relationship as irregularities are induced by control vertices and knots which also define the isoparm values (or maybe it's vise versa if you want to be mathematically correct; there are relationships anyway).

Good luck with it.

 

[treddie]

Yah...I tried the Rotational Blend, and although it really simplified things in general, the bunching was maybe worse. This means to me that the programmers at PTC are pretty imbisilic [sic?]. I mean, their blends have the feel of Newton Interpolation which is as about as dependable as a politician. Why the hell would they base their interpolation on anything but B-spline control points at the given y-height. Hell, I could go into Sketcher and in a sketch plane perpendicular to all the blend sections, plot datum points all the way around where the sections intersect the sketch plane, and get a nice smooth spline with no oscillations. And I could do that for each station plane up the y-axis. What the hell! If I can do it, PTC sure as hell can do it. S _ _ T, if I wrote my programs the way they do, I'd never get anything done. I'd hate to think that I'll have to write yet ANOTHER proggy to do what ProE should have done long ago. Another month or two out of my life.

Sorry for the rant...I guess I'll never get used to living in a world that could have been built on excellence, but instead is predicated on how long it is 'till the next coffee break.

About the isoparm thing, I was referring to radial sections as isoparms, which is not really isoparm-like except that the sections I have are rotated in equal increments. Unless (U) could be thought of as equal longitude and (V) as equal latitude. But that doesn't really classify as isoparms, I suppose.

Anyhoo, I'll be examining your file to look at things from a different angle. Hopefully it will restart my brain.

 

[treddie]

Well...I'm partially the imbecil. It turns out that the major bunching was caused by a bad section I built in Illustrator. Apparantly I accidentally moved a node out of position. Found it by orbiting above the helmet surface and looking for hills and valleys. But once I got that fixed, it was apparant that the remaining bunching was caused by innacurate sections that cannot be simply fixed, which was what you suggested yesterday and what I feared would happen before I started this thing; I remember having horrific thoughts of taking the model into Lightwave or something and doctoring the mesh there. But that's worse than sanding and filling a real helmet master.

I resist the primitives idea, only because I am not starting a helmet from scratch, but rev-eng'ing it and keeping it as accurate as all the other parts I have already built models of. At .005" accuracy, I hope the scanner I'm looking at for next year will deliver a mesh that holds up when textured as a refractive/reflective surface. .005" error is still a hill or valley on a surface, and hit obliquely with light may still show problems, or bend light in an obviously wrong manner. Also, a company may SAY .005" accuracy...but under what conditions?

So,...I still haven't taken a close look at your file since I was so busy edumucating myself about different blend attempts. At least now I know from experience the limits of Sweeps and Blends.

 

[treddie]

Your primitives approach may be easier than I thought. Don't know just yet, but went back to the side and front views from my photo shoot(which are very accurate for this purpose) and found an ellipsoid-like feature that MAY just fit the bill. At least at first sight, it appears to fit to good NOT to be correct. Am going to play with it.

 

[jeff4136]

Good to hear you're (maybe?) making progress.
You might find the attached interesting to play with.
I don't know how hung up I'd get over accuracy with that thing. It's a stable shape but it is plastic. I'm thinking a thirtysecond to sixteenth inch from concept ideal after tooling, process, age ...?

 

[treddie]

Dude...you're reading my mind. I was thinking about a number of things, today:
1. Deformation due to heat when released from the mold.
2. Repeated press/depress from 0-3.8psi during normal use, plus proof pressure to I believe something like 16 psi.
3. Age, roughly 40 years old.

I don't know the stability of polycarb, but the stuff IS quite flexible.

Here's another weird coincidence. 2 months ago, I was drawing up plans for a model of the Planet of the Apes spaceship (to be built out of styrene sheet, eventually). I have copies of the original blueprints used to build the full-size prop. But like all things, and especially in the movie industry what with the time crunches and all, the elliptic cone crossections did not come out quite ideal, and the prop ended up with slightly bloated ellipses (imagine a cold capsule shape, then imagine an ellipse with a tiny bit of capsule shape distortion added to it). So that caused me to recall something from my old days as a technical illustrator in the 80's, something we used to refer to as a poor man's ellipse. Sometime's it is faster to build huge ellipses that way, rather than scan in an ellipse from an ellipse template, blow it up in the camera, and use it as a pattern. Remember, POA was back in the 1960's and there were no computers OR scientific calculators, and I seriously doubt that Hollywood would have spent the time plotting ellipse points via slide-rule and trig tables. The thread and tack method is too flexible for large ellipses, so any number of "poor man's ellipses" would have sufficed. At any rate, this prop had that kind of tweaked elliptical shape to it. My problem was that since I was building a computer program to build cuts through this type of cone, so that I could eventually build flat patterns for styrene sheet, I had to find a way to tweak the standard elliptic cone equation to handle the error in the ellipses, and still simultaneously solve for intersection with a free line. If it's an ideal elliptic cone, you end up with a quadratic for the simultaneous solution, and it is simple to solve analytically. But I had to add a deformation filter of sorts. What started out as the simple ellipse (and elliptic cone) equation ballooned out into these really huge equations, especially since now, this new tweaked cone still had to simultaneously solve for intersection with the free line. What I ended up with was a numerical solution.
So here I am now, looking for an ellipsoid to base the helmet on. From the side, I get a beautiful match with a certain ellipse. From the front I get...a poor-man's ellipse! Even with age and deformation, I assume the new helmet would have still had this shape because the error from ideal is too great (overall, about 1/4 in). But my point is that, I haven't thought of poor-man's ellipses in decades, and here come two projects one right after the other suggesting their use.
Weird...

So anyway, now that I have the general equation for the tweaked ellipse in hand, I can plug this into ProE through a relation and build the funky ellipsoid primitive (2 planes tweaked, the third is an ideal ellipse). The only thing yet to plan is the transition down from the tweaked ellipsoid to the circular base, then add a base ring. That would be simple, since I can grab the shape of the top section of this transition from a section through the ellipsoid, use 4 datum curves to control the transition down to the circular base, and I think that's it.

Opened your file, and looks like I'll have something to play with tomorrow. Am curious about what you did in there, since it has bearing on the whole inaccuracy issue.

Thanks again, Jeff.

<treddie