[bjorn.syse]

Hi,

Is anyone of you still having problems with real scale?

I don't know where to start. I have this floor-surface, about 100 meters wide probably. It has it's own projector/texture mapping set on channel 1. Tried Box and planar.

The material have a few textures, all set on the same channel. Tile X and Y is set to 4,0 and real scale is on (btw, the Real-scale-M is really diffucult to see whether it is yellow or not. Perhaps the contrast between the two could be increased)

No matter, I can't get the real scale to show in Rendered mode. I havent been able to see whether it is right when rendering, but I figured it wouldn't.. Should I try? can the Rendered mode display wrongly?

I think the problem started after I did a "gather all files" yesterday. Could that mess things up? It still finds the textures, otherwise I woulnd't see it at all I gues..

Any thoughts on this?

- björn

[firebird]

Tile X and Y is set to 4,0 and real scale is on

I think real scale only applies to the size of you map, not to the size of your object the material is applied to.

can you show us an image of your rendering and what it is supposed to look like, makes it easier to solve your problem!

cheers

[bjorn.syse]

Well, actually. I'm so sick of it right now, and the deadline is soon. So I'd rather not touch the issue anymore. Perhaps I'll try again some other time. Thanks for you concern though!

[JDHill]

It works fine here - I just tried it similar to what you said, 100x100m, planar projection 4m x 4m tile size...no problem that I could see. That said, the plugin doesn't 'own' the viewport, so changes made to things outside of the texture editor might require you to use the Restore Viewport function - aside from that, I'd probably need to see the file.

JD

[bjorn.syse]

Restore viewport you say... I'll look into it. Get back to you.

[bjorn.syse]

Hi JD,

I am still having problems with real scale.

It just is not working. It works sometimes, om some surfaces, but I can not pinpoint what the reasons for that is. It is seriously driving my mad.

please help me with this.

Look at this screenshot. It's the same material assigned to all boxes (extruded rectangle). None of the boxes have a custom texture mapping.

http://img135.imageshack.us/img135/1401 ... sueuz8.jpg

Perhaps I've understood the Tile X and Y values wrongly? are they, as I've though always expressed in meter? so that 0,30 is 30 cm? or should I consider them the same as my rhino units?

- bJörn

[bjorn.syse]

