[Josephus Holt]

btw, Real Scale works great for me. Just some general questions...hopefully to save me a lot of time as I'm going through texturing my "Maxwell House" model:
1. Regardless of the texture map size or shape (like square or rectangular), when using Real Scale the map will always fill a 1mx1m square on the object?
2. I've been a little thrown off with the mapping xyz orientations. In the Material Editor you see that the original texture map is longer in the x axis than the y axis (I ajusted the tiling to show how the rendered view might be closer to the original map scale), but what throws me off is that in the model the top and front views have the axis rotated 90 degrees, and it's the RIGHT side view (yz plane) that has the same orientation as the original texture map. BTW, the uvw texture mapping matches the model xyz.

Can you shed figure out where I'm in the dark and shed some light on that???
Thx much, Joe...oops, forgot to upload the image hmm, Imageshack is hanging up:(

[JDHill]

1. when Real Scale is enabled, then you can read the Tile X/Y in the texture editor as meaning 'make each tile X by Y meters' in the model. So to rephrase your original statement: "when using Real Scale, the map will always fill a TileX m x TileY m rectangle on the object."

2. the starting orientation of the cubic mapping applied by the plugin is arbitrary, because the orientation of the persistent feature on the object it is referencing is arbitrary. So you're not missing anything: rotation x/y/z in Maxwell Object Properties > Real Scale Texture Control has no rhyme or reason with respect to the mapping cube's starting orientation.

I'm not sure if this actually answers your questions or not, so let me know...

[Josephus Holt]

1. when Real Scale is enabled, then you can read the Tile X/Y in the texture editor as meaning 'make each tile X by Y meters' in the model. So to rephrase your original statement: "when using Real Scale, the map will always fill a TileX m x TileY m rectangle on the object."

Thanks for the good explanantion, that makes sense to me...got it

2. the starting orientation of the cubic mapping applied by the plugin is arbitrary, because the orientation of the persistent feature on the object it is referencing is arbitrary. So you're not missing anything: rotation x/y/z in Maxwell Object Properties > Real Scale Texture Control has no rhyme or reason with respect to the mapping cube's starting orientation.

I'm not sure if this actually answers your questions or not, so let me know...

This is over my head as I don't know what the "persistent feature on the object it is referencing" is. I'm having a difficult time grasping that a mathematically based program would not look for the model's uvw coordinates and always place the image the exact same way in respect to its uvw orientation.....maybe it does.....just did another little test in another file and found that the mapping came in exactly as I would have expected it! I guess I'll put this on the back burner for now....maybe I had something preset in my first test that altered the mapping.

But I have noticed another little issue...seems like a plugin issue. For instance, I created a cube, applied by layer the mxm and all looked good, the orientation I would have expected, right real scale, etc. Then when I applied box uvw mapping to the object, the scale was greatly increased, and the only way that I've found to "reset" the right (real scale) is to go into the material editor and roll either the x or y values some (ending in the original settings), and all is the right scale again. Is this a bug?

[JDHill]

This is over my head as I don't have a clue what the persistent feature on the object it is referencing is. I'm having a difficult time grasping that a mathematically based program would not look for the model's uvw coordinates and always place the image the exact same way in respect to its uvw orientation.

I'll put it in terms of Cinema. As you recall, there, you have a local coordinate system (in the object's coords tab). Now, Rhino does not have this - all coordinates are in world x/y/z, with geometry just consisting of bits and pieces of things you've drawn strewn about world space. There is, however, a plane equation which is part of the Rhino object, and I use this as a reference frame from which to rotate the cubic mapping. As this plane is created in an arbitrary orientation by Rhino, it then follows that our rotations in x/y/z are also arbitrary in their starting orientation.

But I have noticed another little issue...seems like a plugin issue. For instance, I created a cube, applied by layer the mxm and all looked good, the orientation I would have expected, right real scale, etc. Then when I applied box uvw mapping to the object, the scale was greatly increased, and the only way that I've found to "reset" the right (real scale) is to go into the material editor and roll either the x or y values some (ending in the original settings), and all is the right scale again. Is this a bug?

Not a bug, but a limitation - by using Real Scale, you already have a box mapping created and maintained by the plugin, so you should not then set up a competing box mapping explicitly in Rhino. It is really an either/or situation: use Real Scale with no other mappings, or don't use Real Scale and do your mapping explicitly.

[Josephus Holt]

