[f64cg]

Greetings Maxwellians,

Anyone else get weird results if you:

1. Create Cylinder Primitive Solid (in new rhino document...with viewport set to Rendered View)
2. Create and Apply simple material with UV Map (or other colored checkerboard style texture calibration image) to Cylinder.
3. Change the Cylinder's texture mapping (ignoring for the moment that it looks pretty good surface mapped) by going to object properties>Texture Mapping>Apply Cylindrical Mapping button and follow directions for defining the cylinder....

At this point for us the texture mapping goes wacky bananas......looks black and white, semi-transparent and not at all like it does in surface mapping.

Same behavior seems to occur with Planar mapping, Spherical mapping, and both Cylindrical setups....seems OK with Box mapping or surface mapping.....

When you try to render one of these problematic mappings (Planar, Spherical, or Cylindrical) the object defaults back to its surface mapping....

We've tested this with the last 2 releases of the Rhino 5 Beta (10-20 and 10-25) and are seeing this behavior in both.

[JDHill]

I confirm your steps 1-3, but the weird cylindrical mapping renders in Maxwell as it does in the viewport.

viewport.png

render.png

[f64cg]

It just gets stranger....

So when I remote desktopped into work last night after JDs post to check my workflow for the 3rd or 4th time everything seemed to be back to normal.....
My process (via remote desktop) that I outlined in the first post produced predictable results just as JD was seeing. OK. So I must have been tired at the office yesterday and screwed things up somewhere in my workflow.

Tried again via remote desktop this morning...good predictable results....
Arrived at the office and went through the whole thing again and its doing what it did yesterday...the mapping is way off : the image being used as BSDF is now greyscale (was color) and is distorted way beyond what is typical....and attempting to adjust the mapping controls just makes it look stranger. Regardless of all that....if we try and use Spherical, Cylindrical, or Planar mapping, the render defaults back to surface mapping and doesnt at all reflect what we see in the view port.

We tested this on all three of our workstations at the office and are seeing the same thing. I'm thinking its graphic card/OpenGL related? Two of our workstations are running Quadro FX 4800's and Our newest is running a Quadro 4000....all with the latest drivers. But if I remember correctly the remote desktop protocols disable some elements of graphical display. The other thought I had was that it is related to WIndows 7 color mode.....when you remote-in it automatically sets the Windows Color mode to "Basic"...?

I'll get some screen shots up here in a bit.

[f64cg]

OK.

So changing the Windows 7 Visual Theme to Basic seems to be the fix.
Seems crazy to me that something in the Aero themes would be so invasive as to disrupt the mapping>rendering relationship. I mean it would make sense to me if the viewport was drawing strangely and things end up looking weird pre-render (in viewport) but it surprises me that the issue translates all the way through the process and shows up post-render in a Fire/Maxwell Render window.

At least its easy enough to switch off....

[JDHill]

Sorry, but so far, none of that makes much sense from a code standpoint. Suffice to say, the plugin can only render whatever UVs are provided by Rhino. So, the plugin can help you verify whether what is coming from Rhino (i.e. what is obtained via the Rhino SDK) matches what it is showing in its viewport, but that's about the extent of it. It does seem remarkably strange, as you point out, that changing the Windows theme could affect the UVs provided by Rhino to the plugin. You may want to do some further checking to confirm that this is actually what is happening; possibly you could do that by switching to Rhino Render, and repeating a failing test, to see how Rhino Render behaves. Technically, while the absence of a matching behavior would not indicate anything, its presence would.

[f64cg]

Thanks JD

Apparently I posted too soon...as it turns out the Theme change was not the variable that was making a difference.

I'm still narrowing it down but it looks like its actually all related to the material itself having bad paths. We keep all our textures and materials on a network shared drive and it appears that perhaps maxwell isn't able to utilize the search depth function properly. If we have textures nested within folders deeper than the root of the shared drive it reports the mxm as having bad paths...

The only way to get the material to show up without any bad paths is to input the actual folder three levels deep on our Z: (network shared material drive) in the search paths input. Even setting the search depth to 100 and setting Z: as the first texture folder in the search paths input doesn't seem to get it.

