BRICSCAD v15 SLICE bug

christoph leipold

I do a lot of 3D work and find a problem to "SLICE" a 3D-Solid.

The drawing file comprises a "Panel-Wall" which cannot be sliced.
I have tried  along the 3-points of the polylines I have put there
and also if I try to slice within the xy-plane .

For comparison I have tried my old ACAD-2004 - worked well!! but not with my new BRICSCAD-15.

The command works well with BRICSCAD on the simple CUBE-solid also in the drawing but does not work on the "Panel-Wall".
So I think it is the more complicated structure of the "Panel-Wall" that causes the trouble - but this would not be acceptable for me.

I add the file in the attachment - I would be happy for help.

Scott McKenzie

I couldn't get it to slice either; to complete the task, I set the UCS to one of your white lines representing the roof profile and drew a huge rectangle and extruded it through the wall panel.  I then did a subtract and removed the huge cube from the walls.  It seems as though there is a bug of some sort, I would suggest sending in your drawing to the support team...

Alan Liddle

Yup, I couldn't get it to slice and I do a lot of slicing....

Jason Bourhill

Hi Christoph,

As already suggested it would be great if you could raise a support request on this. I've previously experienced this with V14 and thought it was resolved with V15, but clearly not.

A work around I found at the time was to copy the solid you want to slice into a new drawing, and slice it there. For some reason this seems to resolve the issue. Attach a new drawing with your solids copied across as an example.

Regards,

Jason Bourhill

CAD Concepts 

NewDrawingSliceSuccesful.dwg

christoph leipold

@Jason Bourhill:

Hi Christoph,

As already suggested it would be great if you could raise a support request on this. I've previously experienced this with V14 and thought it was resolved with V15, but clearly not.

A work around I found at the time was to copy the solid you want to slice into a new drawing, and slice it there. For some reason this seems to resolve the issue. Attach a new drawing with your solids copied across as an example.

Regards,

Jason Bourhill

CAD Concepts 

Hi Jason.
Thank you for your concern.

Interesting stuff: Now the slicing works - in every way (xy-plane / 3-points etc)
Could you tell, what you have done to the file?
I have tried to copy the original Panel-Wall "Copy with basepoint" and insert into a new drawing - but that did not change anything.

In the meantime I have sent a bug report to the support team - but I have no answer yet, i hope they will figure it out.

Jason Bourhill

Hi Christoph,

all I did was _COPYCLIP the solids on the problem drawing, then after starting a _NEW drawing used _PASTCLIP to get a copy of the solids. Sounds like you have done the same thing, but it didn't work. If you used your own template, then I would try starting a new drawing using one of the default templates instead.

Regards,

Jason Bourhill

CAD Concepts 

christoph leipold

Solution and explanation from Support team:

Codrut Dinca 26-02-2015 14:21 UTC

Dear Christoph,

When using CAD software, the space positioning of entities is important for the accuracy of computations.

The present issue is caused by space location (very large coordinates values) of the 3DSolid.

Moving the entities closer to the origin will solve the SLICE problem.

Kind regards,
Codrut Dinca

Best Regards,
The Bricsys Team

#############

I shifted the "Panel-Wall" to 0,0 - now it works as expected!

Within my drawing, the distance to 0,0 was about 3094811 units - in my case that is about 3,09km away from the building centre - that´s quite a lot

my conclusion: take a look for the 0,0 before starting to work )

Thank´s a lot to all of you - and to the Support Team !!

Best regards

Christoph Leipold

Scott McKenzie

 Interesting, back when I used to do civil drawings and work with surveys I noticed that large coordinates were causing an issue with commands like trim, fillet and extend.  Mind you this was a while ago, but after a bunch of research I discovered, if I remember correctly, that AutoCAD only stores a set number of digits (I think 16) for the x,y and z coordinates of entities, so having an an entity way off of the world coordinate system which is common in non truncated survey data can cause this.  What happens is near the origin, coordinates can be stored as, for example 13.9822363, 12.1825464, 123.254847 where as way off of the origin the data could only be stored as 13982236.3, 12182546.4, 123254847.  While the program was working properly it just didn't have the accuracy in the coordinates to perform certain operations.

Here is an article related to the subject that I just dug up: http://www.cadalyst.com/aec/tip-autocad039s-big-problem-5787

christoph leipold

