[JDHill]

Sure, I'll take a look. We're not sunk yet though...can you confirm the following:

1. before you hit restore viewport, the plugin has already read the textures. You can know it has done so by seeing that there are thumbnails in the material editor. Did a lag occur when the plugin created the thumbnails, or does it only happen afterward, when using restore viewport? (I am trying here to determine for sure whether it is the plugin or Rhino that is hanging up)
2. select one of these objects (after using restore viewport, so the textures are loaded and showing), go to Object Properties > Material, switch to 'Basic', and note the texture path - it looks as you would expect, right?
3. set current renderer to Rhino Render, close Rhino, re-open, draw something, and then set the same path in a regular Rhino material. Is there a lag?
4. save the test document, close, then re-open. Is there a lag? Does the texture show up in the viewport?

Lastly - do you see any difference if you set the plugin option 'Disable Material Environment' to Yes?

[bjorn.syse]

I'll have a look on these tomorrow, got to go.

- Björn

[JDHill]

The textures work fine here, fwiw.

[bjorn.syse]

That is very weird. I have this very same problem on 3 different machines (two XP and one Vista).

I've used the textures in coalition with Real scale, and a few objects have had their projections rotated by using the .'Real scale texture control' in 'Maxwell Object properties'. How about if you try that?

Here's the very material I've been using:

http://dl.getdropbox.com/u/114792/wood% ... lan%29.zip

To answer your questions:

1. If I open rhino with both 'Restore viewport on load' and the 'Enable real-time viewport materials' disabled - and then open the file - it opens right away. The thumbnails in the material editor are there and appear without a lag.

2. Just so you know, the textures are showing both in the material editor and in Rendered preview/viewport before I even use Restore viewport aswell?.. But yes, the texture path looks like expected.

3. No lag when setting that texture path to a 'Basic' rhino material, nor when setting it or when switching to RenderedViewport.

4. No lag here either. The texture shows up allright.

I allways have 'Disable Material environment' set to Yes, but there is no difference when switching it to No either.

Btw, I tried to create a new Maxwell Material, single BSDF and used the texture for Reflectance 0. Put this material on around 15 cubes (test object) and everything behave as normal.

I will continue to try to look into the bad model to see if there is anything strange. Not sure what it could be though... I've removed all block definitions using purge, there are no "bad" objects or anything..

Just let me know if there is anything else I can do or try to help.

- Björn

[bjorn.syse]

Next test:

I cleaned the 'bad' file from all maxwell materials, and set all to 'By Layer'. Then I created new maxwell materials using the same textures, and everything seems to work fine.

Next, I tried to import the same .mxm files i used before and assign those instead. Maxwell_RestoreViewport worked, but when I closed the file and re-opened it, and did another Maxwell_RestoreViewport i got the following:

Code: Select all

A 'System.AccessViolationException' has ocurred in 'Rhino_DotNet'
*******************************************
Exception report.
Type: System.AccessViolationException
Message: Attempted to read or write protected memory. This is often an indication that other memory is corrupt.
Source: Rhino_DotNet
Has StackTrace: True
BEGIN STACKTRACE: 'System.AccessViolationException'
	 - at RMA.Rhino.MRhinoObject.SetTextureCoordinates(IOnTextureMapping mapping, IOnXform object_xform, Boolean bLazy)
	 - at Maxwell.Rhino.mxRender.ModifyMapping(IRhinoObject obj, TextureBase tex, Double factor, Int32 proj, MRhinoTextureMappingTable table)
	 - at Maxwell.Rhino.mxRender.CreateRhinoMaterialFromTexture(OnMaterial& RhinoMaterial, Material MaxwellMaterial, Boolean isImageBasedEnvironmentMap)
	 - at Maxwell.Rhino.mxRender.CreateRhinoMaterial(OnMaterial& RhinoMaterial, Material MaxwellMaterial, Boolean isImageBasedEnvironmentMap)
	 - at Maxwell.Rhino.mxRender.RestoreViewport()
END STACKTRACE: 'System.AccessViolationException'
Has InnerException: False

*******************************************
The purpose of this dialog is to collect information about the error which has just occurred, so that it may be sent to the support team for diagnosis.

Use the space below to include include any additional details about this issue which you feel may be useful:
*******************************************
Additional Details:
*******************************************



*******************************************
The following information will be sent, as well as the contents of the Log Viewer. Although you are completely free to remove any portions you are not comfortable sending, it is recommended to send the whole text, to aid in diagnosing this issue.
*******************************************
LOG_REPORT [TYPE=EXCEPTION] [ID=9716]
*******************************************
Operating System Info:

OSFullName: Microsoft Windows XP Professional
OSPlatform: Win32NT
OSVersion: Microsoft Windows NT 5.1.2600 Service Pack 3
ComputerName: SIGNE2
UserInteractive: True
BootMode: Normal
CLR Version: 2.0.50727.1433
DebugOS: False
CurrentCulture: en-US
CurrentUICulture: sv-SE
SystemDirectory: C:\WINDOWS\system32
*******************************************
Machine Info:

ProcessorCount: 1
TotalPhysicalMemory: 1610141696
TotalVirtualMemory: 2147352576
AvailablePhysicalMemory: 603721728
AvailableVirtualMemory: 1375985664

However, when I tried again, i did not get this exception but just the very long wait when using restore viewport. Is there something wrong with my materials, or with the way the plugin handles materials that are imported?

[bjorn.syse]

Perhaps it's a performance thing?

I tried the following:

1. Create a test object, and import the 'bad' material. Restore viewport is quick.

2. I create more test objects, and copy these so I have around 1200 polysurfaces. Some of these I change the real scale texture control for. Restore viewport takes forever (a minute or two)

