Can Rhino export the sub-surface material information somehow?

This is getting weird but I just keep asking for the same basic functionality for years but maybe, maybe this time I’m wrong!!
There’s already per surface material capability I’m sure it can somehow export it.
Can it? Can Rhino export the surface material information somehow?

Moved to Rhino category.

Hello - not that I know of - but Bake may work to make the correct texture map, and you can export that.


I can’t thing of a single reason why neither sub-surface material id or uvw mapping.
At least not a valid one. The one I can think is even kind of disrespectful for the users :frowning.

By all means prove me wrong but I have a feeling you’re not even equipped to perform that simple task. And I’m not implying you don’t have the ability simply that I don’t have the enough people and probably none that understands that meshing subsystem and that just a financial decision that I don’t believe you need to have.

Sorry Pascal and John, and of course it’s not personal, but the lacking of such basic functionality is quite more offensive from McNeel’s part than any of my frustration driven rants.

Even the new SubD and quadRemesh are surely not develop in house.

Prove me wrong please! What could justify this?! :frowning:

Adding support for this is on the todo list:

RH-56447 Obj export doesn’t support sub object materials
RH-59308 Collada: Support per-face materials

Incorrect. Our Subd was 100% developed here.

This is probably 100% correct. Every person and organization has limitations. With every release and service release, we prioritize what we’re going to do. What we do is a tiny list compared to the list of things we don’t do. There are feature requests on our list from the late 1990’s that many of us wish Rhino could do - and it still can’t - because it has never reached the top of the priority list.

This kind if prioritization is true at any organization of any size. I have features I wish Google would implement in their G-Suite products. Surely they have the resources and the talent. But they still prioritize other things, and that’s their choice.

Because we close fewer feature requests than we open, people are often disappointed. We don’t always deliver what they want. That’s why we offer a 100% money-back guarantee. If Rhino doesn’t do what you need, please please return it and use a better product. I’m sure someone else out there understands your needs better than we do, and would be delighted to serve you.

If you choose to keep using Rhino, please know that we’ll continue to prioritize our work in ways that make sense to us. Sometimes, you’ll get what you want. Sometimes you won’t. I assure you, it’s not personal, even if it hurts.


With the guys from TSplines?
But ok, forgive my unfounded suspicions but… so why simple futures lack for decades then?
Is that on a subsystem no one knows how to work with? Is it closed source?
Why is exporting material id or keeping sub-surface texture mapping taking forever to do?
Is it a secondary feature by any chance??

Hi @ruisantosfortes

I think @brian just explained that to you

Also - and I’m no programmer - I think that the concept of “simple features” is something that exists mainly in the heads of us people with no programming skills. What might seem trivial or logical or easy from a user stand-point, could potentially take hours to program, might require changes to core parts of the program or even require brand new functionality to be added. And as it has allrady been pointed out, it’s all about priorities. Requested features and identified bugs are not added/fixed in the order they come in; they are dealt with based on importance, difficulty, internal objectives and available ressources. Sometimes requested features are added within a few service releases, sometimes it takes years, sometimes they don’t get added at all and all we can do is work around it - no single piece of software will do every single job. Just my 2 cents :grinning:
Regards, Jakob

Well, now let’s get hyper specific. What, exactly, do you want to export, and to what file format or program? Do you have an example model, and also an example of what you want it to look like in the target program?

All of these details help turn an abstract request into a concrete task.