Boolean operations sometimes modify texture position

bug

#1

I noticed this strange bug for quite some time but still haven’t found a way to consistently reproduce it.

When working with booleans that have a material with a texture applied, sometimes after doing a trim or add or subtract etc, the texture coordinates are changed / moved a bit.
This can result in having to redo them again (and again and again if you need to apply more boolean operations later in the process).

To test;

  • just create a few shapes and apply a material with a texture.
  • play with the objects (move / rotate etc) and apply a boolean. At some point it will fail.

Anyone else noticed this and knows a workaround maybe?
Will try to upload a video the next time this happens again

edit: added gif
edit2; added a skp for testing; boolean union main & add
booleans.skp (132.4 KB)


#2

Textures on faces with no locally specified positioning are positioned according to the local axes. The native solid tools draw their output to a new group, created from scratch, with the origin in the lower front left corner, without caring about the original axes location.

My own solid tool extension keeps the the axes of the solid that is regarded the target (the one being edited), which would avoid the materials jumping on one of the original solids. To also avoid the material on the other jumping around, you could make sure from the start their axes line up. This is btw a great way to make sure textures match where objects meet.


#3

@eneroth3 thanks for the explanation Christina. Could you elaborate on this part of your reply? The faces have materials, not the container (group/component).

Also, ‘axes line up’ means xyz are all in the same direction (aligned to world axes) OR must also the origin match exactly? (can only be done using components)

I will have a look at your plugin as well.


#4

You can experiment a little yourself with changes axes in a group/component and see how the materials react. You have to exit the group though for the changes to apply.

I was refereeing to an exact match.

you can change group axes too. Just enter the group, right click the axes and select Place.


#5

@eneroth3 Thanks for the additional info. I downloaded your solid tool and after aligning the axis, it works as expected.

Still, having to line up the axes and origin all the time for boolean objects is a bit of a hassle. Too bad that can’t be done for groups using ruby…(I had a quick look at the api).


#6

I had code lying around that I still haven’t published. This small extension is activated from Extensions > Eneroth Line Up Axes and move the axes of selected groups an components to match the parent drawing context.

ene_line_up_axes_v1.0.0.rbz (5.8 KB)


#7

Thats nice!
Although when running the code the texture uvs on the objects are changed again (if the axis is different from the origin).
If only native-SketchUp would leave the coordinates as they were in the beginning and not alter them when re-grouping, doing boolean operations etc etc…


#8

For grouping and making components I think it makes sense to position the local origin in the corner of the bounding box, so the object isn’t too far away from its origin. At least for components, as these represent a complete object of its own (can be though of as an embedded SketchUp model) and are often copied and moved around. Groups though typically represents something that only makes sense in its given context, e.g. a wall built on site and could maybe match the parent axes after creation, but I think it would be confusing with an inconsistency between the two.

With the solid operations I agree moving the axes is quite annoying. It’s all a result of the result being drawn to a new group, rather than added to an existing instance, which I think is a design failure.


#9

@eneroth3 Thanks for your time and effort looking into this. It was bugging me for a long time already. At least I now know a workaround. Have to think how to fit it into my workflow.