Feature Request : Local DB

[Synthercat]

Due to my work I need to frequently use 20-30 special unique mats...

I'd love to be able to use my 3d suite (blender for me)

1) Create a scene and have one material called "Example_1" amongst others.
2) Click "Autoassign materials" [IDEA] on the exporter (or have it as an internal option on Octane [IDEA])
3) Export to Octane
4) When Octane loads up my scene, it looks if there is a "Example_1" on my localDB and (makes a copy of the material on the graph editor if selector "make copy" [IDEA]) assigns a material to all "Example_1" objects!!!

This also helps if you have a database with objects you frequently use like a sofa or a car model. Now you will be able to use it in a whole different scene without assigning materials all over again on graph editor

PS. If I re-export just my .obj with new names the mat-assign changes with new LocalDB materials [IDEA]!!!

IT'S A DREAM THAT CAN COME TRUE!!! [WISHFUL THINKING!]

[matej]

Local DB is one of the oldest feature requests around here. And not something that would take months to code, just a routine that loads a directory tree of. ocm files and diplays it in the same fashion as the Live DB == most of the code is already there.

I never use Live DB, because most materials there need additional work to be usable (so I might as well create the material from scratch). But a Local DB would really help speed up my workflow.

[kavorka]

I agree, this would be awesome. I do furniture renderings and get a lot of the same wood and paint finishes requested, this would save me a lot of time. Plus, all of my assets like phones and computers, ect, would just load up without me grabbing all the mats for them.

What you can do (to save a little time) is make a .ocs file with all your mats in it and load it up in a second window after your other octane window loads, then copy and paste those mats into your new scene (you can select all the one you want and do it as once instead of individually importing them). Still have to re link them but it could save you some time until this feature is implemented (but they have a lot of features that I am sure are more important right now, so I wouldn't expect it anytime soon)

Local DB is one of the oldest feature requests around here. And not something that would take months to code, just a routine that loads a directory tree of. ocm files and diplays it in the same fashion as the Live DB == most of the code is already there.

I never use Live DB, because most materials there need additional work to be usable (so I might as well create the material from scratch). But a Local DB would really help speed up my workflow.

I agree, using the online database is hard, especially since there isnt a material scale node. you never know how their UVs were when they made the materials. Whenever I do use them, it takes a lot of back and forth in Blender to get my UV scale correct.

[matej]

I agree, using the online database is hard, especially since there isnt a material scale node. you never know how their UVs were when they made the materials. Whenever I do use them, it takes a lot of back and forth in Blender to get my UV scale correct.

Scale is the major problem, but there are other things. In some cases textures of the material are not exposed as image node, but integrated into the material node. That makes it impossible or very hard to influence the looks of the material, which makes it's usefulness limited. Some people edit their materials really nicely, exposing scale and other important controls through the macro pins, making the thing useful out-of-the-box. But most don't put much effort in the stuff they upload. In most cases it's just easier to make your own material, than correct the one you downloaded.

Anyway, I don't get it why a Local DB is still not being implemented. All the needed building blocks are already there for the needs of the Live DB functionality (a GUI widget, a loading program, drag&drop functionality, etc..) . They would just need to make it read a file system on the local disk instead of their server.