[polynurb]

Hello everybody,

I just spent a very tiring evening trying to get multiple texture channels to work in rhino...
Jd, I know you are trying to avoid this rhino feature for realscale mapping, but how can I get it to work if I need it for a certain material?

these are the issues i observed (most of which seem to be a rhino problem):

- it is not possible to switch the openGL Texture preview between channels
(shouldn't it display the other projector when i click on it in the advanced tab??)

- assigning a different channel in maxwell for a particular texture does not work; the channel displayed in the viewport is aways the one being rendered.

- often the mapping widget dissappeares; (it is still selectable via _selAll, but not via mouse)

_the mapping widget moves around when i change UV repeat!

- the mapping widget is visible, but can not be selected (via mouse)

- the mapping widget shows up somewhere else than it was before, when i show it again later.

Now what i would like to know of you guys,.. is anybody out there using this feature successfully?
If you encounter similar problems with texture channels, please post them here. I would really like to get an overview of what is working and what is not;
If McNeel is selling a feature that is not working,.... ... then we should complain most definitely.

..but as always feed back is needed to confirm i am not the one messing up here...

[JDHill]

Hi polynurb,

You should be able to use them however you want to, the reason to stay away for Real Scale textures is that the explicit mappings that you add to an object will get transformed when that object is transformed, and it can get very confusing. When this happens, it is not really possible (as far as I can tell) for the plugin to un-transform the mapping in order to re-size it as necessary to enforce the Real Scale rules. So, if you leave your objects mapping-free for Real Scale, the plugin gets to manage all that itself and it can keep track of things to ensure that 0.25 meters will actually be that size, no matter how much the object has been moved/rotated/scaled, and using whatever the current units are in the document.

But, when it's not for Real Scale, you should be able to use as many texture channels as you want, defined using Rhino's tools. However, I also find these difficult to work with at times, as you have said:

- it is not possible to switch the openGL Texture preview between channels
(shouldn't it display the other projector when i click on it in the advanced tab??)

I think it should work that way, but it doesn't - there seems to be no easy way to switch between mappings. The only way I know of to 'show' any given mapping in the viewport is to actually modify it in some way. If I could, I'd make whichever one the current Maxwell texture is using (via the Channel) current, but so far, I've not been able to do that. So, you will see whichever Maxwell texture you're currently working with through whichever mapping happens to be current in the viewport, and you'll have to manually make sure you're working with the right one.

- assigning a different channel in maxwell for a particular texture does not work; the channel displayed in the viewport is aways the one being rendered.

This should work, though due to the first issue, it is sometimes very hard to keep track of what is where. But to test, create a simple cube, and add two explicit Box mappings (i.e. channel 1 & 2 in Rhino UI). Change UVW scale/rotation for each one, and different from each other. In your Maxwell texture, set the channel to one and render - it should render the #1 mapping. Now set the channel to two and render again, it should now render the #2 mapping.

- often the mapping widget dissappeares; (it is still selectable via _selAll, but not via mouse)
- the mapping widget is visible, but can not be selected (via mouse)

Things like this have been reported, and I seem to recall some issues with them being created on a locked layer or something. I haven't found much consistency here.

_the mapping widget moves around when i change UV repeat!
- the mapping widget shows up somewhere else than it was before, when i show it again later.

These are related to the same reasons for not using explicit mappings with Real Scale. Objects in Rhino (besides for blocks) have no local transformations - everything is in world coordinates. But, the mappings apparently try to listen for move/scale/rotate kind of events on objects, and then to modify themselves accordingly. In my experience, this doesn't really work, and you will see them moving around, scaling themselves out into space...things of this nature. It is always best to get your geometry all built and into place before you start playing around with Rhino mappings, and this is the basic reason.

Now with all that said - it is a complex area, with a bunch of bugs/inconsistencies, and this makes it very difficult to have the plugin work predictably. Consequently, I'm sure there are definite bugs in the plugin in many places regarding mapping - I'm not going to try to say that I've got everything perfect here and it's all strange behavior on Rhino's part...but the bugs that are there make it difficult to even tell if what I'm doing is right or not most of the time.

JD

[JDHill]

Actually, I just found two things:

The bad news: I just found a bad bug, where you will have trouble in 1.6.8 when you switch between textures in the plugin - it is not correctly checking whether RS is enabled, and it is always trying to fix mappings as if they were RS - so basically, it will erase the things you've set in the Rhino mapping UI as it tries to show you the newly-selected texture in the viewport.

The good news: I fixed the above, and I also just found a way to get the right mapping showing in the viewport when you select a texture in the plugin - , i.e.:

- it is not possible to switch the openGL Texture preview between channels
(shouldn't it display the other projector when i click on it in the advanced tab??)

So in the next update, switching the selected texture's Channel in the plugin will also now switch which mapping is shown in the viewport. I thought I'd tried this before without any success, but now it seems to be working.

JD

[polynurb]

thanks for clearing things up JD!

..so if i got you right, it is better for now to stay away from using real scale together with a second non-real scale mapping channel -
or is that a general problem with rhino projectors?

[JDHill]

Basically, as far as staying away from mixing them, at this time I would say, yes. I'll try to give you a more concrete example... if:

a) you have a Material with a RS-off refl. 0° texture, which uses channel 1
b) you have applied it to an object which has an explicit Rhino mapping on 1
c) this mapping is either planar or cubic
d) you rotate/scale the projector in Rhino
e) you switch (in the Material Editor) between this refl. 0° and say, the transmittance texture
f) you switch back to the refl. 0° texture
g) the plugin will now adjust the Rhino texture-mapping to be RS, even though RS is off, and you will lose the rotate/scale you applied in step (d)

