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:
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.
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?
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.
@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.
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.
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