Can you read texture paramters in a script/macro? And use this to resize a mapping widget to 'real world' scale?

Hi, I’m after some help on texture mapping and how to streamline the workflow a bit.

I work in Architecture, so it’s very important for us to be able to set materials with a ‘real world’ scale. We’re looking at moving across from SketcUp, and this is something they make very easy.

From everything I’ve learned so far in Rhino, that means using WCS/OCS. But we have 2 issues with that:

  1. It means 3-clicks to set a coordinate system on every single object, Which can get veeery tedious on large projects to the point of being unfeasible.
  2. WCS/OCS doesn’t work in Enscape, which we use frequently.

So we’re going to have to work with box mapping.

Essentially what I want to make is a script that will update the box mapping widget based on properties of the material texture.

  • Is it possible to somehow access these texture parameters with some sort of scripted tool?
  • Is it possible to edit an object’s box texture widget?

My scripting experience is limited to pretty basic macros, but we have someone in the office that can do it. But before I throw it to him I need to have some basic idea of whether it’s feasible and so far I haven’t found anything on how to do either of these things.

A few other thoughts on what we’re trying to achieve:

  • Probably won’t work to reference texture pixel size, as resolution varies. Maybe specifying a real world scale in the ‘Notes’ section would work
  • It would be even better if the command could select a face/point on face to align the widget to. 99/100 times aligning the widget to a face will be good enough and better than defaulting to world/cplane
  • As an extension, is there anyway to modify a Surface Map’s UVW repeat values? This would allow us to create a similar “scale to real world” tool

This all really feels like it’s way more difficult than it should be, and I’m hoping we might be able to automate things a bit to make the process a bit more manageable.


You can change texture mappings on objects through scripting with Python. If there is expertise in your group you could also create a C# plug-in for said functionality.

Either way you’ll be using the TextureMapping functionality. See RhinoObject Class , specifically GetTextureMapping, GetTextureChannels, HasTextureMapping and SetTextureMapping functions.

How you encode the material properties is up to you. When you mentioned notes, did you mean notes on the RhinoObject, so that your future script would read those, and based on that create the texture mapping and adjust the material?

1 Like

Hi Nathan,

Thanks for the super fast reply!
Ok so

RhinoObject.SetTextureMapping Method (Int32, TextureMapping, Transform)

Will allow us to set the mapping widget? That’s great.

As for how we read the scale of a texture -
When I mentioned notes, I meant the ‘Notes’ section on the material/texture editor. But I’m still not really sure how I can access any parameters here that could be used to store either real-world dimensions or a real-world scale factor.
I’ve been looking at MATERIAL CLASS and TEXTURE CLASS.

Maybe “Set/GetUserString”? (Material method)
If we could use that notes section to store a string with the dimensions, that might work? Not the most elegant solution but it might be workable.

It would be great if in the future materials actually had a field where you could enter real-world texture sizes. The texture window allows you to enter a “size” for x and y, but it’s kinda hidden - it’s only visible when you have “WCS/OCS” selected, As soon as you switch to “Mapping Channel” the input options switch to “UV” and “Repeat”. This is a bit annoying but I guess could still work, except that I can’t find anything in TEXTURE CLASS that would actually get these parameters.


XY only with OCS
Mapping channel changes to UV repeat

You should prefer RenderMaterial and RenderTexture classes to work with. On RenderTexture you’ll find GetRepeat (same as size in WCS/OCS), GetOffset and GetRotation

From a RhinoObject you can get a RenderMaterial, and you get find textures assigned to a render material by checking its children.

You’ll find you have then also access to the Notes property on say the RenderTexture.

Great! I reckon we can get it working with this. Will post back with the results :grinning:

@josh.nrb , I just remembered an example I wrote about tweaking texture mappings:

You should be able to get going with this, well documented example.

1 Like

@nathanletwory thanks again for this. We’re still working through the tool but I think we’ve managed to find all the functions/parameters we need to make it work.

Trying to figure out what texture parameters relate to what material parameters relate to what widget parameters is all a bit confusing, but that’s all just a matter of HOW we put all the bits together.

Good to hear you’re making progress. Don’t hesitate to post more questions here on the forum.

Cheers. Getting there. There’s some weired stuff that happens with Surface mapping, but I think with box mapping we’re getting our heads around it.

Hey slightly off-topic here but I’ve noticed that if I rotate my mapping widget with the ‘rotate’ command rather than the gumball, the texture doesn’t correctly update. It will refresh once I move the widget.

Widget aligned

Widget rotated.
The preview stretches out as the widget is being transformed, but usually snaps back once the command is finished, but you can see here it hasn’t

If I move the widget slightly it triggers the textures to refresh

Looks like this is happening only in Rendered mode. And with the gumball it happens while rotating, but once rotating is completed it is good again. I’ve logged it as RH-65817 rotating uv mapping (at least box) can cause stretching

RH-65817 is fixed in Rhino 7 Service Release 12

1 Like