This is because, to generate viewport materials, the plugin cycles through the objects; for each object, it reads which (if any) projections have been applied; for those found it checks whether they have a matching texture in the Material (i.e. matching Channel); for those which do, it checks whether they are cubic/planar projections; for those which are, if the matching texture uses Real Scale, then: the plugin will try to adjust them in such a way as to be based on one-meter sizing. If you were even able to read that last sentence, you may understand that the problem is that I missed on checking whether RS is enabled for the matching texture.

However, if you use a Material which only has Channel 0 textures, this bug won't affect you. Also, it will not affect you if you are using projections other than cubic/planar. Also, if you use no explicit projections, and just use the per-texture Tile/Offset controls in the Material Editor, you will not see a problem. Finally, if you apply no explicit projections, and use the plugin to generate RS sizing (just by turning on RS in any given texture), then you will also be fine.

So as you assume, it would probably be difficult to set up an object to use RS for some things, and explicit projections for others at this time.

[polynurb]

If you were even able to read that last sentence, you may understand that the problem is that I missed on checking whether RS is enabled for the matching texture.

reading & understanding don't always go hand in hand..
..but i got it now, and as far as i can reproduce what is going on, i must say that is a bit of a problem

.. if i didn't miss any workaround, then it is impossible to use planar or box projection at all right now.

and since uvw rotation is greyed out for channel 0 mapping, I don't have any clue how to rotate the mapping on a surface...

[JDHill]

.. if i didn't miss any workaround, then it is impossible to use planar or box projection at all right now.

With a Material which has textures where Channel > 0.

.. and since uvw rotation is greyed out for channel 0 mapping, I don't have any clue how to rotate the mapping on a surface...

You are confusing something: UVW rotation is greyed out for Rhino's default 'surface' mapping - not for cubic, spherical, etc.. a Maxwell texture's channel doesn't come into it. If you had an object, and you added three of any kind of Rhino mappings to it, you would then associate different Maxwell textures using three different Channel numbers in those textures. However, any number of textures may be used with a single Rhino mapping - if they all use Channel 0, they will all use that mapping. The problem will come when you want to use multiple mappings on a single object, i.e. to use a cubic mapping for the Refl. 0° texture and a planar mapping for the Roughness texture.

So that's more of an edge-case, and not so much of a show-stopper as if it was doing this for all textures. But the positive side is that finding this problem also caused me to finally figure out how to force Rhino to show any given projection - so in the next release, when you do have textures on different channels, you will be able to see the related mappings in the viewport simply by choosing different textures in the Material Editor - to do this in Rhino, you have to literally change some parameter in the desired mapping to show it in the viewport.

Sorry for the trouble though...

[polynurb]

maybe i am really confused...

