- Mon Apr 29, 2013 6:38 pm
#367445
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
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
nightnurse images, Zürich
http://www.nightnurse.ch
http://www.nightnurse.ch