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.

cheers,
Daniel

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

thanks,
Daniel

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:

c.

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:

cheers,
Daniel

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.

c.

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!
D.

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.

cheers,
D.

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

Hi @clement, from time to time your little tool helps me to adjust mesh UV. Unfortunately it doesn’t work anymore. I tried it at Rhino 5 and 6. It could be great, if you could update it please.

-Micha

Hi @Micha, this is an old script. I’ve tested it in Rhino 6 and it still worked. But you need to assign a texture to the mesh and have it preselected:

Did you test it in Rhino 7 ?

_
c.

I used this button script:

_NoEcho
-_LoadScript “C:\Program Files\Rhino 6\Extra 6\transmeshtexcoords.rvb”
Flip_V

and get this error message:
image

At texture is assigned and I tried preselection and no preselection. Without preselection the tool is started and ask for a mesh. So, the button scripts seams to work and start the rvb.

Maybe my rvb is older than yours. Your upload from 2015 at this thread above doesn’t work anymore. If you like we could try a fresh uploaded rvb.

Hi @Micha, hm i have not touched it since then: TransMeshTexCoords.rvb (7.3 KB)

During the years i’ve written much better texture related tools than above rvb script, but with python. Now i’ve tried some of them and see…they don’t work either.

_
c.

Hmm, same runtime error like before. Variable is not defined: ‘Print’.

Pls. send this script via PM and the Rhino version you use.

_
c.

Good news - it works. :slight_smile: I found now as I downloaded your rvb from today Chrome saved the rvb with the name TransMeshTexCoords (2).rvb since the old version was blocked by an open Rhino task. It works perfect now.

Thank you very much for your help and so quick. :slight_smile:

OK great ! I wonder if something like shown below would be more useful, it does not change or require mesh uvs, it’s working with the values from the texture slot:

_
c.

It looks nice. More I would like to see a slider functionality for the default Rhino tools. For example a hidden slider function could keep the UI compact. Click on a number and move the mouse up/down like on a hidden slider. Most I don’t like so much to install extra tools for exist functions since all this tools can break and needs to be updated. :wink:

@BrianJ I’m not sure you are the man for my wish - could Rhino not support UV manipulation for meshes per _dir? I miss to switch the direction of U and V and to swap both. I don’t understand why it works for NURBS only.

Hi @Micha make a new post please and provide a mesh model with an applied material and texture map to explain the request and I can file it, just @ mention me. My understanding is that meshes don’t have default U V directions like NURBS surfaces do with their U and V surface directions. Run the Dir command on a mesh plane versus a NURBS plane for instance to see the lack of U and V on the mesh. Perhaps that is something that could be added for meshes but I’m not sure how it would work on a triangulated mesh.