Also, if you split a bezier .. it too becomes a control point spline

I can see no logic here at all - surely here it would be easy peasy to retain spline type !?

It's the same with the offset tool

(I don't get why we need to change this object type as the nature of the offset curve will be very similar to the original)

What I REALLY NEED is an offset curve with a similar number of points as the original (and ideally placed similarly)

I can't tweak these control point splines reliably with so many points

First rule of surfacing :

ALWAYS USE THE MINIMUM NUMBER OF POINTS THAT CAN DESCRIBE YOUR SHAPE ACCURATELY

I do zero surfacing in VC so bear with me here.....why cant you use control point curves when making a network surface, I do it all the time in Rhino ?

If you choose to delve into nurb detail Rhino is full of it....it's built on it. Curves and their data are shown differently to VC, I mean VC does not show you all technical data such as curve degree, knots etc

To answer your question, if I draw an Int. curve in Rhino it is the same as a CP curve, same degree (unless is choose otherwise) BUT it always has a higher node/cv count and in most cases has non-uniform knots as opposed to a CP curve which are uniform. (unless they are straight line curves ;). I see no big changes in the curve if I split the curve in Rhino....HTH

In VC when you draw a Int. curve it shows the "edit points" or knot averages whereas if you draw an CP curve it shows the control points. In Rhino showing the points displays the control points no matter what curve it is.

From Google [URL="http://www.cl.cam.ac.uk/teaching/2000/AGraphHCI/SMEG/node4.html"]http://www.cl.cam.ac.uk/teaching/2000/AGraphHCI/SMEG/node4.html[/URL]

Maybe Tim can explain why we have all this conversion facility...even the ability to convert an Int. spline TO and Int. spline :confused:....maybe this can be streamlined a little if the users understood why it is in place ?

Greetings,

Not at all, in fact quite the opposite accurate & smooth.

I have never tried building surfaces with overlapping curves, I generally setup my curves so that they are correct for the surface I require....this can take time but then you knowing the saying - "shit in & shit out"

Editing curves in Rhino have history like VC therefore editing is a wizzzz;)

In your image you show the middle curve to have 'tangency'...what are they tangent with here...im trying to understand your point JOL.

Ohhh 2 surfaces....okay, are they split with the curve going across then, did VC match the surfaces in the network surf command ?



Note me, nor do I profess too. In my previous post I mentioned I had zero knowledge of surfacing in VC therefore my comments were to do with Rhino. Im trying to see if anything can be learned and implicated into VC to help..but never mind eh .......I see my efforts are wasted here:rolleyes:

Hi NickB,

Are you talking about VC or Shark here - can you post any examples ?. Im not sure why you have problems when exploding edges to curves unless the geometry is "complex" to start with :cool:

Dear Jol,

I think it is perfectly normal (in any system) to experience a more complex and higher point count when Offsetting a spline ?? The accuracy of the system is mostly responsible for this taking place as well as the curvature of the input geometry.....so how do you think this can be improved then ??

Joining splines doesn't seem to increase complexity of the final curve over here, what steps do I need to avoid then ??

Most people assume there surfaces are simple whilst working in VC or Shark but if fact they are quite complex, this is due to the surface isocurves not being shown by default. There is a facility to show more isoparms but IMHO this is not consistent and correct...for example the true edit points on a spline are not consistent with an extrusion when you display isolines, this should be so when density is set=1 - Any comments Tim ?

I'm not convinced there is a major problem as you & NickB describe which is why I asked "NickB" for an example....perhaps no coment from Tim is another clue.....

Nick,

No, im not saying that, I was answering Jol's comments about offsetting geometry & joining curves etc....because I know this from previous experience with VC and other Cad programs.

I cannot make out what your part is used for but it does look fairly complex. You say the exploded curves are "unusable", I think posting them is the only way people here or development can fix the problem or offer up suggestions :)

My comment would be to use a straight blend/fillet rather than an elliptical one, this would benefit any possible machining process' and will certainly make the model simpler for further operations such as this...That said I certainly see your point which is why I think posting actual problems IS the only way to get anything done...sometimes:p
(attached image as example of underlying geometry, showing points)

FYI: I am interested to know all the short comings (if any) of this product before we further invest in Shark...

All our splines at the lowest level are treated as NURB's. ACIS is a NURB/Analytic geometry kernel where the native definition of a spline is a NURB. A NURB is defined by control points (control vertices) plus some additional info (knots, weights, etc). Control points do not necessarily lie on the curve as part of the NURB definition.

An interpolated spline takes a collection of points that lie on the curve and fits to a tolerance a set of control points to the data. Note that control points and interpolated points are not the same thing. Many people like to work with interpolated splines since the edit points lie on the curve they are tweaking. When we make an interpolated spline, we retain the original user points and rebuild the control point spline everytime a interpolated point is manipulated.

Whenever an operation is performed on a spline (interpolated or bezier) such as a trim, break, offset, the resulting form is the most accurate definition, which is a control point spline.

I'm not aware of an ACIS procedure to recalcuate the associated edit/interpolated points from a general NURB. Will need to research further.

Tim

Hi Jol,

Very Good example. Can I be nosy and ask why are you joining these curves together if they already touch?

I feel this highlights the fact that the join command is not a good tool at all and not much use for accurate modeling, I never use it and took a dislike to it from the very start. Why would anyone want the join command two curves like this anyway...I mean with a blend when these tools are already at your disposal. IMO joining two curves with G0/G1 cont. should not effect the structure or density of the curve, it should just modify a few cv's here and there - Tim ?