Author Topic: Circle Norm  (Read 10962 times)

0 Members and 1 Guest are viewing this topic.

Bryco

  • Water Moccasin
  • Posts: 1882
Re: Circle Norm
« Reply #15 on: January 02, 2008, 10:10:18 PM »
Mick, I am wondering if you are trying to transform an ent by an identity matrix, perhaps you want to use the inverse matrix

MickD

  • King Gator
  • Posts: 3619
  • (x-in)->[process]->(y-out) ... simples!
Re: Circle Norm
« Reply #16 on: January 02, 2008, 10:23:56 PM »
It's a bit more difficult than that and what SEANT warned about is the culprit I'm sure.
I'm saving whatever ucs that's current, setting it to world and creating a 3d solid. This gives me a section in wcs ready to transform to wherever I need. I then set it (the ucs) back to where it was and then move the object into position, in this case I create a matrix from a line and it's normal then transform the 3d solid to the line. I'll sort that axis/normal conflict out and see how it goes.
thanks.
"Short cuts make long delays,' argued Pippin.”
J.R.R. Tolkien

Bryco

  • Water Moccasin
  • Posts: 1882
Re: Circle Norm
« Reply #17 on: January 02, 2008, 10:40:36 PM »
Mick, is this true-> a circle's normal always works, a line's normal sometimes

MickD

  • King Gator
  • Posts: 3619
  • (x-in)->[process]->(y-out) ... simples!
Re: Circle Norm
« Reply #18 on: January 02, 2008, 10:48:59 PM »
I'd say so, only because a circle (or a polygon for that matter) is planar and it has a proper normal, a line is not and afaik the lines normal is only usefull in determining what ucs it was drawn in - ie. its ucs z vector.
This doesn't mean the line's 'normal' will be perp to the line  (as you might expect) which is a bit of a pita but that's what I need to check for and work around. For example, say you're in world and the user draws a line form 0,0,0 to 0,0,10 , the line's normal would be 0,0,1 but so is the ucs and the direction of the line.
"Short cuts make long delays,' argued Pippin.”
J.R.R. Tolkien

Bryco

  • Water Moccasin
  • Posts: 1882
Re: Circle Norm
« Reply #19 on: January 03, 2008, 12:42:18 AM »
So using the vector of the line is good instead of the lame line normal

Bryco

  • Water Moccasin
  • Posts: 1882
Re: Circle Norm
« Reply #20 on: January 03, 2008, 12:50:10 AM »
This may be what you want, feed it the line vector and it will give you the x and y axis
Code: [Select]
Function GetOcsFromNormal(N As Variant) As Variant
    'N is the normal vector.
    'Wy is the world Y axis, which is always (0,1,0).
    'Wz is the world Z axis, which is always (0,0,1).
    Dim Wy(2) As Double
    Dim Wz(2) As Double
    Dim Nx As Double, Ny As Double
    Dim Ax, Ay, ocs(1) As Variant
   
    N = NormaliseVector(N)
    Wy(0) = 0: Wy(1) = 1: Wy(2) = 0
    Wz(0) = 0: Wz(1) = 0: Wz(2) = 1
    Nx = N(0): Ny = N(1)
    If (Abs(Nx) < 1 / 64) And (Abs(Ny) < 1 / 64) Then
         'Ax = Wy X N (where “X” is the cross-product operator).
         Ax = Crossproduct(Wy, N)
    Else
         Ax = Crossproduct(Wz, N)
    End If
    ocs(0) = Ax
 
    Ay = Crossproduct(N, Ax)
    ocs(1) = Ay
    GetOcsFromNormal = ocs

End Function

MickD

  • King Gator
  • Posts: 3619
  • (x-in)->[process]->(y-out) ... simples!
Re: Circle Norm
« Reply #21 on: January 03, 2008, 12:54:42 AM »
Yep, then you need to create the other axes from somewhere else, either use the current ucs x & y or the line normal and cross them all to make the matrix orthogonal depending on what you want. I usually use the line and it's normal to create the first 2 axes then cross them for the third making sure to normalise them on the way.

[edit] I already wrote the above before seeing your last post so I'll leave it.
The only reason I use the line normal is so I get the rotation of the 3d section somewhat how I want it, what you have there is what I mention above, I'll give that a go as it may suffice for what I need.
thanks.
"Short cuts make long delays,' argued Pippin.”
J.R.R. Tolkien

SEANT

  • Bull Frog
  • Posts: 345
