Why can this 3dFace not be extruded

[j.palmeL29YX]

In the attached dwg you see four 3DFaces. Three of them can I extrude, the fourth (red) is always removed from the selection set of the extrude command. 

Why I can not extrude (and also not revolve or sweep or other 3D operations) this object. 

In >>this video<< you can see what I did. Be aware: if I move this 3DFace a little, then it can be extruded (and other operations too). 

What is wrong with this object, what can I do to avoid this behavior?

Additional information: This 3dFace is one of thousands of 3DFaces, which I want to extrude. some of them (seemingly randomly, I can't find any "rules") show the same behavior. (Tested in ACAD 2020 and 2021). 

Does anyone have an idea how to solve the problem? 

[Patchy]

Try UCS, select using OB, then Extrude, will it work?

[R_Tweed]

It must be a random issue. I'm using Arch 2020 and I did not get the same result. screencast   Maybe upload more faces in another file? 

.

[j.palmeL29YX]

In the attached example i have 7691 3DFaces, 457 of them are rejected. 

Here a snip from the text window: 

Command: EXTRUDE

Current wire frame density: ISOLINES=8, Closed profiles creation mode = Solid

Select objects to extrude or [MOde]: Specify opposite corner: 7691 found

Select objects to extrude or [MOde]:

457 objects removed from selection set.

Specify height of extrusion or [Direction/Path/Taper angle/Expression]: *Cancel*

[j.palmeL29YX]

>>Here<< a video what I tried to solve the problem (first read the following text): 

- Given is a bunch of 3DFaces

- Extrude as much as possible, Some of the Faces are removed from the selection set (and I/we don't yet know why)

- Move the remaining (the not extruded) faces away and try a new Extrusion. Again some of the faces are removed from the selection set

- Repeat this until all Faces are extruded (it is not necessary to watch all these repetitions in the video. you can jump to about 12 min)

- Now (I hoped) we can move all 3DSolids back to their initial position, union all the 3Dsolids to one solid or do whatever we want to do with them.  

But: 

At the end (in the video at about 12 min) remain 3 faces which don't want to extrude. I moved this faces twice without success. Maybe if I move the faces to another position it will work, or even not. 

Fazit: This way needs a lot of work, and the success is not guaranteed - we have to find the reason why some faces can not be included in the selection set of a 3D-operation and solve this case. 

I hope someone can help ...  

[j.palmeL29YX]

Small correction: jump in the video to 11 min if you want to see what fails at the end. 

[leeminardi]

I am aware that some CAD systems organize data into groups (not to be confused with the meaning of "group" in AutoCAD) that identify the minimum box that contains the data in that group.  Other entity information may also be kept.  When the database is searched for what objects should be considered in an operation that database  group summary (we called it sector headers) would be examined firsts to see if any of the data in that that group should be considered in the current operation (e.g., select, move, etc.).  Having the software scan these sector headers enabled faster processing than if the extents of each individual entity were examined in the database search process. 

I think that AutoCAD may use a similar scheme and there is a minor database error in the sector header that is causing the problem.   I found that moving or copying the faces in your file may solve the problem as it forces the update of header information.  I had better success opening a blank drawing and then using insert with explode to enable the use of extrude on all 7691 faces of your extrusion_fail drawing to extrude them.  I believe that the insert operation causes AutoCAD to update the database bookkeeping and fix such errors.  Note, this is only a guess but it may work!

[leeminardi]

I should add to my last post that I first suspected that the direction of the face normal could be the cause of the problem The direction of the face normal is not explicitly included in the database data for a face.  Instead, it is implied by the order of the face's vertices. Right-hand-rule is used to determine the normal direction.  All 4 of the faces in your test_error  file were consistent in defining the order of vertices. This, led me to believe that the problem was not with the individual face but at a higher level. 

[j.palmeL29YX]

Thank you for your detailed explanation. 

Inserting the test-file in a new file (incl. exploding) has no effect here. The same number of 3DFaces (about 470) are not added to the selection set. 

But if I copy the 3DFaces (Ctrl+C) and paste in a new drawing (Ctrl+V) then the number of removed object is only 7. In this current case it reduces the effort to repair it, but of course the main problem is not solved. In the next example file I can experience a nasty surprise again. 

And my first example file with only four 3DFaces makes me think that we are not yet on the right (solution) path. 

(BTW: I also suspected the Normal direction of the Faces as the cause of the problem and checked it. Has not been confirmed). 

Nevertheless thank you for your answers. 

[R_Tweed]

This is interesting. I was thinking that normals might have something do with it as @leeminardi  mentioned.   I was able to do it in one shot again consistently with the larger set although it took some time to process.  I wonder if it's related to cpu as your processing quite a bit faster than me. It took me a couple of minutes to extrude the selection set but everything was extruded. see screencast   I have dual Intel xeon e5-2623 v3 bought back in 2015 if it means anything.

[j.palmeL29YX]

---

@R_Tweed wrote:

I was able to do it in one shot again consistently with the larger set 

---

Then you can feel happy. 

I've had the same thought that the CPU may have some influence and tested on different computers. 

My current Laptop: 

Intel(R) Core(TM) i7-9750H CPU  @ 2.60 GHz

- 457 objects removed from selection set

another:

Intel(R) Core(TM) i5-4200M CPU 2.50 GHz

-> exact the same, 457 objects removed 

still another (ACAD 2013): 

Intel(R) Core(TM) 2 Duo CPU T9900  @ 3.06 GHz

-> 93 objects removed. 

It stays annoying ...

BTW: don't worry about the calculation time. In the video I snipped some ranges while nothing happened (to reduce the duration of the video). Sorry for the confusion. 

[leeminardi]

I think I have a handle of what the problem is!   The database definition of a 3DFACE includes the x,y,z coordinates for 4 points that defines the 3dface. If only 3 points are used to define a 3dface then the 4th vertex is automatically assigned the same coordinates of the 3rd.  I think the problem with the extrude command rejecting a 3dface has to do with it looking at the equality of the 3rd and 4th vertex.  If it determines that they are not exactly the same the face is rejected.

In your test_error file the problem face is selected and the properties panel shows the x,y,z coordinates of vertex 3 to 8 decimal places for a total of 15 significant figures, the approximate limit to AutoCAD precision.

Vertex 4 shows the exact same values.

However, if the precision of the 3rd and 4th vertex of the face is reduced to 4 decimal places for example.

The face will successfully  extrude!

Try the following, create a 3dface with a 4th vertex out of plane with the other 3.  You will find it "removed" when trying to extrude it.

Moving faces or rotating them may modify their coordinates sufficiently to make the 3rd and 4th vertices identical enough to pass the extrusion command's requirements but then again it may not.

The bug is with the extrude command and how it compares the 3rd and 4th vertex.  Autodesk would need to fix this in a future release.  In the meantime it may be possible to write a vlisp program that makes the 3rd and 4th vertices "more" identical by rounding down to a lower precision.  Alternatively, it may help just to move all the faces so that they are approximately centered about 0,0,0 WCS.  This would yield higher decimal place precision although the absolute precision of the database would remain at 15 significant digits.

[leeminardi]

On further thought and testing there are two factors that may cause a 3dface to be removed from a selection set for the extrude command.

1.  The 3rd and 4th vertex do not pass the test for being at the same location.

2. The 4th vertex is not sufficiently on the same plane defined by the other 3 vertices.

Try the following. Create a 4 vertex 3dface on the xy plane where none of the vertices are coincident.  Extrude will be successful.  Now move the face far (1000000 units in x,y z) from 0,0,0 and rotate it to an arbitrary 3D orientation.  It may not extrude if extrude determines that the 4th vertex is no longer sufficiently co-planar. 

[j.palmeL29YX]

Thanks a lot for your deep analysis of the problem. It sounds plausible that the extrusion fails if the four points define not exact a plane face (Even if they should). I think the suggestion to reduce the precision of the coordinates will be a practicable workaround to avoid this problem (until it will be fixed by Autodesk). All my other attempts to avoid the problem have worked sometimes/partially, but not always reliably. 

Again a big Thank you. 

[leeminardi]

Well, I thought I knew what the problem is!

I wrote the following vlisp program to round the 3rd and 4th vertices of selected 3dfaces to reduced precision.  Just run the program mf (make face) set the precision and a new set of faces will be created on the current layer that have modified 3rd and 4th vertices.  It works fine on your simple 4 face file but no so well on the large file. 

(defun c:mf (/ prec s i p1 p2 p3 p3xr p3yr p3zr )
; make faces that have their 3rd and 4th vertex rounded to the specidied
; precision.  The new faces will be created on the current layer.
  (setvar "osmode" 0)
  (setq	prec
	 (getreal
	   "\nEnter desired precison roundoff.  E.g., 1 or 0.1 or 0.01 etc."
	 )
  )
  (if (setq s (ssGet))
    (progn
      (setq i 0
	    n (sslength s)
      )
      (while (< i n)
	(setq en (ssName s i))
	(setq ed (entget en))
	(if (= (cdr (assoc 0 ed)) "3DFACE")
	  (progn
	    (setq p1   (cdr (assoc 10 ed))
		  p2   (cdr (assoc 11 ed))
		  p3   (cdr (assoc 12 ed))
		  p3xr (LM:roundm (car p3) prec)
		  p3yr (LM:roundm (cadr p3) prec)
		  p3zr (LM:roundm (caddr p3) prec)
		  p3m  (list p3xr p3yr p3zr)
	    )
	    (entmake (list '(0 . "3dface")
			   (cons 10 p1)
			   (cons 11 p2)
			   (cons 12 p3m)
			   (cons 13 p3m)
		     )
	    )
	    (setq i (1+ i))
	  )				; end while
	)				;end prog 3dface

      )					; progn true
    )					;end if 3dfaces

    (princ "\No 3DFACES found!")
  )					; end if
  (princ "\nDone!")
  (princ)
)


;; Round Multiple  -  Lee Mac
;; Rounds 'n' to the nearest multiple of 'm'

(defun LM:roundm ( n m )
    (* m (atoi (rtos (/ n (float m)) 2 0)))
)

For the file "extrusion fail" it created 7691 new faces.  I ran it several times and got the following results:

Precision    Number removed from selection 

1                         430

10                        430

100                     468 

This makes no sense to me. 

When I aligned a problem face to the xy WCS the face would extrude.  

For a final try, I moved the collection of faces of the unmodified Extrusion_fail file so that the approximate middle of the faces was at 0,0,0.  No faces were noted as being removed! Success?

[SEANT61 · Accepted solution]

I would agree that this probably relates to the double precision floating point anomalies that plague computations AutoCAD performs within several of its commands.  But I also must agree that this 3dFace situation is particularly vexing.  I experience similar failures in AutoCAD 2018.   

While it may be reasonable to believe that the Autodesk Solid Modeler (ASM), and its analysis of double precisions that far from the Origin, will find coordinates that it can’t resolve.  The ASM seems much more adept if the 3dFaces are first converted to Regions (another ASM function) – at least as performed in AutoCAD 2018.  In both files linked to this thread all faces were able to be selected, converted, and extruded at their original position.  Also odd:  if the Region is exploded instead of  extruded, the start/end point coordinates seem to match that of the original 3dFace.

I’d have thought the pre-conversion to Regions would be part of the Extrude command.  Perhaps not.  

[j.palmeL29YX]

---

@SEANT61 wrote:

The ASM seems much more adept if the 3dFaces are first converted to Regions   

---

WOW! 

A very good (while so simple) idea. A region MUST be planar and we don't have the problem of the (sometimes) not planar 3DFaces. 

I tried this with my Project file:

- given is a Polyfacemesh,

- Command "Explode" -> about 35000 3DFaces, 

- Command "Region" -> the same number of regions

- Command "Extrude" -> 

voila - no one of the regions was removed from the selection set of the extrude command. I could create the same number of 3DSolids. 

So the subject of this thread IMO is solved. Thanks to @SEANT61 and of course to @leeminardi too. 

Additional: 

The regions whose normal direction is perpendicular to the extrusion direction (here parallel to the xy-plane) will cause an error message during extrusion (as expected). I'd suggest to remove this regions from the selection set (using a LISP or manually) before extruding. The remaining regions will be extruded correctly.

The (hopefully) only remaining problem: While the extrusion I see an error message code number 109073. I don't know what this points to and also can't see any problems (but of course a bunch of 35000 solids is hard to check if all is correct). But this is another problem. If I can't figure out what is going on I will start a new thread. 

[j.palmeL29YX]

---

@j.palmeL29YX wrote: While the extrusion I see an error message code number 109073. I don't know what this points to ...
But this is another problem. If I can't figure out what is going on I will start a new thread. 

---

FYI: 

By pure coincidence I found what's going wrong. In the bunch of about 35000 regions I found ONE triangular region with a length of about 230000 and a height of about 0.2 (very long and very narrow). After removing this object from the selection set of the extrusion the error message was gone.