@Scott McKenzie:

 Interesting, back when I used to do civil drawings and work with surveys I noticed that large coordinates were causing an issue with commands like trim, fillet and extend.  Mind you this was a while ago, but after a bunch of research I discovered, if I remember correctly, that AutoCAD only stores a set number of digits (I think 16) for the x,y and z coordinates of entities, so having an an entity way off of the world coordinate system which is common in non truncated survey data can cause this.  What happens is near the origin, coordinates can be stored as, for example 13.9822363, 12.1825464, 123.254847 where as way off of the origin the data could only be stored as 13982236.3, 12182546.4, 123254847.  While the program was working properly it just didn't have the accuracy in the coordinates to perform certain operations.

Here is an article related to the subject that I just dug up: http://www.cadalyst.com/aec/tip-autocad039s-big-problem-5787

Good read.
It says AUTOCAD calcualtes internally with 16 decimal digits i.e. 123,000,000,000,000 - if 1 digit = 1 mm this would be about 123 x10^6 km
In my case - "Panel-Wall" distance to 0,0 was about 3km so the remaining precision "reserve" would be about 9digits - this should be more than enough!(if I made no estimation mistake) and as tested: my old AUTOCAD-2004 had no problems with the 3km distance to the 0,0.

My question is: how many digits is Bricscad using for internal calculation?
If it´s only 8digits , the remaining precision at a distance of about 1km from 0,0  would be only 0.1mm ??
Does anyone know?

Torsten Moses

It is not a question of "how many digits is Bricscad using for internal calculation?" :-)
The precision is given by programming language (C++) and the "double" resp. "float" data type (which are also standadised for the compilers).

The "double" data type is based on IEEE64 standard 8-byte-floating point number, the FPU in modern CPUs uses up to 80 bit ("float" is IEEE32 standard 4-byte-floating point number) ...
In short, such geometric calculations are all 8-byte-floating point, with 16 digits - same as with AutoCAD.

Actually we introduced a kind of "dynamic tolerance" which adopts to the absolute position / size of objects - this means, at high coordinates, when less precision digits are available, we internally reduce our tolerance as well.
But as you described for SLICE, it might be possible, that the ACIS library by Spatial does not use such an approach - that would be rather bad :-(

You might reopen your support request, and ask for a more deeper analysis and potential fix at BricsCAD side.
Many greetings !

Jason Bourhill

Christoph,

I agree with Torsten on re-opening your support request. You have been provided a work around, it is an issue that should be considered for fixing. After all it worked on your Acad 2004.

Potentially a better work around would be to consider breaking up your model by the use of Xrefs. It would seem that you may be drawing at these coordinates to match Civil/Survey data. In this situation I would typically establish a site datum positioned at a known coordinate and angle on the Civil/Survey data. On your structural, mechanical drawings etc.. you would draw relative to the site datum, which you would position at 0,0,0. To show your information on the Civil/Survey drawings and vice versa, you would XREF the drawing into the other and position at the established datum point.

Regards,

Jason Bourhill

CAD Concepts 

christoph leipold

@Jason Bourhill:

Christoph,

I agree with Torsten on re-opening your support request. You have been provided a work around, it is an issue that should be considered for fixing. After all it worked on your Acad 2004.

Potentially a better work around would be to consider breaking up your model by the use of Xrefs. It would seem that you may be drawing at these coordinates to match Civil/Survey data. In this situation I would typically establish a site datum positioned at a known coordinate and angle on the Civil/Survey data. On your structural, mechanical drawings etc.. you would draw relative to the site datum, which you would position at 0,0,0. To show your information on the Civil/Survey drawings and vice versa, you would XREF the drawing into the other and position at the established datum point.

Regards,

Jason Bourhill

CAD Concepts 

Jason.
You are right if I had to use civil survey date - but i don´t .
It is just a flaw of disorder, to not set the startpoint of our building to 0,0.
My concern is: where are the limits for my building dimension in this case (my drawing units are mm - so if I used 10^6 drawing units I would be at 1000m - maybe a very large storage hall - or two of it (I already had one of about 500m) .
So I did a test: my "Panel-Wall" against 1000m Distance!
It worked! But, at 1001m it didn´t although this does not concern the absolute distance ( I moved it for 100m along the Y-line and it still worked) but as soon as one of the coordinates goes across the 1000m line it´s over. (The simple solids still work)
Again: with ACAD-2004 no problem - even at 1100m.

I attach my test drawing: the red ones did not work for me
I agree with the support request, as this problem might hit me in the future.

Best regards
Christoph Leipold

Test-KAPPEN-2004.dwg