X-Z Plane Issues for Push-Pull

[medeek]

When I’m creating window and door geometry within the new wall plugin I’ve noticed a small degree of unpredictability with regards to the push-pull direction for faces on the X-Z plane. Sometimes it goes one direction, sometimes another. This of course creates problems for me since it make my solids potentially extrude out the wrong direction. 9 out of 10 times I don’t see the issue but once in a while, BOOM, its there, I’m scratching my head.

For geometry that I am starting out on an X-Y Plane I do a quick check to see if Z equals zero. If it does I reverse the push pull direction, this works quite reliably. I am wondering though what could be the situation with the X-Z plane and if Y equals zero I need to reverse the direction. Perhaps the small rounding errors with floats is causing this unpredictable behavior.

Wondering if anyone else has had a similar issue.

[DanRathbun]

@medeek

For geometry that I am starting out on an X-Y Plane I do a quick check to see if Z equals zero. If it does I reverse the push pull direction, this works quite reliably.

I would think PushPull relies upon the direction of the face’s normal ?

Testing … yes it does.

Positive values passed to #pushpull method is along the face’s normal vector, negative values are anti-normal.

EDIT: Actually the docs for Sketchup::Face#pushpull say just this, viz:

The distance is measured in the direction that the face normal is pointing.

The special behavior of the X-Y ground plane does not apply directly to pushpull.
Instead it applies to manual drawing of faces on the ground plane in prep for likely manual pushpull operations

---

@medeek

Perhaps the small rounding errors with floats is causing this unpredictable behavior.

Convert to Length class and use it’s == method ?

[medeek]

After some further testing (quantity is the key) I’ve noticed some additional patterns. The issue only seems to be happening to the solids that involved curved geometry. I then dug into one of my methods that creates the arched casing over a window to see if I can find any other spots where some instability or variability could be lurking. A chunk of this code is below:

   group1 = Sketchup.active_model.active_entities.add_group
			entities1 = group1.entities
			group1.description = "CASING JAMB EXT HEADER"
			group1.name = "CASING JAMB EXT HEADER"

			normal1 = Geom::Vector3d.new 0,-1,0
			xaxis1 = Geom::Vector3d.new 1,0,0
			center_pt1 = [0,@Std0y1,@pt1ym]

			@radius3 = @Wcjex2r
			@radius4 = @Wcjex1r

			edgearray1 = entities1.add_arc center_pt1, xaxis1, normal1, @radius3, 3.14159265358979, 0
			edge1 = edgearray1[0]
			arccurve1 = edge1.curve

			edgearray2 = entities1.add_arc center_pt1, xaxis1, normal1, @radius4, 3.14159265358979, 0
			edge2 = edgearray2[0]
			arccurve2 = edge2.curve

			line1 = entities1.add_line [@Wcjex1, @Std0y1, @Wcjey1] , [@Wcjex2, @Std0y1, @Wcjey1]
			line2 = entities1.add_line [@Wcjex1r, @Std0y1, @Wcjey1] , [@Wcjex2r, @Std0y1, @Wcjey1]
					
			halfround_path = line1.all_connected
			new_face1 = entities1.add_face(halfround_path)
			new_face1.pushpull @Win_jambextdepth_casing

I think the problem is where I perform the “all_connected” command, and then turn it into a face. What is the order that the items get added to path that creates the face? If this is somewhat random then it explains what I am seeing.

[DanRathbun]

(1) Your code does us no good as it contains instance variables from elsewhere (using some “secret” personal naming convention.)

@medeek

What is the order that the items get added to path that creates the face?

This doesn’t read quite right. What are you trying to say?

ADD: I think relying upon #all_connected is dangerous as the array can contain different kinds of entities including the edge itself and other faces and edges. You should at the very least #grep just edges.

@medeek

If this is somewhat random then it explains what I am seeing.

I do not know if you can rely upon any certain order.

[medeek]

The clocking of the points that make up a face is important since it determines the direction of the normal and hence the direction in which it will extrude (pushpull). By reversing the order it will reverse the direction of the extrusion.

Like you are saying regardless of what method I use to collect up the edges to define the face I cannot rely upon any certain order. The rational thing to do is simply check the normal of the face and then either reverse the face or negate my pushpull direction. Something like this?

halfround_path = line1.all_connected			
new_face1 = entities1.add_face(halfround_path)
face1normal = new_face1.normal
if face1normal.y < 1
    new_face1.pushpull @Win_jambextdepth_casing
else
    new_face1.pushpull -@Win_jambextdepth_casing
end

[medeek]

A more concise if statement would be:

if new_face1.normal.y < 1
  ...
else
  ...
end