The range for a rotated cell seems to be wrong.
The magenta box is the returned one. The handles are from the "element selection" tool. The handles are correct, so the cell range is correct but
the returned value from "element.range" is not.
Any ideas what alternative could give me the correct result ?
Jens, if the handles are correct and the box is showing the range, what should be wrong with it ? The range is (afaik) representing the minimum and maximum x,y,z coordinate of the element, the range is always a cube aligned to x,y,z axis of the drawing.
I would expect the values to be in "local" coordinates of the element (left example) not aligned to the drawing coordinates (right example). Otherwise they are pretty useless.
A rotation would not solve the problem because the "diagonal values" are obvious different.
Micheal is correct, the element range and the handle location are un-related things.
Cells do store a "range diagonal" in addition to the element range, which is what mdlCell_extract uses to return the 8 corners of bounding shape. This *can* give you a fitted box around the cell geometry.
The cell handles don't use the shape points from mdlCell_extract for 2 reasons:
1) Applications that create cells don't always set it correctly.
2) It's expanded to a whole uor value, so using these corner locations to apply a scale to the element would be inaccurate.
HTH
-B
Unknown said:Otherwise they are pretty useless
Usefullness, or its absence, depends on what you want to do with the element range.
The primary use of element range is in a spatial scan. You can choose or reject an element by comparing its range with some set of coordinates. That check is fast compared to getting the geometry of an element and performing computational geometric algebra. The check is independent of how you might be seeing the element in one of eight rotated views.
Regards, Jon Summers LA Solutions
OK
Following your advice i tried mdl Cell_extract, but the wrapper for that might be a tough one to set.
In the mdl documentation the wrapper should look like this :
Declare Function mdlCell_extract Lib "stdmdlbltin.dll" (
ByRef origin As Point3d ,
ByRef shape As Point3d ,
ByRef rMatrix As Matrix3d ,
ByRef scale As Point3d ,
ByVal cellName As Long ,
ByVal bufferSize As Long ,
ByVal cell As Long ) As Long
In C# it should be :
[DllImport("stdmdlbltin.dll")] public static extern int mdlCell_extract(
ref BIM.Point3d origin,
ref BIM.Point3d shapePoints,
ref BIM.Matrix3d rMatrix,
ref BIM.Point3d scale,
int cellName,
int bufferSize,
int cell);
But two Problems with that.
1:)
What is "cell" ?
In mdl it is a MSElementCP cell
for example &elmD->el
Is it that one ?
[DllImport("stdmdlaccessor.dll")] public static extern int ElmdscrAccessor_getMSElement(int ElementDescr);
2.)
shape is in fact an array of 8 Points.
So it should be
ref BIM.Point3d[] shapePoints,
...
Crashes and Crashes
I think another episode of "don't fiddle around with pointers and pointers to structures and pointers to undead bodies" :-)
Unknown said:Following your advice I tried mdlCell_extract …
I don't see that advice on this thread!
This is the declaration for VBA …
Declare Function mdlCell_extract Lib "stdmdlbltin.dll" ( _ ByRef origin As Point3d , _ ByRef shape As Point3d , _ ByRef rMatrix As Matrix3d , _ ByRef scale As Point3d , _ ByVal cellName As Long , _ ByVal bufferSize As Long , _ ByVal cell As Long ) As Long
This is the declaration for .NET …
Declare Function mdlCell_extract Lib "stdmdlbltin.dll" ( _ ref origin As Point3d , _ ref shape As Point3d , _ ref rMatrix As Matrix3d , _ ref scale As Point3d , _ cellName As Int , _ bufferSize As Int , _ cell As Int ) As Int
The last three parameters have to be changed, because a 32-bit Long in VBA is a 32-bit Int in .NET languages …
VBA doesn't provide an MSElement*, so you must convert a VBA Element using the convertor DLL you mention …
Use it like this …
Dim oCell As CellElement ... get oCell from somewhere Dim elementPtr As Int32 ' .NET elementPtr = ElmdscrAccessor_getMSElement (oCell.MdlElementDescrP) mdlCell_extract ..., ..., ..., ..., ..., ..., elementPtr
Unknown said:I think another episode of "don't fiddle around with pointers and pointers to structures and pointers to undead bodies"
You're right to be cautious. However, in this case you're not allocating or deallocating memory. Rather, you're passing around a pointer like any other piece of data.
Problems here are likely caused by the shape array. In MDL, an array is passed as if it were a pointer, but that's not the case in VBA or .NET. You may need to pass your array like this …
Dim oCell As CellElement ... get oCell from somewhere Dim elementPtr As Int32 ' .NET elementPtr = ElmdscrAccessor_getMSElement (oCell.MdlElementDescrP) Dim shape(0 To 7) As Point3d mdlCell_extract ..., shape (0), ..., ..., ..., ..., elementPtr
To avoid problems arising due to language differences between VBA and .NET, I suggest that you write a prototype in VBA. Once you have mdlCell_extract working corrrectly with VBA, then you can port to .NET and tackle those languistic conundrums.
Answer Verified By: JensS
Thanks Jon for your detailed answer.
I have it up and running.
That was the "silver bullet" :
Dim shape(0 To 7) As Point3dmdlCell_extract ..., shape (0), ..., ..., ..., ..., elementPtr
Thanks a lot for your help.