However, If I create a similar material within rhino, and assign the same textures. Restore viewport is very quick even if a few objects have had their real scale texture control changed. Even if I export this material, and later use import to assign it again to all the objects, there are no problems.

These original .mxm files could have been created in Maxwell studio on OS X or perhaps in the stand alone material editor.

- Björn

[JDHill]

Okay, firstly, the error you posted - that's from inside Rhino. When you do things with the plugin, it's very much the same as if you did them yourself, except that it does them many thousands of times faster. So, for the plugin to catch something that would have crashed Rhino had you been doing it those thousands of times is really not too strange. Nine times out of ten when you see that error dialog, this is the case.

That aside, having the plugin build Rhino materials for 15 objects is a whole lot different than having it do so for 1200. If I test with 1200 objects, all using the same textured material then I can see a lag too. Further testing on this has revealed a special case that I can optimize for the restore viewport vs. hundreds of textured objects scenario. I don't see any reason why you would ever see a different behavior with an mxm-derived material than you would with any other one - once they're in the scene or database, they are all the same kind of thing.

I think the best rule for now, in this specific case, would be just not to run with Maxwell as the current renderer. It doesn't need to be, and you can prevent the restore viewport command running without your input by doing so.

[bjorn.syse]

Cool, for now, I won't keep maxwell it as the current rendered. But apart from the performance thing, I think there might still be something strange going on with these materials, since I don't see this lag at all when using materials created within rhino. Don't you agree?

Are we certain there is no possibility of compatibility issues between .MXM files created on different platforms and their respective paths.. ?

btw, will I be able to see the texture rotation change when I change the values in the 'Maxwell objects properties' without having this Real-time display / restore viewport active?

- Björn

[JDHill]

Yes, you should still be able to use that. I think the only things that change when the plugin is not the current renderer are:

- no automatic restore viewport when documents are opened/imported
- no automatic restore viewport when a material is imported and used to replace another material of the same name (maybe you've seen this dialog, maybe not, but it's something the plugin can do)
- the plugin will not be given the regular Render command (obviously, since it's not the current renderer), so AnimationTools will not work
- when you resize or modify an object with real scale mapping provided by the plugin, it will not automatically update in the viewport

That should be about it, and you can probably see the theme - the behavior is changed because the plugin is assuming you might have done work with another renderer, and it doesn't want to alter the viewport without your permission. When it's current, it assumes the opposite. The workaround for the last item would simply be to 'touch' the rotation controls after modifying the object, i.e. roll one of the axis rotations up a bit, then back down - since you're directly changing things via the plugin's interface, it assumes you want the changes to be seen regardless whether it is the current renderer or not.

On the theory of incompatible paths, it may help to answer your question if I describe what happens when you import an MXM. There are only two possiblilities:

1. the texture paths in the MXM already point to valid paths on your machine, so nothing is done
2. they are not found, so a search is performed. The basic routine (let's use a theoretical bad filename /Users/some_osx_user/Documents/textures/some_tex.jpg) is:

• a. isolate the filename from the path - so now we're just using some_tex.jpg
  b. search under the directory where this MXM is being imported from
  c. search directories specified in plugin options for files with this name
  d. search additional directories that have been added during the session

If, during searching, a file named some_tex.jpg is found, the search is stopped, and the filename and path will be combined together to look something like C:\Users\Björn\Documents\downloaded_mxms\some_mxm\textures\some_tex.jpg -- it probably looks like this, having been found in a folder you got with the downloaded MXM. You could easily confirm this either by looking in Object Properties > Material > Texture, or by exporting an MXS and opening it in Studio.

So, you can see, importing an MXM using the plugin will effectively 'clean' any bad path location or notation which may have been present in the actual MXM file you imported. From that point on, the material is no different from any other, and it should actually be perfectly identical to one you would create yourself. If you still thought you saw a difference in how they performed, you would first need to make absolutely certain that the tests you were using were really identical, and that you weren't accidentally adding any other unrelated factors into the mix.

[bjorn.syse]

I see, so even if this search is what is taking time, it should only happen the first time I import a material and not after, am I right?

I'm not sure, It was a quick test. I will try to repeat it the next time this issue makes me go crazy. Right now, it seems to be behaving itself

but, I'm confused here. What was the issue, and how can it be fixed? Was it a performance issue with the Restore-viewport command?

[JDHill]

Yes, the search will only happen in the course of creating the new material - once it's created, the paths are all either fixed up, or invalid. About the performance of Restore Viewport, yes, the problem (and the resulting optimization) is very specific to that command and the way that it traverses the document. It should be seen in only a very specific scenario:

- there are many objects (i.e. hundreds) which use the same material
- that material has a texture active in the viewport
- that texture uses Real Scale

I had to change the way objects and materials were being looped over in the Restore Viewport code, because with all of these conditions being true, and specifically when running that code, an outer loop caused an inner loop to be called on each iteration when it really did not need to be. This results in the time taken being squared, based on the number of objects invloved. This would not have been an issue in any plugin prior to the current one, where the plugin is providing Real Scale mappings in the viewport. Being very specific in nature, this new side-effect was not detected until I was testing to determine the cause of the issue you raised in this thread.

[bjorn.syse]

Wow, so that was really a hard to spot achilles heel...

btw, when you say, that material has a texture active in the viewport - do you mean that the viewport is in 'rendered mode' ? because, I think this happened when all viewports were saved in wireframe mode, and then the file was opened aswell?

So, cool. I'm glad you found it!

[JDHill]

It does not matter what mode the viewport is in - that is not known by the plugin. Basically, what I mean is that if you take the same material and un-select the texture by selecting an empty one, so that the viewport would be showing the object's color rather than a texture, then you would avoid the issue.

[bjorn.syse]

Ah, ok, then it makes sense again.