[kami]

Hi Jeremy

I've got a request but already the feeling that you won't like it
It really would be great if the rendering output would match the viewport in rhino texture wise. (as long as you don't work with multiple mapping channels ...). I've got the feeling that most of the time, this is already the case. But there is one exception, which seems new to me: When you use a box mapping in combination with a real scale texture.

For this case there are two possible scenarios:
1 - you apply a real scale texture to an object that had a box mapping before (and you've forgotten about the box mapping - sadly I don't know any command in rhino to select all objects with mappings).
At the moment rhino is showing me the box mapping, but renders the real scale settings. You will never notice, that the real scale settings might be wrong before the rendering is running.
2 - I know that's not the "right" way to do it, but I've found it very convenient to use real scale and tweak it with a box mapping. In an older plugin it worked when you would give it a box mapping of 1x1x1 meters. Then you could position the real scale texture, rotate it, etc. and it was still in real scale and always rendered as shown in the viewport
The adventage was, that if real scale worked nice in 99% on the cases, and on one object you need to move the texture, you could do this without having to duplicate the materials, remove the real scale and create a box mapping with the size of the real scale.
The other case I used this technique was to randomize the mappings. If I've got a lot of pillars, they would all have the exact same texture position with real scale. With a 1x1x1m box mapping and a rhino script I could randomize the mapping position so that they all would look different, without having to create a new material for this one.

I really hope this is something that is possible, because it can save a lot of time:
- no need to duplicate a texture when you have to manually texture only on specific object
- not having to abort renderings (it happened to me on an animation sequence which was even worse) because one texture was completely wrong, but looked okay in the viewport

Thanks
Kami

[JDHill]

If you have real scale enabled in any texture in an object's material, two things will happen:

• 1. the plugin will generate real scale UVs for the object on channel 0.
  2. Maxwell will render using the reciprocal of the texture's tile x/y values.

It's not entirely obvious that this is how it works, which is understandable. However, it is logical: the plugin has to perform step 1, because Maxwell cannot just randomly project boxes over your geometry, and Maxwell has to perform step 2, since it is Maxwell that decides how to interpret tile values during rendering.

Understanding this, you can see that if you want to use real scale with an explicitly-defined projector, you need to:

• use Rhino to define a 1m cubic projector.
• enable real scale in your textures.
• set your textures to use channel 1.

Real scale UVs will still be calculated and exported as usual for channel 0, but you will not be using them. That is fine, because what you are seeing in the viewport will be the coords defined for channel 1 by Rhino, using your cubic projector. If you guarantee that the actual UVs generated by Rhino are based on projection from a 1m cube, then the altered tile interpretation will work, just as it does when you use channel 0 UVs generated by the plugin. If your cube projector is sized at 2m, though, then your UVs will be scaled up by a factor of 2 -- by using the explicit projector, you are accepting responsibility for ensuring that the UVs will actually work correctly.

Hopefully this helps to clarify things. The reason I write in the manual that it is recommended to avoid mixing real scale and explicit mappings is just that this helps to avoid confusion; if you are aware of what you are doing, though, you can definitely use them together successfully.

[AlexP]

kami, can you share script to randomize mapping widgets?