Texture Positioning on Groups and Components

[eneroth3]

Currently textures can be positioned on faces. If they aren’t positioned they get drawn according to the axes in their modeling context. I suggest adding an additional optional matrix (set of axes) to groups and component instances to control the texture positioning on faces without their own texture positioning.

The user interface could be reached much similar to face texture positioning but then allow the user to set axes similar to changing a component’s axes.

In Dynamic Components there could be an option (checkbox) to set the texture positioning matrix to the inverse of the transformation matrix (meaning setting the axes to those of the parent drawing context). This would stop the textures from stretch and make Dynamic Components a really useful feature.

This feature would also be very useful for cut-opening components. These components must have their z (blue) axis perpendicular to the face they cut open. That often makes texture positioning in them a bit strange. Of course you can manually position the texture on each face but then you can’t easily repaint the component instance from outside and you need separate component definitions for each material which makes the file bigger.

This would also allow for having multiple components sharing both the same definition and texture without looking exactly identical. In these stairs you could use component properly and still not have the exact same pattern in the wood on all steps. In Dynamic Components there could even be an option to randomly move the texture origin around but keep the axes the same among instances of the same component to have the same texture rotation but different texture location.

[gadget2020]

I was sure I asked for this before, but I can’t find the relevant post… +1 from me.

[thomthom]

@Bryceosaurus - this!

[Anssi]

I think a somewhat logical behaviour would be for textures painted on faces to stretch with the group/component they are in, and textures applied to groups or components to retain their “global” scale when the object is scaled.

Anssi

[eneroth3]

If the texture has a defined position for a specific face I think it should be kep (i.e. stretched when the container is stretched). If there is no texture positioning on a a specific face I think the texture should be applied according to this suggested matrix regardless of wether the material is applied to the face itself or inherited from the container.

I don’t see any reason to treat faces directly painted or faces with an inherited material differently. If the user wants the material on a specific face to stretch along with the container regardless of what the containers texture matrix is they can just position the texture for that individual face and the matrix will be ignored.

[JQL]

This would be cool, what you’re suggesting would be great as it’s like having an UVW axis for a natural texture position.

I’d think of upgrading the request to comply to cubic, spherical or cilindrical mapping.

But in my dreams, what would be really really cool, would be triplanar projection.

[gadget2020]

It would be cool to stretch and deform the “default” texture on a face within a group, (so that the texture applied to the group is deformed on that face.)

Not sure I agree with locking the face transformations when the container is stretched: I like and sometimes use the fact that I can rotate/stretch an object with texture, then I can pipette the resulting deformed texture and apply it elsewhere.
… unless there could be a “lock texture” option. (r-click option?)

[eneroth3]

@gadget2020

ld be cool to stretch and deform the “default” texture on a face within a group, (so that the texture applied to the group is deformed on that face.)

Not sure I agree with locking the face transformations when the container is stretched: I like and som

I’m not exactly sure how you mean. However my suggestion is about all faces that doesn’t have a texture positioning defined for that face. If you want to “lock” the texture positioning on a face (as in not make the suggested texture positioning matrix affect it) just position it for that face. Positioning texture for an individual face is what locks it. You don’t even need to move the handlers, just go into texture positioning and press enter and the texture is positioned for that face.

[gadget2020]

@eneroth3

I’m not exactly sure how you mean.

Currently, if I apply a texture to a face it will distort if I distort the group/component it’s within:

(these are the same component - the lower one is stretched)
In order to get the texture “correct” on the lower face, I had to rotate it slightly on the upper one, then use the pipette tool and apply it again to the lower one (which over-wrote the upper one and squished it)

If a texture was “locked”, then I could scale the component and the texture would be applied as per the texture’s transformation, ignoring the object’s transformation - the hexagons would remain true hexagons at that size, no matter how I stretched or altered the component.

---

With regard to deforming the default texture: the above uses one texture, painted to the component with default texture on all faces except the one facing the camera - it’s been deformed. If I want to change the texture I can simply click a different one on the component and all faces will change… except the one I deformed. If I could have deformed the “default” texture, then I could simply click and it would all change.

[eneroth3]

I think it’s enough to apply the inverse of the transformation matrix as the texture mapping transformation to make all textures scale and stretch according to the parent drawing context’s axes. I don’t want there to be too many exceptions. Exceptions makes it harder to understand for the end user.

“Everything should be made as simple as possible, but not simpler” as Einstein put it.

[gadget2020]

@eneroth3

I think it’s enough to apply the inverse of the transformation matrix as the texture mapping transformation to make all textures scale and stretch according to the parent drawing context’s axes.

Now I don’t get it… can you show pictures?

[eneroth3]

@gadget2020

Now I don’t get it… can you show pictures?

You can look at the sofa in the original post. I just exploded all levels of nested components to position the textures according to the model axes.

[JQL]

@gadget2020

Now I don’t get it… can you show pictures?

Basically if your texture get’s scaled up in X axis inside a component or group the inverted matrix would then get it scaled down the same amount leaving the texture as if it wasn’t scaled.

[gadget2020]

… unless I am reading this wrong, then if the texture is on a component all other instances of the component (not scaled) will be left with strangely scaled textures?
That’s why I was thinking on having the texture disassociated with the component it’s within (locked) - all instances would have the same fill, no matter how the component is stretched. Specifically I’m thinking on a wood texture.

[eneroth3]

@gadget2020

ss I am reading this wrong, then if the texture is on a component all other instances of the component (not scaled) will be left with strangely scaled textures…

Nonono, the texture positioning matrix is defined for each instance. That’s the whole point of it. Other instances aren’t affected.

[gadget2020]

If a group/component is stretched or scaled, then the texture applied to it is stretched or scaled. This is logical, intuitive behavior and personally I can’t see any reason to change this from the default behavior.
However if you want to have a texture (say bricks or a woodgrain) that remains at a specific scale/position when you deform and change the group/component, then I can see an advantage to have a toggle to ‘lock’ the texture to remain unaltered as the group it’s painting is deformed.

Other related improvements outlined above that I would like to see are…

• Being able to deform a texture ([r-click] texture | position) that is applied to a component/group.
• Being able to transform the default texture on a face so that a fill of the enclosing group would keep the transformation.

[eneroth3]

@gadget2020

If a group/component is stretched or scaled, then the texture applied to it is stretched or scaled. This is logical, intuitive behavior and personally I can’t see any reason to change this from the default behavior.

The suggestion is NOT to change the default behavior. The suggestion is to add an optional extra matrix for texture positioning. If that is not done (or the matrix is the identity matrix) the textures would scale EXACTLY as they do now.

@gadget2020

However if you want to have a texture (say bricks or a woodgrain) that remains at a specific scale/position when you deform and change the group/component, then I can see an advantage to have a toggle to ‘lock’ the texture to remain unaltered as the group it’s painting is deformed.

My suggestion allows for that. By setting the texture positioning matrix to the inverse of the transformation matrix no textures are distorted along with the group, unless they are have a per face position. If you want to override this for specific faces (those that aren’t bricks, woodgrain or the like and for some reason should be deformed) you set a per face texture positioning. There is no need to clutter Sketchup with a boolean setting for each and every face to not have or not have it distorted along with the group. It’s already covered in the much more general suggestion that allows for so much more use cases than merely toggling wether a texture should be deformed along with the containing group.

[LEIEDAL]

Hi,

I think that the suggestion of an option that makes it possible to reposition a texture individually with an axis tool would be great! As I don’t think that the native positioning tools now are very user friendly. (Especially rotate)
I also agree with eneroth on the stretched texture comment. At least the option of not stretching the texture should be in there as in 90% of the case you don’t want it to become disformed (because then you have to fix this).
Great images by the way to help explain you thinking!

[Matheron]

Yes.

Adding a new per-instance UV transformation is quite a good idea.

As a start – if you think of it in terms of cubic UV mapping – it would contain translation, orientation, and (per-axis) scaling.

With this, instances of the same component may enjoy different UV properties.

This would be of great help in many situations that require, or benefit from, variations in texture. Yet still using only one single component definition, and one single texture definition, saving vaulable computational resources. Also, from a user’s perspective, it keeps model complexity low.

One concrete user benefit example would be when making a roof with individual 3D roof tiles. Each roof tile is an instance the same component definition. With UV transformation, each tile can use the exact same texture, yet each tile can still show large texture variation.

This would be useful for reproducing the variations we commonly see in so many real-world objects, be they natural or man-made and weathered. It would also be excellent for any third-part rendering purpose.

Currently, to achieve this in Sketchup, you either must make components unique, or make textures unique. Both of these create needless overhead. This overhead is payed for both in terms of needless computational expense, and in terms of needless user actions, and in terms of needless model complexity. In a model with thousands of component instances – which is what it takes to cover the roof of a house even of humble dimensions – the bloat quickly becomes burdensome. Sketchup slows down. Sketchup needs every little bit of help it can get.

With per-instance UV transformation, architectural and other models could look much nicer and still keep a small size and memory footprint.

If implemented, it need not immediately be exposed as a tool in the native UI. A first step could be opening up this functionality in the API, so that we developers can put it to good use.

– What do you think?

[ArayaCAD]

@eneroth3 Hey Eneroth, do you know how to paint using fredo tools or some way of painting a texture onto one or more components or groups and aligning the texture for all so that the texture looks like one texture and not multiple textures in one plane. For example, I have a house with a siding texture applied to each wall. The problem I’m having is that 1 side of a buidling has the 2nd story wall group, the small floor group below and the the wall below that on the 1st floor group. I want to paint my siding on the entire side of the building but I have to have it seperated with a wall for each floor and the floor in between. I use visual merge to merge all the layers together but I need to apply a texture and was wondering if I can apply the texture to all surfaces chosen and adjust so that it looks seamless even though it’s crossing over component to component or group to group whichever. I’ve attached a photo of what I’m referring to. In the photo you’ll see the sections of the wall in groups, I need to paint a siding texture on the entire sides so that it looks seamless from top to bottom.