Accessing surface texture UV tiling and offset values

Hi Everybody,

i am trying to automate surface texture mapping and would need access to the UVW tiling,offset and rotation values which are exposed at the bottom of the object properties window/mapping tab.
being able to set a mapping channel number would be very helpful too.

the aim is to set different values for a set of surfaces, and to use “surface” mapping type.

i am pretty new to scripting and the rhinoCommon SDK, but as far as i looked “TextureMapping Members” don’t seem to expose these parameters.
In fact, even in rhino itself i don’t find a way to access the texture mapping properties by command line.

i would be very glad if someone could point out if this can be done.
ideally the script is a c# component of a grasshopper setup, but any way of automated access to these settings would be a great help.


it has been a while, so i thought i bump it.

the problem remains essentially the same, I am still looking for a scripted way to control texture offset/tiling/rotation values for any texture mapping type (“surface” being the most vital to me)

i see that the command line now gives access to “tiling” upon creation of a mapping but offset is still hidden and accessible via GUI only afaik.

if someone has an idea how offset/rotation values could be randomized I’d be really glad to hear


Hi Daniel,

The commandline access to offset is there, it just seems to be hidden under the tiling option:

_-Properties _Material _Object "Rhinoceros" _TextureMap _Tiling _OffsetU 0.5

I cannot see commandline access to rotation nor do i know a way to do this from RhinoCommon, Python or RhinoScript. The only way i´ve found to randomize the mapping regardles of the current renderer, is by accessing texture coordinates themself which i did for meshes only. Below is one example RhinoScript and workspace file to change mesh texture coordinates, eg. move (offset), rotate, scale (tiling), flipping for both directions etc. Note that you have to define a searchpath to the below RhinoScript in order to use the buttons in the toolbar. The Script also works without the toolbar. In short it does this:

  1. Read the mesh texture coordinates
  2. transform them
  3. recreate the mesh with the new texture coordinates

TransMeshTex.rui (53.4 KB)
TransMeshTexCoords.rvb (7.3 KB)

@BrianJ could this please be considered as a wish for Rhino6: scriptable control over tiling, rotation and offset for textures ? And i guess the missing option to rotate the mapping is just an oversight :wink:


hi Clement,

thanks for the good news!

1st, concerning the “tiling”, indeed i did missed that one but also because I was looking for it under “texture mapping” (which doesn’t exist in the CL) and not “Material”.
that is because, as you noted, i am looking to do these changes persistent on the object level so that any renderer or file export can access the texture coordinates.

2nd, very cool script, installed and working great!
(found a little toolbar glitch on the R-button V-scale, says “both” should be “v” only)
to do these transformation on meshes is a good alternative;
Interesting that a texture map has to be assigned first, i guess to initially create the texture coordinates on the object. In that respect, although not directly related, i am wondering why in rhino 5 a fresh surface object does not show “default” surface mapping in the mapping dialog, although it is active.
If we get scripted access to the UVW parameters it would avoid having to create the surface-mapping on the object in the first place, potentially saving a lot of time if processing thousands of objects. I belive in Rhino 4 things worked differently;
I have posted about this here: unpacking textures

The mesh join in rhino still messes up texture coordinates, as opposed to the mesh join in grasshopper(keeps all coordinates of disjoint pieces after join) which I use atm to do these operations, maybe you guys can look into that as well as I don’t really see any advantage in the current mesh join behavior within Rhino.

again thanks for the script! I came as far as decomposing a mesh via python in Grasshopper, but I did not find a node for reconstruction including texture coordinates.
I will see about putting your script in a GH node…

might come back here when I hit the next wall :smile:


Yes thanks. Must be a copy paste error. Yesterday i´ve found that i cannot export a single toolbar as workspace. So i´ve just used copy paste to make a new toolbar :wink:

I´ve implemented that in the script to prevent users from using it without seeing what it actually does. Note that it can be difficult to undo the transforms if you do not remember which transforms have been applied previously. Eg. there is no easy way to restore surface mapping type on meshes.

I guess one way doing this in GH is to create a custom python component which adds the mesh with (randomized) texture coordinates using rs.AddMesh method. Or use MeshEdit ? Another thing which came to my mind to make this all work with NURBS is to use a custom rendermesh via the RDK but i have not done so in the past.

PS. If possible, please provide an example file and some steps for the developers where joining meshes messes up their texture coordinates.


please try the following steps as an example:

1-new file, draw a 2pt srf.

2-drag some texture on it

3-copy the surface

4-add surface mapping to both

5-change eg. tiling one one of the two

6-mesh both nurbs or extract rendermesh

7-select the meshes with crossing box and join

you should see that the mappings one one object get replaced by the other.

two odd things:
A: if under STEP 4 you DO NOT assign a surface mapping to the second surface and continue the steps join will be ok.
B: if you do not use crossing box in STEP 7 but eg. select the meshes one by one in the viewport join will also be ok.

hope this helps!

Hi Daniel,

This issue has been recently discussed and RMA is aware of it.
You may also look at the temp workaround to make your meshes retain texture coords:

Hi Jarek,

thanks for your reply, good to know that it is being fixed!

obj export is a way for now, if you have rhino 4 open, you can also just copy the meshes to v4 join them there and copy back, or use the grasshopper mesh join node which should also work as expected concerning tex coordinates.


That’s better workaround (V4 copy-paste) - thanks!
I’m hoping there will be a command to ‘Bake’ the texture coordinates to meshes in V6.

A post was split to a new topic: Accessing surface texture UV tiling