isn't the only way to put planar/cubic on an object, checking "custom" in the mapping properties? and that automatically generates a channel >0
also, to show the widget, i need to check advanced UI, where then a channel 1 is present.

..doesn't that channel get affected by switching textures?


sorry to keep bugging you, but i seem to still not get it 100%

[polynurb]

..doesn't that channel get affected by switching textures?

..ok looks like it does not, but is still rendered despite the material being set to channel 0 ?!

[JDHill]

Well, in Rhino it is impossible to create a mapping on channel 0. But...there is a mapping which is not listed at all in the Rhino UI, and this would be the 'current' mapping. So, the plugin maps textures which use Channel 0 with this 'current' mapping in Rhino. When you change params in a Rhino mapping, say one with a channel of 3, then this mapping will be made current, and therefore be shown in the viewport - and any Maxwell textures which use Channel 0 will be mapped with this projection.

You could add 300 mappings to an object in Rhino, but if the Maxwell Material assigned to the object only has Channel 0 textures, they will all just use whichever one of those 300 Rhino mappings happens to be 'current'. If it (the Material) had all its textures set to use Channel 1, then only the channel 1 mapping in Rhino would be used - and it would be used, regardless if it was visible in the viewport.

So I think the main confusion is between the difference between channels in Rhino and texture Channels in Maxwell. Adding a Rhino mapping, with any channel number, has no effect on the related Maxwell Material, until that Material has textures which also use this Channel number.

..doesn't that channel get affected by switching textures?

No, that channel number (i.e. the one in the Rhino UI) is controlled by Rhino. We just use that number, along with the Channel param in the Maxwell textures, to associate different Maxwell textures to specific Rhino mappings. If you only want to use one type of mapping for an object, whether it is surface/cubic/spherical/etc., then you should just leave all of the Maxwell textures on Channel 0 - they will all use whatever you are seeing in the viewport, regardless of the Rhino channel number.

Just let me know if this is helping at all or not...texture mapping in Rhino is one area where none of the concepts are really 'obvious'...

[polynurb]

.. totally forgot about that current mapping..

.. i was wondering why it was still being rendered.. good thing though.

i should be able to handle most of the mapping issues and simply won't use multiple channels for now...

thnx for your assistance!

[jvanmetre]

polynurb-



My method has been trial and error with mapping...emphasis on error!

You have some control over objects at the command line level in Rhino...ie. swithcing UV direction, flipping, swapping UVs, all of which I've found very helpful _Del at the command line, brings up those options, but only with surfaces and not polysurfaces.

I guess if you think about it, it does make sense that you wouldn't have UV control with polysurfaces since there are multiple surfaces. The boxes are grayed out when using surface projection with a polysurface. If you explode the polysurface into surfaces...you gain back control (boxes should not be grayed out) of UVs.

I've been able to use planar mapping, box mapping, surface mapping, displacement, with Rhino -- but again, a lot of trial and error.

jvm

[polynurb]

thanks for your input, jvanmetre!

.. the strage thing is: build a box, then use _extractsrf on any face; you will still find the options greyed out; if you _rebuildedges they will become available.

now further, any uv swap/dir settings you apply to a surface will become obsolete as soon as you join it with another surface.
.. and that is what i find so stupid. why isn't it possible to adjust the uv directions of the subset? or that it at least it remembers mapping after join....

generally all the per surface mappings should be kept after join/explode, imho.

..and then McNeel should give us a graphical tree, where we can see what object uses what projector.
- i mean, it is actually possible to assign one projector to several objects,..
but what is really happening to projectors when objects are grouped or joined?
or you assign a new projector having a group selected?

..there is certainly still a lot of darkness in this part of rhino unless i forgot to take off my sunglasses

[jvanmetre]

I agree, the surface mappings should be kept after join/explode...

Here's another command to work with polysurfaces to reset normals...haven't tried this yet though. I was having some issues with
surface projections on a polysurface...the text was being mirrored -- this command_RemoveFlippedNormals resets the normals and may be of some help as well.

jvm

[adamwade]

JD,

Even when I turn off RealScale and assign MW textures to the corrisponding Rhino texture channels all textures map to only the current active Rhino channel. So it seems we are stuck with one channel MW materials at this time?

Adam