Set material to mesh with detail

[fabre.cedric]

Hello,
I have many problems to migrate our project APCRender+ from Unigine 2.14.1.0 to 2.15.0.1.
For exemple, I try to apply a material to a ground with a detailmap... In the unigine editor that was perfect but in c++ the detail doesn't appear ? (see sample please).
I have many difficulties because the function to "get material by name" doesn't exist now and in xml format the "name" doesn't exist too and all materials of APCRender+ use the name like this : name="apc/Soils/External Soils/Pavements/Stone Pavings/Cobblestones/Fan/CobbleFan 001" for his categories, traduction, set to surface and other functionnalities :-/ .
Why have you broken the material system and not have developed a new format with preserving the previous ? Like a mesh_base2 for exemple or other.
There is many work to review all the source code of our software to be compatible to the new version...This is really complicated.
Thanks

Objects.zip

[silent]

Hi Fabre,

Thank you for the test sample, we will look into it first thing on Monday and will see how we can help there.

Materials migration in 2.15 indeed touched a lot of things, but we tried to minimize impact of it. Unfortunately, we couldn't keep the old materials alongside with a new ones since the core API is changed a lot and having 2 conflicting material systems would take a lot of time in support and would shift the release even further.

Most of the changes for material files are described in this post, maybe it will be helpful: 

[sweetluna]

Hello Fabre,

if you've used mostly base materials and manual materials you can access them via Materials::findManualMaterial or any material by it's full path with Materials::findMaterialByPath.

We removed inherited material names because of possible naming collisions and could've resulted in bad situations. As the result only manual and base materials have their names via Material::getManualName. Also we added namespaces for more control over possible hash & naming collisions.


ULON Base Material File Format - Documentation - Unigine Developer.

Regarding not having details in the runtime, it's seems like a known bug.

Hope this helps you!

[devrom]

Hello,

we are currently in the progress of migrating and also have multiple problems with materials because we sometimes relied on the materials name.

Quote

We removed inherited material names because of possible naming collisions and could've resulted in bad situations.

Indeed the usage of strings for caching and matching materials can be problematic. This is a logical change of functionality.

Would it be possible to use GUIDs for internal functionality and still offer the material name as simple data member? If you do not use the name for caching there obviously will not be any conflicts. I would compare this to nodes having an ID and a name which does not have to be unique. The purpose of this being that a name can actually be useful for human users. This could also help some people during migration.

Example use case

1. Generate a lot of procedural geometry and materials in place A
2. Save a procedural node with all of its materials to disk in place B

How am I supposed to save the materials to disk with a meaningful name if all I have are material parameters and a GUID? It would be convenient to store the name during creation to later identify the material again.

Best regards

 

Edited January 24, 2022 by devrom

[silent]

devrom

I guess you can use getMaterialPath() and basename from this path would be your filename. Will this approach work for you?

Thanks!

[fabre.cedric]

I'm wrong or now MaterialPtr->getPath return the guid and not the path of material ?

[silent]

Yes, you are right. How to get material name you can check in this forum post: