[kami]

Hi Jeremy

We've been working with V3 for one week now, and the general feedback in our office is really good. But there are a few things that are not working as expected and some situations are now handled worse than before. I hope it's okay if I just post all of that in this thread here? The files are linked at the end of the message. Some seems like bugs or unexpected limitations or just working inconveniently.

Scene 1a - Realscale on an imported mesh
There is an imported mesh we received (it was exported out of ArchiCAD). We textured it with realscale, but it is not possible to rotate the realscale texture with the "RS Rotation" in the viewport. You have to use fire to fine tune the texture direction.

Scene 1ba - Realscale texture with texture rotation
So what we did was using the 'Rotation' in the Texture Editor of the Material Editor, which seems like a good feature. The texture has a ratio of 1 to 3 (as repeat value in meters). When you leave this like it is and rotate the texture by 90 degrees, the texture scale looks correct in the texture preview and in the rhino viewport, but it renders out in the wrong scale. If you change the ratio values to 3 by 1 meters, it renders out correctly but shows wrong in the texture editor and the viewport. I'm suspecting this is a bug?

Scene 2a - surface mapping
There is an imported mesh out of Marvelous Designer. Marvelous Designer exports its objects with a working surface mapping. When I assign a Maxwell material to the object, the orientation of the objects look good in the viewport, I would just need to rotate the texture on it and move it to the right position. But in fire the rendering looks different than in the viewport. Why is this? I thought using the mapping channel 0 means, that it takes the mapping coordinates of the object? It also looks wrong if rendered without fire.
Now I added a surface mapping in rhino on channel 1 and changed the texture channel to 1. This renders fine now.

Scene 2b - weird fire behavior
With this scene, it takes 15 seconds, to open fire and 30 seconds to close the fire window on my machine. That seems unusually long, given that there is only one texture and one mesh in the file. Is this the same for you?

Scene 2c - not working?
Is a similar export out of Mavelous Designer.
Starting the same as in 2a, but now I am not able to texture the object at all (it does not show a texture in the viewport nor does it render one) even not with a surface mapping and channel 1 for the texture. Do you have any idea why this is?

Here is the link to the scenes:
https://dl.dropboxusercontent.com/u/490 ... 0forum.zip

Thanks a lot for your help and clarifications
Christoph

[kami]

Scene 3 - restoring missing textures
This really is a weird one, actually not a problem. I'd just like know why this is happening:
I took a file from the server and saved it onto the desktop, used the Maxwell_GatherFilesandMakePathRelative command, saved the file and closed it.
Now I intentionally deleted one texture to create a bad path. When I open the file now by double-clicking on it in the windows explorer, it shows this material with a bad path. When I click render, I get the error message that the texture is missing. But when I just click render again, I get no error message anymore, but the texture is found again!
When I go into the material and that specific texture is it not red anymore but he has relinked the texture, but taken from the old path on the server now instead of the 'textures' subfolder where I deleted it. How does the plugin know where the texture was saved before? And why does he relink it automatically from there on rendering the scene? does that make sense to you?

The intention for this test was, that I am still having problems with files that have missing textures under certain circumstances... I am just not able to narrow it down at the moment.

[JDHill]

Thanks Kami, I'll take a look and let you know.

[JDHill]

Scene 1a - Realscale on an imported mesh
There is an imported mesh we received (it was exported out of ArchiCAD). We textured it with realscale, but it is not possible to rotate the realscale texture with the "RS Rotation" in the viewport. You have to use fire to fine tune the texture direction.

This appears to be due to some UV caching scheme in the Rhino viewport. If you explode the mesh, you'll find that the RS Rotation spinners work fine on any individual piece. You can then join together, say, 30 pieces, and it will continue to work. Keep joining more though, and at a certain point, an odd behavior will manifest: immediately after the Join command, RS Rotation will work, but after you zoom/pan/orbit in the viewport, it won't.

Scene 1ba - Realscale texture with texture rotation
So what we did was using the 'Rotation' in the Texture Editor of the Material Editor, which seems like a good feature. The texture has a ratio of 1 to 3 (as repeat value in meters). When you leave this like it is and rotate the texture by 90 degrees, the texture scale looks correct in the texture preview and in the rhino viewport, but it renders out in the wrong scale. If you change the ratio values to 3 by 1 meters, it renders out correctly but shows wrong in the texture editor and the viewport. I'm suspecting this is a bug?

