[ricardo]

Hi JD,

Long time no see....

I've been working on a file here and last night I got it rendering and went away.

Today when I got back I turned on a few layers and hit render again.

About half the objects started rendering with the texture that was active on the viewport as color maps. Later I found out that those objects where not attached to their material any longer.

I was able to fix it but I can't imagine what made those material assignments break overnight.

Ricardo

[polynurb]

are you using blocks in any way?

[JDHill]

If you can identify any specific set of steps by which I could reproduce this, I'd like to take a look. Materials are stored by an ID string attached to the Rhino object's string userdata, so it's difficult to theorize about what might cause any specific failure. Also, it would be good to know which version of Rhino you're using.

[ricardo]

Hi JD,

I know I should provide more information. I do have blocks around from visualarq, but I didn't mess with them. And obviously I can't reproduce it.

It's V5 64 bit.

The weird thing is that I did nothing but switching layers on and off between renders.

If it's worth mentioning, I had the perspective view in Rendered Shadow mode and the mxs was rendering pretty much like it.

[polynurb]

i have had much trouble with loosing material assignment lately, but i am very stressed these days and did not find time to document/figure out what was happening.

i also had big trouble with textures loosing their paths, eg. on extracted materials. they are fine once extracted, upon reopen or c&p into another file everything is lost.


sorry for the lack of detail description...
also for various reasons i am still using 2.5 plug in, so i did not want to report on an obsolete version..


daniel

[JDHill]

@ricardo: With blocks and layers involved, there is a relatively complex relationship concerning an object's by-layer, by-parent, or by-object assignment rules. If I were to notice a discrepancy, first thing to do would be to check that the object in question is still assigned as expected in Rhino itself, i.e. if by-object, that selecting the object and checking in object properties, that it has its 'plug-in' checkbox enabled. Ditto if it's by-layer, except that you would check both that the object is set to by-layer, and that the layer's material has 'plug-in' checked.

@polynurb: yes, if you are using outdated code, it would become extremely difficult to diagnose any particular issue with much certainty, unless it were still directly reproducible with the current code. Under the covers, there have been some very fundamental changes in the 2.5+ series of plugins, made in order to accommodate Maxwell Fire.

[polynurb]

, if you are using outdated code, it would become extremely difficult to diagnose any particular issue with much certainty, unless it were still directly reproducible with the current code. Under the covers, there have been some very fundamental changes in the 2.5+ series of plugins, made in order to accommodate Maxwell Fire.

JD i do use the fire version, but not the 2.5.1 version and only the 2nd latest rhino Plug.

[ricardo]

JD,

I had beeing turning layers on and off, but I never assign material by layers. And as far as I can tell all the blocks had already been exploded some time before this happened.

The funny thing is that the objects rendered with the normal maps previously assigned to them as textures. The same maps that where active in the rendered shadows viewport. Then I'd try to select assigned obetcts from the materials window and nothing would be selected.

It's a pitty that panic prevented me from saving a copy of the file before fixing it.

[JDHill]

Yes, this is what I would expect to see if the material ID info had been lost. During export, I would encounter the object, try to retrieve a Maxwell material ID from it (actually from its Rhino material's attribute data), fail to find the ID, and consequently, use an auto-generated Maxwell material for the object. That material would have been derived from the Rhino material -- the one you are looking at in the viewport.

There have been other times during the WIP process where things have become broken here from Rhino's side, so even if you find a repeatable procedure for reproducing it, I would need to confirm that it's not just something temporary which would end up being fixed in the next WIP. Confirming would generally mean: that it is reproducible both on Rhino 4 and Rhino 5; if it is, that is a definite bug in the plugin, and must be fixed.

[ricardo]

Hi JD,

I found two bugged obects left behind in the scene. I ran a pack and go from studio enad sent it to your mw4r4 email

[JDHill]

Thanks -- I got it and will take a look.

[ricardo]

Hi JD,

It just did it again. Is there some pack and go equivalent from within the Rhino plugin?

Then I can send you the whole package.

[JDHill]

Yes, there is a pack and go option in the output tab, but it applies to writing MXS files. Don't worry about that though; all I am interested in is whether or not the material assignments are lost -- no need to send textures and such to see whether or not that's the case -- the .3dm alone would do. In that respect, I have so far not been able to determine anything meaningful from the files you previously sent.

Most likely of all though, no amount of file sending of any kind is going to help; once the assignments are lost, the only thing I'll be able to do with a file is confirm what we already know: that they're lost. I need some clues on when/where/how that happens, whether it's during/after a save, and auto-save, a copy-paste, a specific usage of another plugin, or something of this nature. In the end, it is really Rhino's territory, so even if I can reproduce it, there will not likely be anything I can do about it -- I store some data, and from there, Rhino manages it. If it disappears, all I know the next time I look for it is that there is no data.

[ricardo]

I've started a rendering and left it running for 6 hours. Then stopped it and started messing with the file again.

This time a created a new layer, imported a rhino 4 3dm with a dish washer model and assigned materials to it. Then hit render again.

If you check the object properties, the material name is there. If you right click the material and try to select the objects to which the material is assigned to nothing happens.

I'm emailing the corrupt file anyway.

[JDHill]

The material name in obj props is not a good indicator, since that would remain the same even if the user data were lost. And that appears to be the case -- the material in question has no Maxwell material ID stored on it. Could you send the Rhino 4 dishwasher separately so I can try to duplicate your steps exactly?