Re: Circle Norm
« Reply #22 on: January 03, 2008, 04:53:15 AM »
I’m interested in the direction of this (and http://www.theswamp.org/index.php?topic=20389.0) thread. 

I’d assume that this stage, the orientation of the profile (Roll axis of solid), is the most subject to complication.  Not an issue with circles (reference to this thread's title), obviously, but certainly for profiles of considerably fewer axes of symmetry. 

Is runtime user interaction the game plan?  If not that: Would the best, perhaps only, way to automate an angle iron construction, for example, be with a data imbued wireframe?  If that were true, it would certainly increase the scope of the project.     



. . .for the life of me know why they didn't implement more geometry classes in vba, particularly the matrix. Oh well...

An ill advised marketing scheme, I believe.  Just about all the geometry classes one could ever hope for are available to VBA with Mechanical and MDT via the GeAUTO and BrepAUTO dlls.   
Sean Tessier
AutoCAD 2016 Mechanical

Bryco

  • Water Moccasin
  • Posts: 1882
Re: Circle Norm
« Reply #23 on: January 03, 2008, 10:08:52 AM »
Mick, I added
Code: [Select]
   [font=Verdana]Dim ucs As AcadUCS
Set ucs = GetActiveUcs
SetOrthoUCS[/font]

ptInsert(0) = 0: ptInsert(1) = 0: ptInsert(2) = 0
  If IsEmpty(ptInsert) Or Err.Number <> 0 Then Exit Sub
  If ThisDrawing.Blocks.Item(DWGName) Is Nothing Then
    Set objBlockRef = ThisDrawing.ModelSpace.InsertBlock(ptInsert, _
      DWGPath & "\" & DWGName & ".dwg", 1#, 1#, 1#, 0#)
  Else
    Set objBlockRef = ThisDrawing.ModelSpace.InsertBlock(ptInsert, _
      DWGName, 1#, 1#, 1#, 0#)
  End If
  objBlockExplode = objBlockRef.Explode
  objBlockRef.Delete
  For lCounter = LBound(objBlockExplode) To UBound(objBlockExplode)
    If objBlockExplode(lCounter).ObjectName = "AcDbPolyline" Then
      Set objRegEnt(0) = objBlockExplode(lCounter)
      objRegion = ThisDrawing.ModelSpace.AddRegion(objRegEnt)
      Exit For
    End If
  Next lCounter
 
 
  Set objBeam = ThisDrawing.ModelSpace.AddExtrudedSolid(objRegion(0), height, 0)
  objRegion(0).Delete
  objRegEnt(0).Delete
 
 [font=Verdana] objBeam.TransformBy (ThisDrawing.ActiveUCS.GetUCSMatrix)
ThisDrawing.ActiveUCS = ucs[/font]
and it always seemed to work, can you post a dwg where it doesn't?

MickD

  • King Gator
  • Posts: 3619
  • (x-in)->[process]->(y-out) ... simples!
Re: Circle Norm
« Reply #24 on: January 03, 2008, 04:29:17 PM »
Hi Bryco, that will work as long as I only want to rotate it to the current ucs, my problem is rotating it to a user picked line (as Sean mentioned). I think the problem is the ucs/line/normal thing and I'll work on it today.

Hi Sean, yes, as you say I would like to use some wire frame geometry as a base for adding sections to. If these were drawn correctly (in the correct ucs to give the correct orientation on insert) the sections come out as expected. With this project it's not so important as I can ask the user for an optional rotate after insertion before ending the command say.

I have already done this in C# some time ago and it was a lot easier given the geometry classes available, that was a pretty complicated project and I want to steer away from that for the moment and make it as simple as possible.
Just simple tools that can later be used to automate easily/quickly as required for your circumstances or discipline. Automation of tasks can come as required once the tools are in place but what I don't want is an 'application' per se that ends up requiring a lot of time to learn it's 'tricks', it can be used just as tools or you can create/use specialised 'routines' that don't required any special requirements prior to use if that makes sense.

If anyones interested I'll start another thread and add the module as an OS project, I have to warn you though it's pretty rough, but it works most of the time :)
"Short cuts make long delays,' argued Pippin.”
J.R.R. Tolkien

Bryco

  • Water Moccasin
  • Posts: 1882
Re: Circle Norm
« Reply #25 on: January 03, 2008, 05:27:52 PM »
I couldn't break it on a user picked line. (which is different than a user picking 2 points)

MickD

  • King Gator
  • Posts: 3619
  • (x-in)->[process]->(y-out) ... simples!
Re: Circle Norm
« Reply #26 on: January 03, 2008, 05:49:48 PM »
I couldn't break it on a user picked line. (which is different than a user picking 2 points)

I haven't had a chance to try it yet and probably won't get a chance today, here's some linework I've been using. Try setting the ucs to different ortho's or on the objects etc.
"Short cuts make long delays,' argued Pippin.”
J.R.R. Tolkien

MickD

  • King Gator
  • Posts: 3619
  • (x-in)->[process]->(y-out) ... simples!
Re: Circle Norm
« Reply #27 on: January 03, 2008, 09:13:32 PM »
That worked a treat Bryco! I haven't had time to study what's happening yet, I just copied and pasted it in to test and it works well, time to put it to test in the production environment.
thanks!
"Short cuts make long delays,' argued Pippin.”
J.R.R. Tolkien

SEANT

  • Bull Frog
  • Posts: 345
Re: Circle Norm
« Reply #28 on: January 04, 2008, 06:51:54 PM »
Bryco - clever use of the AA algorithm.  That certainly reduces the guesswork from the profiles final orientation.  With an additional objRegion.Rotate -  given Nx < 1/64 and Ny < 1/64 - the profile could be constrained to a very predictable orientation.  Compare the Red and Blue lines in the attached file as demo.

Mick – Is the order of operation which you employ important to your workflow?  By that I mean:  Could you orient the profile before generating the solid extrusion?  This may allow the possibility of solids other than straight lines via AddExtrudedSolidAlongPath.  Arcs would certainly be cool and Polys would offer automatic mitering.
Sean Tessier
AutoCAD 2016 Mechanical

Bryco

  • Water Moccasin
  • Posts: 1882
Re: Circle Norm
« Reply #29 on: January 04, 2008, 08:05:02 PM »
Thanks Sean but I virtually copied it from Arbitrary Axis Algorithm found in the dxf reference help.
It has a great explanation in there as well.
I use that more than a ucs as I'm used to it, and it's better for plines.
The use of it did'nt always give me the xaxis I wanted on solids though so there is still a little mystery there.
I'm not quite sure what the drawing is explaining, I see the blue is just out of range.
I guess it's pretty important for Mick's kind of extruding, but I'm not quite sure what you would do with the info