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]

From the help file, on "IntersectWith Method"

..."If the two objects do not intersect, no data is returned"

You should check to make sure the variant is not EMPTY before trying to get data out of it. Your code is CLOSE to the ample code, but you removed the line that did the error checking.

Place the following line directly in FRONT of line 10:

If VarType(intPoints) <> vbEmpty Then MsgBox "Your beat, kid..."

[Anonymous]

Yes, but each one of the lines WILL intersect one of the 16
3dFaces. It's drawn that way. When I step thru the code and
hover over the line:

intPoints = entTopLine.IntersectWith(entTopFace, acExtendThisEntity)

the intPoints popup says empty. Once the line is executed I no
longer get the popup help so I assume that one of the 3dFaces
does indeed reside in intPoints.

I put in that missing error checking line and there really is
something in there but when I hover over intPoints(2) in the
next line it still shows subscript out of range.

I tried changing the line

Dim intPoints As Variant

to

Dim intPoints(0 to 2) As Variant

but I got an error message for that too. So I'm confused as to
why the help code works and mine doesn't.

bc

[Anonymous]

One other thing I noticed. I put a couple of counters in for the
inner and outer For-Next loops. The outer loop correctly
cycles thru all 3600 objects in ssetObj1. The inner loop only
cycled thru 14 of the 18 items in ssetObj2. I don't know
what's up there. The object.count clearly shows 18 items in
the set but the for-next loop only sees 14.

I don't think this has anything to do with the subscript out of
range error though. Just another problem to be solved.

bc

[Anonymous]

This one is solved. There was a stray dot that got selected
which disrupted the count. Dot gone, counter problem gone.

Now only the main problem remains.

[Anonymous]

I tried a couple of things with your code, with no success. I tried a couple of things with new code, and geometry by me, with no success. Then I tried the sample code provided by acad - with No success!

I tried replacing typed entities with generic Objects, variants with double-prec arrays.. no success!

It may well be that yiou have a genuine bug here ... but there may well be a workaround ....

http://forums.augi.com/showthread.php?t=64537

[Anonymous]

I've been experimenting too with no success. I agree with the
guy in your link about the upper bound always being -1. As for
the rest I'm nowhere even close to understanding the math
they use. Not sure if I can find a workaround there or not.

I also agree with them that while this is easy to do from the
command line with the calculator function

ilp(end,end,cur,cur,cur)

it's a pretty poor showing that there's apparently no way to do
it from code.

As for the code in the help file it does work for me with the
line and circle. My next step is to add code to that for a 3dFace
and see what happens.

But I'll keep experimenting. Maybe someone else will come
along with a home-grown solution.

Thanks for the help.
bc

[Anonymous]

Can you post a sample layout of the geometry? It’s quite possible that the code from the other forum could be modified to work within the scope of your project.

[Anonymous]

Ok, here's my test file. You're looking at a side view. The blue
lines on top are the TopLines. The TopFaces are the blue
shapes in the middle AND the 2 red triangles in the midst of the
brown lines. There are 3600 blue lines and 16 faces.

bc

[Anonymous]

You’ve got a project with a fair bit of complexity there. Nevertheless, I think a similar process as posted on the Augi forum could work. All the TopLines oriented similarly will make the process easier. but, unlike the situation with the Augi post, 3DFace’s do not have a Normal property (unlike polylines), so that would need to be derived. A few other issues would require attention for a general routine, quite a few more for a routine optimized for speed.

On a different tact; if a volume calculation is the goal – would constructing a solid with the appropriate top facets be a better alternative? The volume extracted from the solid would conceivably be more accurate than that returned by the limited resolution of the 3600 samples.

[Anonymous]

>>All the TopLines oriented similarly will make the process easier. but, unlike the situation with the Augi post, 3DFace’s do not have a Normal property (unlike polylines), so that would need to be derived

First thing that comes to mind is dicing the face up into triangles, and getting your plane from that. Makes it a bit more possible, and a *lot* more messy

I wonder if there's anything available in the way of a vlax call (using the vba-callable module I see everywhere)...

is there anyone in this forum that 'goes both ways' (Vlax and VBA, I mean) ? 😛

[Anonymous]

Here is a down and dirty (i.e., in need of error checking, in code commenting, and optimization*) conversion. And even at that, it is only half completed so do not include the 2 Red triangles when selecting the faces. The routine should extend the lines down to the blue faces and give a tally of the running volume.

* With optimization not yet addressed, the routine is rather slow (10 – 20 seconds with modern PC). Have patience 🙂

[Anonymous]

Getting the Face's normal is fairly straight forward process (CrossProduct of two of it's sides). It's just that the other post didn't require it.

The “mod” I just posted has a couple of additional functions that were not in the original. When I get some more time I’ll comment it better.

[Anonymous]

Yup, a volume is what I'm after. The top facets don't matter
though. They are just one of my attempts at doing a poor
mans volume in acad.

Originally I tried to drop faces from a known height down
to whereever the bottom of the hole was underneath it. Then
I'd union them all together to get the volume. But I had the
same problem there as here - to drop a line to the surface.

Then I decided on another way. I'd take the volume of a
rectangular cube around the hole, subtract the volume that
wasn't a hole and I'd have my hole volume. (that's the method
I'm using here in this example)

Then I discovered (from someone's help here) the 'cal and the
ilp formula. It worked great from th ecommand line. So I
searched around in Help till I found the IntersectWith
command. It was just what I needed till I found out it didn't
actually work.

So now I'm back to square 1 again. Every time I think I'm close
to a solution, the genius at Acad rears up and slaps me down.

Granted, an easier and faster way to do this would be to just
take contour lines of whatever thickness desired and get an
approx volume that way. But once started I wanted to see if
I could actually do it this way. I don't know, something about
"you can't do that" makes me want to find a way to get around
a limit.

bc

[Anonymous]

The faces are triangles. It's just that the fourth point required
for the 3dFace is the same as the first point.

[Anonymous]

Ok I'll give it a try. And if I can figure out what your math is doing I'll comment along the way. Thanks.

bc

[Anonymous]

Well, for my first bit of playing with this new code it seems to
work great, although I have no way to check it. I tried adding
in the extra code to do the bottom lines to meet the bottom
faces.

When I ran the routine again the first part (for the top
lines) still was ok but the nextr part for the bottom crashed on
a Type mismatch error. I haven yet found where that's coming
from, still working on it.

But I have realized that those 2 red faces (and their coresponding opposites for the bottom lines) don't actually
need to be used.

By putting in a counter to count how many lines get extended,
that can be used to figure total volume of the space, then just
subtract the volume found by the top and bottom part of the
routine.

But fo rnow I have to find where the type mismatch error is
coming from.

bc

[Anonymous]

I think I 've got the whole thing working correctly. The type
mismatch error was due to a stray point being selected.

I've made things simpler also. Rather than using 2 sets of lines
I just re-use the first set. First drop them down to the top faces
to get the volume above the hole. Then drop them again to the
bottom and side faces of the hole to get that volume. Then
subtract the first from the second and voila, the volume of the
hole.

This example hole was actually a real one that I'd previously
used the stepped contour method to find an approx vol. The
volume from this routine was pretty close to that one so it
must be working correctly.

None of it would be possible though without the help from
all you great folks on here. Thanks much.

bc

[Anonymous]

Hi bceng,

3Dfaces are commonly drawn as triangles with the fourth point being
identical with another point, but that is not necessary and the four
point can be independent creating a pair of triangles with a fold axis
across one diagonal which only becomes obvious in a 3D view

Regards


Laurie Comerford

bceng wrote:
> The faces are triangles. It's just that the fourth point required
> for the 3dFace is the same as the first point.

[Anonymous]

It’s an interesting problem.

My first impression was that the methodology you were using would be needlessly expensive, computationally speaking. If I had to guess, a “stepped contour” methodology would be more efficient (faster) than the “dropped line” method, given an equal level of precision and code optimization.

Thinking about it further, however, I could imagine the Dropped Line method handling elevation “islands” more effectively. And, depending on what actually constitutes a “hole”, I suppose features such as overhangs may also come into play.

Let us know how you make out.