it is really working the opposite way of what is described in the FAQ (http://www.maxwellrender.com/forum/view ... real+scale)

Look at these pictures..

1. Three brand new boxes with different sizes. They all have their default texture mappings. Assigned is a real-scale material. It is real scale! (this is not always the case though)



2. I add texture mapping to all the boxes, with channel 1 in rhino, and "Box" mode. They all display the real-scale texture in different ways! (and wrong sizes too)



btw, what is the RestoreViewport? not a Rhino command is it?

- Björn

[bjorn.syse]

Furthermore, If I have more than one texture channel on a box, whichever on I change mode on (from surface to planar to box or so), updates the texture in the view - EVEN though I might be changing a channel with number 5 and the material in question doesn't even use that channel... isn't that wierd?

Should I be re-installing something?

- Björn

[JDHill]

Björn,

Way too many variables at once.

Furthermore, If I have more than one texture channel on a box, whichever on I change mode on (from surface to planar to box or so), updates the texture in the view - EVEN though I might be changing a channel with number 5 and the material in question doesn't even use that channel... isn't that wierd?

No it's not weird, that's just how the texture-mapping tool interacts with the viewport. I have never found a very good pattern for predicting how this will behave. If I could control which projection was shown in the viewport, I'd do that when you select a different texture in the plugin, but I haven't yet found a way to make this work

2. I add texture mapping to all the boxes, with channel 1 in rhino, and "Box" mode. They all display the real-scale texture in different ways! (and wrong sizes too)

Try skipping this step altogether. There is a new behavior for RS textures (it's not tested much, so I haven't changed the FAQ), and it should be possible to skip creating an explicit projector - that's why they look okay before you did this step #2.

btw, what is the RestoreViewport? not a Rhino command is it?

Maxwell_RestoreViewport, or the 3rd button in the Maxwell 'Functions' toolbar.

Perhaps I've understood the Tile X and Y values wrongly? are they, as I've though always expressed in meter? so that 0,30 is 30 cm? or should I consider them the same as my rhino units?

Without RS, Tile X/Y mean that for each width of the map, x number of that map will be squeezed into the space - so Tile X = 2.0 means 2 tiles per mapped width in X. With RS, it is meant to work at x% of 1 meter, regardless of the scene scale. What it really means is that the plugin tries to re-create the applicable projector for each related object at such size that RS Tile = 1.0 will mean 1m at that scene scale.

That's where it gets tricky - since you can also mess around with projectors without the plugin knowing about it, it's easy to get out of sync if you aren't following a pretty strict methodology. Also, the texturing system in Rhino really isn't set up to accomodate this at all - it needs to be given global texture space, in addition to the current per-object/widget (remember how young Rhino is in texturing though). Furthermore, it has strange behavior that I haven't yet been 100% able to predict, such as: create an object, give it a projector, switch the projection, then delete the projector. The object shows that it is now using 'default', but when the plugin tries to correct the scale, something isn't working right, and I don't think it will never again get back to working properly.

Tell me if this doesn't work better for you:

1. create some boxes
2. create a material
3. add a texture, set it to channel 1, RS on
4. add a BSDF
5. add a texture to that, set it to channel 2, RS off
6. drag this onto your boxes
7. switch between the textures, adjusting tile/offset
8. Render - you should have 2 channels, and the scales should line up with what you set in the plugin
8. with the RS texture showing in the viewport, scale one of the boxes - now the RS is wrecked for that box
9. issue the RestoreViewport command - the viewport should be fixed up
10 Render should now match up again

If RestoreViewport doesn't work, it may be necessary to either switch to another texture (empty or not) and back, or to toggle RS off/on.

Let me know if that works a bit better.

JD

[JDHill]

I'm looking further into this, and what's happening seems to be:

- make a cube
- create a box mapping
- apply a material
- turn on RS
- everything looks good
- scale the cube
- RS gets screwed up, never to return
- delete the mapping
- add a fresh box mapping
- RS will work again

What's happening is that when you scale the cube, the mapping is also scaled. When the plugin re-sets the size for this projector to be in RS units, it works, but it is subsequently transformed through the scaled mapping - you can see what's going on here if you show the mapping widget. Deleting the mapping and re-creating it makes a new un-transformed mapping in which the RS-scaled size being set by the plugin will be in effect - it won't go through the additional transformation it did with the scaled mapping.

I don't yet see any way through code - or even through the texture-mapping UI - to get a mapping back to n,n,n scale (the UI already says size is at n,n,n when the plugin makes it so) when the object it's associated with has been scaled.

Still looking...

(I should add, there's a good reason for this - say you rotate an object - you want the mapping to rotate as well...but it seems to be a tough problem for dealing with RS and scaled objects)

[JDHill]

Ok...I think I've got this working pretty sweet now. In the next update, here is what you can do when you want to use RS textures: just don't apply any Rhino texture-mapping at all. That's it - I finally figured a way to make this work really nice without any explicit mappings, which you really don't need in an RS context anyway. Avoiding them allows the plugin to keep things synchronized on its own, with much better predictability. Also, the way it works is much better than the regular Rhino 'Box' mapping, because it is built using the object to which it is applied - what I mean is, where now if you:

- make a cube
- apply a texture
- rotate the cube
- create a Rhino box mapping

the mapping-box will not be lined up with the cube - it will be aligned with world xyz, unlike the rotated cube. You'll also get funny things going on if you move/scale things. This stuff won't happen using the plugin's version - the texture will always be oriented to match the object, and it will maintain the real-scale size units specified in the plugin.

Here's a quick example...the scene is in cm, the small cube is 10cm. The RS (tile x/y = 0.1) material was applied to this cube, which was then copied and scaled 2x. The resulting cube was also copied and scaled 2x. Then the 2 larger cubes were moved, and finally the 2 smaller cubes were each rotated using rotate3d. The small cube had already been rotated twice before applying any material. So there are 3 cubes, 10cm, 40cm, and 80cm which all have multiple scale/rotate going on and the RS texture is staying sized correctly and more importantly, oriented logically, with no more input necessary than toggling-on the RS switch...



Try doing that using the normal mapping tools...of course, you can still use them if you want to, but for RS I think this will work much better.

[bjorn.syse]

This sounds really interesting, I'm looking forward to try that. However, until then, what is a safe workflow to deal with this issue?

...to make this work really nice without any explicit mappings, which you really don't need in an RS context anyway. ...

That might be true when dealing with floor surfaces, however I'm not so sure it goes for all cases. The stuff I'm working on right now are extruded baseboards to be rendered for catalogue work. The way I build them is I extrude their profile curve. Whenever there's a knot in the profile curves, the resulting surface becomes a polysurface, and the wood texture can turn up lying in different directions - which of course is not natural at all.




However, I still want to use real-scale in order for the group of four modelers to be able to use the same material MXM and the same scene, so that all the renders look similar in scale etc.

- Björn

[JDHill]

what is a safe workflow to deal with this issue?

Hard to say, with the dodgy nature of Rhino's texture mapping, what I've shown above is by far the most consistent thing I've used as of yet. Closest to safe for 1.6.1 is also to just not apply explicit mappings if you can help it (see ex. 1 in your previous post) - if you can't, don't try to scale your objects because the plugin won't be able to alter them correctly afterwards. You may realize that this problem stems from having two UIs sharing one target - my aim of maintaining a real scale vs. Rhino texture mappings and object transformations - and neither one really has decent control over what the user does with the other.

Therefore, if the question is what is safe, the real answer would be to use one or the other exclusively - there's absolutely no magic in Maxwell RS, this stuff is all plugin gymnastics. That is to say, you can accomplish all the same things if you leave RS off and modify the mapping 'Size' parameter for your objects - that's all the plugin is doing.

That might be true when dealing with floor surfaces, however I'm not so sure it goes for all cases.

I understand that, and I wasn't meaning to minimze it, but there are limitations on what can be accomplished in any given time frame - for now, I don't think you'll have a huge issue with it, at least not any worse than other general mapping issues. Given the image you posted, I'd say the only way to get good looking mapping either way would be to use divided texture space with custom-made maps. A regular box mapping is just not sufficient to deal with that kind of a scenario - at least with the new plugin method, once you've got the map built to work correctly, it will stay oriented correctly when you transform the object. It's possible in the future that I could manage to put in some rotation controls...let me think about that...

[bjorn.syse]

Hi again,

Thanks for the effort of looking into this, and I understand that dealing with Rhinos texturing isn't allways the way you want it too.

I have managed to get a decent workflow out of it, and what I was missing totally up until you wrote it yesterday was the function Maxwell Restore viewport.. I hadn't tried it until yesterday, and much of my problems stemmed from not beeing aware of the need to use it.

So, right now, I'm using a planar projection, and adjusting the mapping widget in Rhino combined with real scale, and It hasn't made me freak out yet, so that's a good sign.

Looking forward to the new plugin!

[abaez]

Does the rescale ---- apply the same for nonmetric models

Channel 1 = real scale ?