[kami]

Hi.

Is there any document which describes how to use the database manager?
I can't seem to understand the concept behind it, which lead to some problems... e.g. while changing materials for one file, the material got changed for several files, or I had to rechange the material after I reopened the file.
There are some nice explanations for texturing (realscale) etc. but I cound't find anything for the database manager.


Thx,
kami

[bjorn.syse]

I too found this component very hard to understand intueitively. Perhaps I could understand it if I read the manual, but I'm not much for reading manuals when it comes to understanding interfaces. I think they should be able to grasp more direct...

[JDHill]

@Kami: That's the intended behavior - the database exists outside of any document, precisely so that you can modify a material and have the changes be seen elsewhere. This is an important concept which was lacking in the previous versions and would cause difficulty when working with blocks and such. There is a page in the manual which explains how it works, and this may be found under main menu > Maxwell > Help > Database Manager.

@Bjorn: could you say exactly what you found to be confusing? Because, I can try to improve it, but I don't personally understand what's confusing - it's basically modeled using the same concept as a normal file system. I figured this was a good model to use, as it should already be fully understood by most people.

[bjorn.syse]

JD. I see, well, I guess the problem might just be I haven't tried to understand it enough to really know what I find confusing. I just looked at it and figured something in the line of: "Whoa, that's a lot of small buttons I haven't seen before, that's heavy".

But then again, perhaps I just don't need the function, since I haven't been experiencing any of those problems your mentioned before.

In my workflow, I have a material database (folder in the file system) from which I import the mxm:s I need into the Scene materials tab in the Scene managaer. I guess that does it for me.

- Björn

[JDHill]

Thanks for explaining. If you always drag MXM files into your new models, you could just as well forget there's any database manager at all, since each time you drag in an MXM, it creates a new material. In effect, using the plugin this way is the same as not using any database, since each material in your database is referenced by, at most, only one document.

You may eventually want to look into how it (the database manager) works a bit though, since it offers alot more functionality than just holding materials - you can drag individual BSDFs, displacements, textures, etc., from the Material Editor into the various other pages, then drag them back out into new materials as you build them. However, if you mostly just use MXM files you've gotten elsewhere, rather than creating materials from scratch, it's not likely that you would find this to be too useful.

[bjorn.syse]

Ok, cool, thanks for explaining aswell. I guess I could have read the help file or somehting

That might come in handy then, I'll look into it.

- Björn

[NoahPhense]

I have a couple questions about the DB Mgr ..

If I edit the materials that are located in the DB Mgr, will the end up editing
the actual MXMs?

Also, can the DB Mgr be used to just store variances of Materials, or in the
end, will the DB Mgr have to place MXM's back to the disk?

- np

[JDHill]

No, editing a material in the plugin has never affected whichever MXM file it may or may not have been created from. The material editor has a command in its menu which allows you to re-save (Update Source MXM) how the material currently looks back into the MXM file it was created from...if it was created from an MXM, and if that file still exists on your machine. If both of these things aren't true, you will not find that command in the menu.

[bjorn.syse]

So where are the materials in the database manager stored, if not in their original mxm's and not in the scene?

[JDHill]

They're stored (a) somewhere I can guarantee the existence of regardless of the machine the plugin is installed on, and (b) somewhere I can guarantee that the plugin will have permission to write files. So, this is the user's AppData folder, wherever that might be located - you can find the actual location on your machine by looking near the top of the Log Viewer in any given session.

[kami]

thx JD
I'll have a look at the document and play around with the new plugin a little more and then try to phrase what's left of my confusion

[kami]

back again with a question:
what happens if I got several sessions of rhino opened and i change something in the material database in one document? and something else in another document ... will this cause problems?

[JDHill]

It shouldn't be a problem, though that depends a little bit on what you mean by problem. The last instance of Rhino that you close will be the last one to save the state of its materials back into the database - really no different than if you set a bunch of user preferences in two instances and then closed them - the last one closed would 'win'.

[kami]

Ok. Just like the position of the toolbars as well. But if I change two materials in two document, the material change made in the first document would be lost then?

[JDHill]

Yes and no. Materials are only loaded on a volume-by-volume basis, as you access them. So if two instances of Rhino open two documents, and those documents use materials in different volumes, it would be possible to edit materials in each one without overwriting changes made in the other. However, there is only one database tree, and it will be saved by each copy of Rhino when it closes. If, with two Rhinos running, materials are added in document A and it is then closed, and then the second document, B, is closed, the tree will be saved without the new materials added in A. That would be a problem, but each Rhino document also gets your materials saved directly in it, so the next time you opened Rhino, though you would see the database tree as it was the last time it was saved, without the new materials added in document A, as soon as you opened that document, you would see the materials you were 'missing' being brought into the database under a node named 'A.3dm', as they are read from the document when it is opened.

In the end, working across two instances is not the preferred method - none of this would be any issue if Rhino used a multi-document interface, but as it is, each instance of the plugin is running in a completely different process and they are not able to communicate with one another (i.e. they may as well be running on different machines). That being the case, you will want to adopt a different strategy if this is your primary workflow - use MXM files and import copies of them into each document, so the materials in each document are independent of one another. In other words, basically ignore the existence of the Database Manager and use only the materials browser in the Scene Manager - the plugin will still maintain the database in the background, but you will not see the effects of it - each document will be using different materials.