We are in the process of building a new material library for Rhino WIP. The library will ship in place of the small library that currently shows up when you add a new material in V5, and will include something like 1000 materials.
Please download it and try it out. Please note that it will only work properly with the Rhino WIP we released last night, so make sure you have an up-to-date Rhino WIP and that you have restarted after installation. This will (hopefully) ensure the material previews work correctly inside Windows Explorer and the Library panel (and the file open dialog).
The materials are all real-world scale, and they should drop onto real-world-scale objects and work without any modification or fuss. The library is designed to complement the new material types - so it’s not full of “green plastic, blue plastic, red plastic” type materials. Use the material types for simple, non textured materials, and the library for photographic texture materials.
To install, just unzip the file onto your desktop. You can drag and drop materials right from the Windows Explorer folder view onto Rhino objects or into the Material Editor. I’d rather you didn’t replace the files in the libraries folder just yet, because we’re going to switch out the old material library soon. Having the new library in place will just confuse the installer.
Please let me know whether it will be useful. Most importantly:
What are we missing?
Are there any materials that don’t seem to work without fussing around?
Is the layout of the folder structure sensible?
and well - and other screw ups I’ve made I’d prefer to know about before we commit this into the product.
Sounds great!
But something is wrong with the link or file:
“Sorry, we can’t find that page.
The page you requested doesn’t seem to exist.
The error number is 404.”
I’ve only poked around with this for a bit, but for what is missing, the biggest thing seems to be vehicle type materials, car paints, rubber, carbon fiber, gel coats.
Architectural\Wall needs Glass block and some tile
There are also no simple metals, such as gold, titanium, cold / hot rolled steel, cortan, galvanized, brushed.
For materials to come in without too much fussing around, it seems this works for a file starting in meters, but for instance if I have an inch file and I insert an oak floor material, it does not come in at all close to a standard I would expect (2.25" wide for oak). I have to create a map for the object I am applying it to or change the material’s WCS mapping size. Also, some mappings come in rotated when compared to similar materials. for instance The textures oak flooring_250_DF.jpg, Strip floor*.jpg, Texture_Floor_Wood_1000_DF.jpg, and Wood floor_1000_DF.jpg (so materials using these texture maps) run in a different orientation that all the others.
I think the general idea of the folder structure is good, but I find a few things a bit odd, mostly in the Architectural folder. For instance:
There is an Architectural\Exterior folder, yet Architectural\Wall is almost entirely made of of materials that are exclusively used in exterior applications. With the exception of the Wood subfolder (which I would call siding), I would consider Architectural\Wall as Masonry.
Architectural\Exterior\Concrete contains almost no concrete, it seems like this should be called Hardscape.
Architectural\Floor\Parquet should be renamed Wood or hardwood, as parquet is a style of wood flooring. It also seems like the Inlay folder would want to move into the renamed Wood folder.
Again, this is only after a bit of playing with it, so it may take a bit to better articulate a folder structure I would prefer, but as it is I find the Architectural folder a bit unsettling, but the others seem OK to me.
Wood\Burs should be Burls
I do have a problem with file naming. The best example of this is in Architectural\Wall\Brick, there seems to be almost no order as to how things are named. I would suggest something like MaterialType_Kind_[Color]_[Condition]_[Channel if texture map, finish if material], so bep222_625_DB.jpg becomes Brick_RunningBond3rd_MultiColor_DB.jpg. Parquet would red dark_1000_DF.jpg would become WoodFloor_Maple_GoldenStain_PlainSawn_D.jpg
I do like the idea of a comprehensive material library that drops in all nice though Kudos on the work undertaken so far.
To add to what Sam already said, I think there should be a Maritime category that include various types of sailcloth. I second the call for a wider collection of machinery and vehicle finishes. And anodized aluminum, which I didn’t see in my quick first pass. I also noticed that there were some things called something about “rivets” that looked to me like diamond plate.
I’m not sure whether the ultimate goal is to have a “one-stop shopping” setup for all materials or whether this thing is intended to always complement the other schemes for the various display and rendering packages. My vote would be for one-stop shopping, should you “choose to accept the challenge, Mr. Phelps”.
Another thought I have had percolating for decades is that a “Material Manager” should include the ability to store other physical characteristics beyond color and light properties. How handy would it be for the interface between designers and CAE if the material spec also included elastic and thermal characteristics. Probably Rhino would never use them but it would be a really great place to manage the data for the various Rhino objects so it could be easily picked off by downstream tools. Probably best designed to have a few very commonly used additional data fields and then be easily extensible to include anything else a user might like. Sounds like a simple database job, doesn’t it? And of course, the SDK (RDK?) to go with it would need to exist.
The simple materials are not there for a good reason - the new material types system in WIP should cover that, because they don’t rely on textures. So you won’t see gold, titanium and so on, because that should be covered in the “Metal” type. Corten seems to be something we might want to add to the “patterned” type.
Sorry about the Architectural bias - you can probably tell which field I’m from.
The textures are named so they can be parsed. You shouldn’t be dealing with textures anyway - remember the idea is drag-and-droppable materials. Not fiddling around with texture files. The materials are derived from the name before the first underbar of the texture.
The comments are great though - we’ll take all of that into account for the next build.
I agree with you about the “Material Manager” idea - but that’s not for this time around. My intention for this version of Rhino is to make it much easier for novice rendering users to get great results.
And that’s the idea of the material library too. I’m not targeting professional renderers - although I’m sure that they will find a pile of the materials useful. Generally, those guys have piles of textures ready to go that they’ve collected over the years (textures are currency in the rendering world). They also know how to build material definitions from textures and other parameters.
The idea, here, is to cover a large range of applications - so yes, Maritime seems like something we’ve missed - and get some easy-to-use-ready-to-go materials for simple-drag and drop into RhinoRender and Cycles. Each of these materials uses the built-in OpenNURBS rendering type (extended a bit for V6) so other rendering engines will be able to support them just as they support the build-in types now.
Again - my intention is not to make professional tools like Maxwell/VRay/Octane/Arion… obsolete. In fact, I’m not considering those much at all. I’m trying to raise the bar at the low-mid end.
True, I shouldn’t really be looking at the textures, I was more doing so to see what each one was when looking at the materials through the Windows Explorer. But I think that sort of gets to my main issue (at least when browsing materials via Windows Explorer), it is impossible to tell what some of these guys are when looking at the spheroid preview in explorer or the file name. Is bep222.rmtl a stacked bond? It looks like it in that preview but it’s 1/3 running bond. This may all be resolved with tags in the material editor, but as it is, it feels a bit hunt and peckish. Part of a strong material library besides having good materials is the ability to find those good materials. I think that is more the point I was hoping to get across.
Andy, I don’t think that beginners need other diffuse/albedo textures than advanced users.
Among the many issues I see, the lack of resolution is most critical, for absolutely anyone. All content smaller than 512/512 could really safely get discarded unless it shows a checker or tiling dots. Most of this is content one could purchase bundled on cheap texture CD’s already in 2000. Such tiny images were designed to perform well on hardware used back then and in the realtime games of that time.
This here is a typical example of a useless texture. The repeatable structure actually is much smaller, but even if it had been cropped to just the necessary tile size its overall extends of 256*256 was way too small (one can see stairstepping in the browser already). If one uses such a texture in realistic scale in a scene pixelation can not be avoided, unless it shows in a dark backyard far away from the camera. The collection contains hundreds of such images.
I don’t agree with you. First up - the people I’m targeting with this library will neither buy a cheap texture CD, nor know what to do with it once they get it. The texture we’re looking at, is, I agree, a fairly extreme example, but remember - these objects are pretty small in world space. I’d certainly rather see a render made with it rather than just looking at the texture - and my guess is you’d have to get pretty close to it to see the pixelation.
Another randomly picked texture. The parquet texture has just 100100px but shows a wood pattern with an extend of roughly 30cm30cm. There’s no way in the world to avoid blurrieness when using such a preview-thumbnail.
A good texture for that purpose would start @512 px square, one might also opt for 1024px to have some headroom for closeups. I don’t intend to cause you work + a bad time but I think customers of any skill level were better served with a far smaller collection (say 10%) of greatly better textures. A lot of such material is given away for free.
I think Holger is right, these textures looks bad at first impression and users should have flexibility to use them for detail work and far away shots. Novices are the ones that need most of the help to get good results. Most of them might not even know that their rendering looks fuzzy because they have a bad texture/image as a building block of their profesionally made material library that shipped with a well regarded product like Rhino. Also most likely they are not part of the ‘currency game’ of textures, nor they should even be, that’s old way of thinking.
BTW, here’s this library’s Ash and Walnut (each 480x480 AND kind of ugly)
here’s Keyshot’s (each 1200x1200 AND beautiful BUT not good for large tiling ):
here’s Modo’s (each 1024x1024, AND beautiful AND tileable):
They go even further for each wood, presenting you with polished, finish, unfinish versions of each wood. And even giving you end grain materials. Also the unfinished versions have separate bump map files:
In both of these cases these are the standard materials that ship with it, no texture exchange, no currency, no secret geek handshake. At think Rhino should do better than those products, or at least keep up with them. You guys have only so many times to make a good impression, and you have used up a few already.
…and so we don’t get academic and religious about this here’s an A/B comparison of the same scene rendered in Modo (my default scene settings) using
A. Modo’s built-in material with their separate bump and diffuse textures:
B. Same Modo scene swapping textures to the 480x480 shipping in this WIP library and no bump (I did not see any bump textures in the library):
I personally think A looks pretty good for a no-effort rendering. And B looks like an OK realtime viewport display, not something from a render engine result.
Rendering the same scene in Rhino for 2m 45s (same as the Modo render A, which took longer than B because it had bump maps) gives me this result:
…so the problems (from people that want to just drag and drop) seem to be beyond just texture.
Speaking of viewport display. The materials (with textures) should look good on the GL viewport, not just in rendering. This is not the case.
Could you please send me the model. I’m not getting results anything like yours.
This is the image we’re talking about, right?
If so, then the colour reproduction in the modo scene is terrible. Far too light.
Looking at your Rhino scene - those are not defaults. Clearly there’s nothing to reflect - because those materials should be reflective. And the model scale seems wrong - unless those bits of wood are a couple of meters across.
Kudos on the work undertaken so far.