Not so much bug as limitation -- the more projection parameters are added to the Maxwell texture, the lower the likelihood of being able to perfectly predict their rendered result in the viewport, or in the texture editor preview, due to incompatible underlying conceptions of the meaning of parameters (for a really clear example of what I mean, apply a textured material to a plane, set Mirror to XY, Repeat to 2/2, and then adjust Rotation).

Scene 2a - surface mapping
There is an imported mesh out of Marvelous Designer. Marvelous Designer exports its objects with a working surface mapping. When I assign a Maxwell material to the object, the orientation of the objects look good in the viewport, I would just need to rotate the texture on it and move it to the right position. But in fire the rendering looks different than in the viewport. Why is this? I thought using the mapping channel 0 means, that it takes the mapping coordinates of the object? It also looks wrong if rendered without fire.
Now I added a surface mapping in rhino on channel 1 and changed the texture channel to 1. This renders fine now.

Could you please send me the original mesh that you imported into Rhino? Clearly, the viewport is using different UVs than are given to the plugin by the SDK, but I have no idea how or why that would happen.

Scene 2b - weird fire behavior
With this scene, it takes 15 seconds, to open fire and 30 seconds to close the fire window on my machine. That seems unusually long, given that there is only one texture and one mesh in the file. Is this the same for you?

Was this file perhaps forgotten? I did not find any "Scene 2b" in the download.

Scene 2c - not working?
Is a similar export out of Mavelous Designer.
Starting the same as in 2a, but now I am not able to texture the object at all (it does not show a texture in the viewport nor does it render one) even not with a surface mapping and channel 1 for the texture. Do you have any idea why this is?

I don't see what is causing it, but again, it may help if you send me the original object that you imported into the 3DM.

Scene 3 - restoring missing textures
This really is a weird one, actually not a problem. I'd just like know why this is happening:
I took a file from the server and saved it onto the desktop, used the Maxwell_GatherFilesandMakePathRelative command, saved the file and closed it.
Now I intentionally deleted one texture to create a bad path. When I open the file now by double-clicking on it in the windows explorer, it shows this material with a bad path. When I click render, I get the error message that the texture is missing. But when I just click render again, I get no error message anymore, but the texture is found again!
When I go into the material and that specific texture is it not red anymore but he has relinked the texture, but taken from the old path on the server now instead of the 'textures' subfolder where I deleted it. How does the plugin know where the texture was saved before? And why does he relink it automatically from there on rendering the scene? does that make sense to you?

The intention for this test was, that I am still having problems with files that have missing textures under certain circumstances... I am just not able to narrow it down at the moment.

It could depend on various factors, including your Options > Search Paths settings, and the directories you have visited during the Rhino session. If you open a file in a particular directory, the plugin stores that in a list of "interesting" directories, which are later used when searching for missing files. That is probably what happened here.

[kami]

Sorry, I've been too busy lately to write back earlier. But since these topics are pretty important for the way we are working, I'm having a few questions back:

Scene 1a
So this is means it is a rhino limitation and there is no way to fix it?
Scene 1b
Hmm, I see what you mean with the 2/2 and Mirror XY. It hasn't gotten simpler with the latest version
But I thought it would be just a matter of the order in how these parameters are applied, or is it a limitation of the rhino viewport? Just a relative tiling setting (no realscale) with a repeat 1/3 and a rotation of 90° shows correctly in the texture window, but the viewport preview is wrong. With realscale it gets even more funny:

Neither the viewport, nor the texture preview is showing the correct result. Like that it is almost impossible to predict the result and that means a lot of test renders and wasted time ...

Scene 2a
https://dl.dropboxusercontent.com/u/490 ... lded_3.zip
with Scene 2b I was referring to the same scene file (2a), but it is working fine on my machine now ... no idea what was wrong the last time.
Scene 2c
https://dl.dropboxusercontent.com/u/490 ... lded_2.zip

I hope I am not bugging you too much with all the reported stuff, but I'm constantly thinking of a way to improve how rhino+maxwell work, because at the moment I got the impression that we lose an enormous amount of time due to software problems or a complex workflow that can be very confusing, especially for newer users with many exceptions and not obvious settings.
I think it's mainly the texturing that creates headaches. Especially when the viewport and the rendering output does not match at all ... Usually that means it is necessary to launch a lot of test renderings. Sometimes it is something you only see after you've rendered the image to a higher SL and you lose hours of rendering time.

[JDHill]

Scene 1a
So this is means it is a rhino limitation and there is no way to fix it?

I couldn't say whether it would be a bug or a limitation, I can only say it's something that is occurring outside the plugin's control.

Scene 1b
Hmm, I see what you mean with the 2/2 and Mirror XY. It hasn't gotten simpler with the latest version
But I thought it would be just a matter of the order in how these parameters are applied, or is it a limitation of the rhino viewport?

Limitation would not be an accurate description, it is simply due to conceptual incompatibility. Meaning, try to mimic the Maxwell style of doing Mirror XY + Repeat 2/2 using a texture in Rhino -- I don't believe it's possible, even by applying an explicit mapping to a specific object.

Just a relative tiling setting (no realscale) with a repeat 1/3 and a rotation of 90° shows correctly in the texture window, but the viewport preview is wrong.

I'm not seeing this here -- such a setup works fine both in the viewport & the texture editor. The only cases I know of where there is a mismatch have to do with the use of mirroring, and in the case of the texture editor, rotation in conjunction with Real Scale.

but the viewport preview is wrong. With realscale it gets even more funny:

The only explanation I'd have for this would be that values have perhaps been applied in Obj Props > Maxwell > RS Rotation, but have not yet been exported to FIRE. At least, that's the only way I have been able to reproduce something similar.

Neither the viewport, nor the texture preview is showing the correct result.

As mentioned above, the viewport works properly here, except with mirroring, but the texture editor can't deal with RS & rotation. I am now testing some code that would replace the plugin's use of .NET graphics library routines, for the purpose of overcoming this limitation, but I am not yet sure about it, and it is much slower than the accelerated methods used by .NET. It may make more sense to just stop applying the projection parameters in the preview, and restrict it to pre-visualizing hue/saturation/etc, like MXED.

Scene 2a
https://dl.dropboxusercontent.com/u/490 ... lded_3.zip
with Scene 2b I was referring to the same scene file (2a), but it is working fine on my machine now ... no idea what was wrong the last time.

Scene 2c
https://dl.dropboxusercontent.com/u/490 ... lded_2.zip

I don't find any problem with either of these OBJs; importing either and applying a material using the titel_neu.jpg texture from the Scene 2 textures, I need to use RepeatX -1.0, OffsetX -0.04, and Rotation 90, to map it as I expect it is supposed to appear.

[kami]

Hi Jeremy

Thanks for the reply. I'm as always a bit late with my answer. But didn't look at the stuff in details yet.

This time, I got a new texture error. Both textures are realscale and use exactly the same settings, no other mappings involved.

The objects are imported meshes. One renders correctly, the other one is wrong. When I rebuild the wrong one as a polysrf, it works too ...

The scene: https://dl.dropboxusercontent.com/u/490 ... ne%204.zip

No idea, why it's wrong.
Best, Christoph

[JDHill]

Something seems off there, but I'm not yet sure what -- I'll look into it.

[kami]

Okay, thanks.

I found a new issue: When you use an override material in a scene, but untick the override before you save (without removing the texture there), it disables the override.
But the next time you reopen the file, override is activated again. Can you reproduce that?

[JDHill]

Using those specific steps, no, I can't. Might it be related to linking to an MXM?

[kami]

you mean to a special mxm?

1 - I open a new rhino with the defaul template
2 - select a material for the override (override gets activated automatically) - I tried several different mxm, everytime the same result
3 - deactivate override (leaving the material there)
4 - save the file
5 - close rhino and reopen it
6 - open the saved file again

now, the override is activated on my machine.
If I delete the texture next to the override and save the file, it stays deactivated.

Is this different on your machine?

[JDHill]

Thanks, I see what you mean now -- I thought you were referring to the "Use Override" switch in textures.

[JDHill]

Both of these last two issues should be fixed in the next build.

[kami]

perfect, thanks!
We once spoke about implementing the possibility to control the export check boxes ('Instances', etc ...) via rhino script. I'm not sure if that is implemented yet, but at least the instance check would be great, as we have a script, where we would need to control that.