[kami]

Thank you for the good explanation. The whole database manager is still very new to me (since I had no render jobs over the last 3 month) and I am still trying to understand it completely. The idea behind is good and I think it can save some time if used wisely. I just noticed, that I had to change a lot of materials twice, because I used several rhino instances. But now that I know how it's working I can avoid that.
Cheers, kami

[kami]

I got another question ...
The database manager shows some of my other rhino files as volumes, I suppose those are recently opened files.
I got some old materials in other rhino files which aren't listed. How do I access the materials in those files? (without having to open them and exporting all materials)

[JDHill]

If you see a Volume in the database which is named after a Rhino file, it just means that once when you opened that file on your machine, the Materials inside of it were not yet found in your database. They were then added, and the name of the document was used to name the Volume they were added to. However, the Volume exists separately (as does anything in the database) from any particular Rhino file, and the name it is given is arbitrary - if you also had SolidWorks installed, you would likely have some Volumes which had been created this way and which were therefore named after some SolidWorks file. The point is, database items are not related to documents at all - you can reference any Material in the database from any Rhino or SolidWorks document.

So, the direct answer to the question of 'how do I access Materials which are only contained in an older file?' is simply: open the file.

(referring to SolidWorks may seem off-topic if you don't have or use it, but I mention it to help give a broader view of how the database works)

[caryjames]

I did have something strange happen last week with my database. I had a render running and the power to our area of town went out. My computer shut down and when I got it up and going again my material database had saved everything under the last render's file name and wiped out all my node names. I had a Master section where I saved all my best materials into one node where I can easily find it. Not a big deal but very strange

[JDHill]

While the database does have an automatic backup system that is used every time the plugin is started and shut down, it would still be possible to lose some in-session material or node-hierarchy changes due to a power-outage, depending on when it happened. In any case, it has an ultimately document-centric backup paradigm built into it as well, for exactly the reasons I laid out in my previous post: say that for some reason you had deleted all of your materials; the next time you opened a document, the materials contained in it would automatically be added back into the database. The same would happen with the next document, and so on. So, even in the case of some catastrophic failure, the only materials you could really lose permanently would be those which were not actually used in any of your documents.

[kami]

thanks JD,
I was hoping to speed up the process of having to close my actual file, reopening the other one, close it again etc. (since my files are often over 100mb, it takes a lot of time)
But once i've found the time to organise my old materials, that problem will be gone.
greets, kami

[kami]

I'm warming up that thread, since I still have my problems with the material system ...

Two kind of problems occur:
While working on a new project, it happens quite a lot that I need an object (furniture) or material from an older project. The fastest way to get this is to copy&paste the object from the other rhino file. Afterwards the materials often needs to be modified (color changes, etc). By changing it, I screw up the old model/material as a consequence. If I don't need to change anything it works fine this way.
The other problem occurs when I share a project with a co-worker and we trade rhino files including materials. If I create or load any new materials I put them in a sub folder to the rhino file. By sharing, I copy the whole folder to the other machine. So all new materials work fine, but the ones copied from older projects are without textures.

Am I missing an important feature? Or can anybody suggest an improvement to my workflow which doesn't create too much effort? It's not a problem of the plugin, is it?

greets,
kami

[JDHill]

The design of how the database manager works has some deficiencies when it comes to sharing files across machines, and I'm changing how it works with materials to alleviate those. What you would want to do in the case of copy/pasting Rhino objects would be to clone the materials used on the pasted object and replace the assignments with the cloned versions. You could then remove the originals from the scene. If you don't do something like this, then when you modify those pasted-in materials, you are going to be modifying the same ones used in the source file - they live in the database; they're saved in the document too, but only used as backup when they're not found in the database when you open up a document.

On texture paths, have you tried using the plugin's Relocate Paths feature, found under Scene Data Management in the main menu? This feature is specifically designed to help you package up everything used in the scene in order to move it to another machine.

[kami]

thanks for the answer JD
I did not know about the relocate path feature but I'll try it the next time.
About the cloning of materials. In my opinion it could be more clear when you change a material which is used elsewhere. Since I'm not always alternating every material, rhino could at least warn me, that I'm changing a material used elsewhere (which hasn't been cloned). So I'd only have to clone the ones I change. Manually cloning every texture works fine for objects with two or three materials but gets pretty time-consuming if there are more materials used.
Or wouldn't a switch be a useful idea, where you can assign materials directly to files so that they are automatically cloned while copying the parent object to another file.
Just my few thoughts on a steadily improving plugin
cheers, kami

[JDHill]

Problem is, there is no possible way to know if a material is used elsewhere - there are an awful lot of Rhino documents out there. The case is that it works this way on purpose, the need for automatic cloning being exactly the thing it means to avoid. This is because there are many to whom the ability to change a material in one place and have the changes appear elsewhere is very very valuable. If it doesn't work that way, you run into many other issues when you are dealing with documents linked in as block references and such. But it's not flexible enough to deal with the way you want to use it, which is why I'm changing some things.