A lot of the behavior is, unfortunately, inconsistent....
I copied one of our problematic materials and all its associated texture images to my local machine's data drive, reset the paths on that mxm and imported it and it works as expected...even without any local machine folders added to the search paths input. I then import the same mxm off the network drive and PRESTO it also reports as being fine without any bad paths.
Switching this process up a bit and importing the mxm off the network drive first: the mxm has bad paths.... THEN I import the version of the mxm off my local machine and it has no bad paths....check the initial mxm imported from network share...its still got bad paths....delete mxm with bad paths....reimport same mxm from network share and PRESTO no bad paths.

Continuing to investigate....

[JDHill]

I was not aware that Maxwell materials were involved; in my above test, I used a simple Rhino material with a checkerboard texture.

Regarding any question about bad path searching, may I assume that you have enabled Perform Path Checking, and set Search Depth to a value which would allow the plugin to find your textures? Regarding consistency, realize that in addition to the Search Paths you explicitly define, the plugin does take other opportunities to add more paths into the search list during the session; for example, when you open a document, or when you browse for an MXM or texture, the plugin will add those paths to the list of paths to check. Such additions are, however, only effective during the current session.

All that said, though, I am not yet understanding how this would relate to texture mapping, and it would be best to first confirm, without introducing any other factors, whether you are having an issue with that, and if so, whether it is related to some problem with the plugin or not.

[polynurb]

i am just chipping in because i also saw some new bugs with one of the latest r5 betad concerning texturing/mapping:

when i apply eg. box mapping , everything is fine until i complete the command, a projector is created, but it is always planar mapping!!!

i can only get box to work if i change the projector type once i created it. but the numerical values are total nonsense and need to be input again.

[f64cg]

JD -

Your assumptions were correct in regards to the material search paths stuff...."enabled Perform Path Checking, and set Search Depth to a value which would allow the plugin to find your textures"

I think I wrongly assumed that this issue (which I still see as a problem...) is related to the initial problems I posted about.
It would seem that there's perhaps a few issues that are hard to distinguish in the file Im working with....

I created a screen grab video of my workflow that shows the issues I am seeing.
I will send you an email off-forum with a link to the video and a copy of the rhino file I am seeing this issue in....its those same truck tires you've helped me troubleshoot other issues with in the past....

We're seeing this issue in both the 10-20 and 10-25 release of the V5 Beta...current Maxwell for Rhino plugin....

[f64cg]

Little Update....

As of the newest Rhino build (11-22-2011) we're seeing more reliable mapping and not having the issues described in the original post.

Hooray!

[f64cg]

Oh And we're back.....!
Having similar issues to this in the latest Rhino build.....

Only Planar UV, Surface and Box mapping appear to be go through...

Spherical, cylindrical and planar UVW just render as surface mapping or incorrectly all together....
The cylindircal mapping on all our tire models just went whack-bat in the latest build.

We're are still using MW 2.5.13....

Anyone else seeing this?

[JDHill]

I see similar things, and am still on the 5/15 build. Not much more I can say, though I'm curious why you'd be using 2.5.13 (not that moving to the current plugin would magically fix this issue -- it wouldn't).

[f64cg]

Okee Dokee
I am soooo glad we finished our last major project a few weeks ago and are just doing some R&D at the moment!
Rhino 5 dev seems to be "3 steps forward one step back" these days....

We were mid-project cycle when 2.6 came out and were fearful to upgrade....then the project went on for about 5 months

[JDHill]

Ah, that makes sense, then -- thanks.

[f64cg]

I had managed to get by with the 4/25 release of Rhino 5 until now....it has expired. This was the last version that seemed to hold texture mapping with anything other than surface, planar or box projections.

There've been 7 version releases since the 4/25 build with no improvements to this issue.
I understand that the MW plugin is truly a Rhino V4 plugin and is developed as such but am curious if there is any sense as to how /when this issue might be addressed. It seems like there was a substantial change to mapping with the 5/2 release of RhinoV5 and its been pretty much this way ever since.

Is there the potential that this issue won't be able to be addressed until V5 is officially released?

Hope this doesn't sound whiny because I don't mean to be.....just curious and trying to figure out if we should start creating some new workflow in other 3d software.