I'll put it in terms of Cinema. As you recall, there, you have a local coordinate system (in the object's coords tab). Now, Rhino does not have this - all coordinates are in world x/y/z, with geometry just consisting of bits and pieces of things you've drawn strewn about world space. There is, however, a plane equation which is part of the Rhino object, and I use this as a reference frame from which to rotate the cubic mapping. As this plane is created in an arbitrary orientation by Rhino, it then follows that our rotations in x/y/z are also arbitrary in their starting orientation.

JD, that's a good way to explain it for me, I can follow it well enough...just don't quiz me on it on Monday

Not a bug, but a limitation - by using Real Scale, you already have a box mapping created and maintained by the plugin, so you should not then set up a competing box mapping explicitly in Rhino. It is really an either/or situation: use Real Scale with no other mappings, or don't use Real Scale and do your mapping explicitly.

Seems like I've "heard (read) this elsewhere before, you've clarified this...I think we can put this to the test

[kami]

1. when Real Scale is enabled, then you can read the Tile X/Y in the texture editor as meaning 'make each tile X by Y meters' in the model. So to rephrase your original statement: "when using Real Scale, the map will always fill a TileX m x TileY m rectangle on the object."

Hi JD
I got few other questions/remarks/wishes concerning the real scale setting.
1 - with real scale, the texture preview above does not work correctly (at least on 1.8.3, have not checked the newest version). If your texture is 2m high and 5m wide and you put x=5, y=2 i'll look differently stretched in the texture preview, or am I wrong? And you will only see a small part of the texture, which is a bit confusing, because the window only showing the first 1m.
2 - Also a switch to keep the texture at its original proportions would be great. Right now I have to use photoshop (to check the texture size) and the calculator a lot
3 - couldn't the description "tile x" and "tile y" change to something else, to make it clearer that you're working in real scale

cheers,
kami

[JDHill]

1. yes and no, meaning, it may not work how you think it should, but it is working as designed. When real scale is enabled, what you should see (as you said above) in the texture preview is what will be mapped into 1 x 1 meter. If the original aspect ratio frame of the image were not to be maintained in the preview window, then I guess I'm not sure what relationship it would be trying to show you.

2. I agree; it's been in my plans to do something like that.

3. Well, it was called Tile to match with Maxwell, but the term has been changed to 'Repeat' in the UI in 2.0. I think that's less useful than Tile, myself, as it really doesn't make any sense with Real Scale. How about if the labels read 'Repeat X' and 'Repeat Y' when real scale was disabled and then switched to 'Width (m)' and 'Height (m)' when it was enabled?

[kami]

1 - Are you sure that it shows the image in its proper proportions? http://www.pictureupload.de/originals/p ... axwell.jpg
PS on the left side, Rhino on the right. The display above looks wrong. This is the maxwell 1 plugin though ... I have not yet checked it out with the newest plugin.

2 - That's great to hear

3 - Sounds absolutely perfect!

Edit: I just noticed, that I mixed up x and y (like I often do ...). But even if I switch the x and y values, it looks weird.

[JDHill]

I think that shows it working correctly. Here's another:



So, you have a 1x1m plane, and the image is mapped onto it at a size of 1m in the X and 1m in the Y. In the second frame, the Y scale has been set to two meters - as you see, the preview is showing precisely which portion of the image will be visible on the plane, which is still 1x1m.

Nothing has changed here in the 2.x plugin, btw.

[kami]

you are right that the preview shows exactly what is 1x1m, but a wrong proportion. shouldn't it be more like this?

[Josephus Holt]

I find the Real Scale xy adjustments a bit confusing too, so what's working for me is to go in an orthographic view in Rhino (like front if it's a brick wall) and with the rendered view measure my bricks there and adjust the xy in the material editor that way....the WYSIWYG works really well for this. With that it really doesn't matter what the Material Editor is showing, although I agree it would be less confusing if it was showing the map at the "proper" (rendered) proportions.

If it is possible, I would like somewhere in the material editor to see what the texture map size in pixels is...that would make life a little easier.

[JDHill]

So, if I am understanding, you would prefer that when Real Scale was enabled, rather than showing the effect of scaling pixels with respect to texture space, that the preview would instead stretch the aspect ratio of the preview image to match the current Tile X/Y aspect ratio? I can do that.

[kami]

would be a lot clearer I think ... hope I'm not the only one. But I found it always very hard to adjust (without checking what the x/y ration of the original texture was)

[Josephus Holt]

So, if I am understanding, you would prefer that when Real Scale was enabled, rather than showing the effect of scaling pixels with respect to texture space, that the preview would instead stretch the aspect ratio of the preview image to match the current Tile X/Y aspect ratio? I can do that.

x2 I also think that would be clearer.