Hi Dave,
In terms of graphic presentation, if a "chord" approach is used then
probably all that is needed is a "chord offset" parameter, both vertically
and horizontally. For plotting purposes this value can probably be quite
large as at the usual plot scales it will appear smooth to the eye. Say I
plot with a line width of 0.18mm at a scale of 1:500. This would translate
to 500*0.18= 90mm, say 100mm or 4"
However for design purposes it should be far more accurate. I would want to
snap to this object and have full double precision accuracy.
We certainly don't want to have issues with offsetting it when at large
coordinates such as happens with polylines.
--
Laurie Comerford
CADApps
www.cadapps.com.au
"Dave Simeone" wrote in message
news:4051e90b$1_2@newsprd01...
>
> Hi Steve - I guess the real question relates to working with 3D
arcs/splines
> (including parabolic vertical curves). What I was referring to in the
> tessellation is as follows:
>
> LDT/Civil Design grading - create a curve that you want to grade in Civil
> Design. When you grade this object the program has a setting that defines
> the increment that grading projections will be created along the arc. A
> small increment is more accurate, but higher in overhead.
>
> I would imagine that you want to keep the 3D geometry (almost like a
> mechanical part) that you shape with 3D offsets based on the exact 3D
> geometry. Specifically I am talking about modeling an alignment that has a
> parabolic curve.
>
> DAS
>
> "Steve Cannon" wrote in message
> news:4051e260$1_1@newsprd01...
> > Dave, I had to re-read your post several times to try and understand
> exactly
> > what you are asking:
> >
> > >Historically we've generally "accepted" the tessalation (tessellation?)
> > >of 3D vertical curves ... when working from a grading feature line.
> >
> > Laurie seem to assume you were talking about the parabola in a profile
> > view - and if this is the case, I am comfortable with the status quo
> > graphical representation. However, it sounds to me you are talking
about
> > the sampling increment of 'Z' data to be placed in a potential grading
> > feature line. Historically, I did know that either LDT or C3D had any
> > routines that did this. The LDT 'Superimpose' profiles is the only
> existing
> > AutoDesk routine that I know that samples a profile at an increment. If
> > this is in indeed what you are asking - it scares me to think about the
> > direction you might be heading!
> >
> > Background: Within LDT, we have written our own 3Dpoly to Profile and
> > Profile to 3Dpoly routines. In going from Profile to poly we sample at
> all
> > critical points: PI's, PC's and PT's in the XY alignment. We sample all
> > PVI's locations from the profile. The routine requires a horizontal
curve
> > sampling factor and a vertical curve sampling factor that are
> independent -
> > because of the nature of the mathematics. We make it user selectable -
but
> > more often than not we will use a 0.5' foot horizontal sample through a
> > vertical curve and a mid-ordinate distance sampling criteria for
> horizontal
> > curves of 0.05'. This can result in a large number of 3dpolyline
> vertices.
> > The resultant 'tessellation' seems to be pretty good for terrain surface
> > creation, but here are the other design problems we encounter with this
> > approach:
> >
> > - The large number of closely spaced vertices can make grip editing
and
> > critical point location tough to id in plan view.
> >
> > - A 3d object looses 2d characteristics - for example you can no longer
> > query horizontal curve from the object.
> >
> > - Plan lengths are replaced with True lengths on the object. Stationing
> is
> > lost. Neither AutoCAD nor LDT provide easy to use tools for plan queries
> of
> > 3d AutoCAD objects.
> >
> > - The large number of vertices make it difficult to locate true slope
> > breaks.
> >
> > - For all the above reasons the designer needs keep two layers of
> segregated
> > design data - one for plan work and one for 3d design work.
> >
> > It would be my hope that C3D did not go down the same path. As I sit
here
> > and type, I see that Doug just now expressed my very concern in his
reply
> to
> > Laurie above:
> >
> > > I think we should be able to have an interactive string element which
> has
> > > its horizontal geometry defined with horizontal tangents and arcs and
> its
> > > vertical geometry defined by tangents and vertical curves that
designers
> > are
> > > familiar with but which displays the resulting 3D polyline as a
feature
> or
> > > property of that object ...
> >
> > This 'string' element could potentially be an alignment. It 'handles'
> > horizontal manipulation. The present C3D problem I see is that the
> profile
> > is not a property of the alignment, but instead an independent object.
If
> > the profile was a property of an alignment, whereby the user could
> > right-click on an alignment and manipulate the 3d elements of the
> alignment
> > by both graphical (profile) and tabular (sta-elev-pvi) means, we have
the
> > starting structure for the string object. If I queried a location in
plan
> > view along the alignment, I should also be able to get the vertical (z)
> spot
> > data. If I 'snapped' to any location along the alignment I would also
> snap
> > to the z coordinate, which is retrieved from the profile property. If
you
> > gave me plan tools, whereby I could change the elevation of a spot
> location
> > on the alignment, that elevation would reflect in the profile property.
> If
> > you gave me a tool to interpolate a slope between two horizontal
vertices
> on
> > the alignment, it would reflect in the profile property. There should be
> no
> > reason I couldn't add a vertical curve in plan view. I could see a full
> > range of interactive site design tools that allow you to modify a point
in
> > plan view based upon slope, grade, or vertical distance from other
> 3dobjects
> > in the drawing. You could even have a routine similar to the LDT 'Curb'
> > routine: pick the alignment, an offset distance (horiz) and offset
> distance
> > (vert) that created a new OFFSET Alignment (say L1) and OFFSET profile
> that
> > was based on the main CL stationing. OFFSET alignments also have their
> own
> > associated profile property that could be manipulated after the offset.
> For
> > that matter, the horizontal alignment could also be post manipulated
with
> > grips or whatever, while interpolating new 3d(profiles) by stretching or
> > extrapolating.
> >
> > And of course, they key to real productivity is that the alignment can
be
> > used as a feature line for grading objects. As such, the
> alignment-feature
> > line keeps its plan and profile features, and any tessellation required
> for
> > tin creation is kept in the background and not even seen by the
designer.
> > Horizontal curves still appear as smooth arcs. Grips remain on the
> alignment
> > only at critical stations. The programmers should be able to come up
with
> > internal algorithms for sampling such as mid-ordinate for horizontal
> curves,
> > and a similar property for vertical parabolas based upon algebraic
> > difference in slope and length of vertical curve. Never bother the
> designer
> > with having to make tessellation sampling decisions - it should all be
> > transparent to him.
> >
> > sc
> > ----- Original Message -----
> > From: Dave Simeone
> > Newsgroups: autodesk.civil3d
> > Sent: Thursday, March 11, 2004 5:09 PM
> > Subject: Re: Civil3D 2005
> >
> >
> > Excellent feedback.
> >
> > Q - Historically we've generally "accepted" the tessalation of 3D
> vertical
> > curves (ie, break the geometry into short segments) when working from
a
> > grading feature line. I'm guessing that ya'll - (I'm trying to learn
to
> > speak in Wedding's language - I've got "Ya'll" and "All y'all" down
> pretty
> > nicely) - would like a smooth 3D spline. What is the requirement? The
> > smoother the better? Engineers go to great lengths to have accurate
> > vertical
> > (profile) geometry. I'm guessing that the true 3D geometry should be
> > carried
> > through the grading of the EOP, Kerb (how's that all y'all Aussies?),
> etc
> > geometry.
> >
> > Thanks
> > DAS
> >
> >
>
>