why subscript out of range error?

[Anonymous]

I'm having trouble with the following code. In line 10 I get
a 'Subscript out of range' error on intPoints(2). I followed the
IntersectWith code example in the help file but don't see
where mine should operate any different than theirs.

They dimmed intPoints as Variant and so did I. They then extracted
point info from the variable (intPoints(j)) and so did I (intPoints(2)).

Yet I get the error. And the variable LinLen always remains empty.

What am I doing wrong?
bc


Sub Intersect()


'This code is supposed to find the intersection point between
'a line and a 3dFace, check the length of the line stretched
'to that point then find an area based on that length.
Dim msg As String

Dim ssetObj1 As AcadSelectionSet
Dim ssetObj2 As AcadSelectionSet

Set ssetObj1 = ThisDrawing.SelectionSets.Add("TopLines")
Set ssetObj2 = ThisDrawing.SelectionSets.Add("TopFaces")

'the following selections are made en masse, ie not in any particular order
'there are approx. 3600 lines and 16 3dFaces
msg = MsgBox("Select on screen all the TOP lines.", vbOKOnly)
ssetObj1.SelectOnScreen
msg = MsgBox("Select on screen all the TOP faces.", vbOKOnly)
ssetObj2.SelectOnScreen

Dim LinLen As Variant
Dim intPoints As Variant
Dim TopArea As Variant
Dim Area As Variant
Dim entTopLine As AcadLine
Dim entTopFace As Acad3DFace

'each of the 3600 lines are tested for intersection with a 3dFace
For Each entTopLine In ssetObj1

'the 3dFaces are cycled thru to check for intersection with line
For Each entTopFace In ssetObj2
On Error Resume Next
intPoints = entTopLine.IntersectWith(entTopFace, acExtendThisEntity)
10 LinLen = intPoints(2) - 10 'error occurs here
Area = LinLen * 0.25
TopArea = TopArea + Area
Next
Next
ssetObj1.Delete
ssetObj2.Delete

End Sub

[Anonymous]

Right, but triangles work best. I don't think ilp will work with a
surface that's not flat like a 4-point folded surface.

bc

[Anonymous]

I agree that the stepped contour method would seem to be
faster and better, but only for simple holes like my example.
But for complicated holes with, as you say, elevation islands,
things get more interesting.

I did a really big test yesterday afternoon. We had another
excavation a while back. It had a number of elevation islands.
The setup time to get everything ready for the macro ~1.5hrs.
Get this, my Toplines selection set had 151,365 lines in it. The
Topfaces set had 260 3dFaces. It took approx 1 hour 40 minutes
to run and a total of 143,526 lines were dropped.

The answers I got didn't seem correct. It said 463,007 cu.ft. or
iow 17,148 yds. That seemed like an awfully large volume. But
after doing some actual measurements of the hole on the
drawing and figuring roughly from that I suppose it could be
correct.

I was using lines spaced 6" apart in a square array. That's
where the 0.25 came from to multiply the line length by.
Seemed like that would be a fine enough resolution for good accuracy.
And to do the same with stepped contour I think the times
might be comparable.

So it looks like this could be another poor mans way of finding
volumes in plain jane acad 2007. And most of the credit should go to you
since it was your code. And to think, you said the code was
only half finished. Well it sure worked good enough for me. Thanks.

bc

[Anonymous]

Oh one thing I forgot to ask.

Before I went to this top down only method and I was still
dropping lines down AND shooting lines up fro the bottom
half, it wouldn't work. This could have been because of that
stray dot I mentioned in a previous msg.

But since I'm now thinking about it does your code handle
lines going up? I mean I know your code uses vectors so
if I'm trying to shoot a line upwards aren't the signs reversed?
Will that cause it to crash or doesn't it matter? I don't know
much about vector math so just curious.

bc

[Anonymous]

The routine would work in a similar fashion for lines below, projected upwards. In that light, however, an aspect to be aware of is that the routine as posted modifies the endpoint of the line (as opposed to the startpoint). The ramification is that if the “BottomLines” had a startpoint above the endpoint, the routine would backtrack, and the original length of the line would be eliminated.

That type of quirk leads me to believe you’d be better off removing the need for any preliminary geometry. Via code, acquire a size parameter from the Face’s Bounding Box. A For Next loop could create a 2d array (virtual, not an AutoCAD array) with the necessary resolution and positions. You may not even need to use LINE entities, just use the displacements along with the positions to perform the volume calculation. That alone would speed up the code.

Further on the optimization bent, each For Next face loop could isolate only the positions that fall within it’s own Bounding Box and avoid the others.

I imagine such a routine could process the 151,365 “positions” and 260 3dFaces several hundred times faster than the original code.

[Anonymous]

I agree that an actual line isn't necessary, just the point of intersection. And if the routine didn't have to
cycle through all the faces every time either so much the better. But I don't understand your code at all,
let alone to do those things.

Two things I did notice about the way it runs at present. One, if the line will fall almost exactly on the
intersection of a face, it will not drop at all and therefore does not contribute to the volume. Fortunately
this doesn't seem to happen too often. Don't know how to fix that.

The other thing is that for some reason some of the lines get used twice, thereby contributing twice
their volume. I did a test where I knew the number of lines present (2892) and after the test saw that
2900 lines had been dropped. (Isn't this like free money 🙂 ) So I put in an If-Then test to test for
beginning length before getting the intersection point info to calculate length going into the final volume
calc routine. That seems to have taken care of that problem.

bc

What a royal pain in the neck it was trying to get back onto the forum after this restructure. It wouldn't
even let me use my ID, said it was already in use. Yea, by me! Had to add a number to the end.
Sheesh! 😞