Revit api materials and textures

[Anonymous]

Hi,

It would be nice if we could create textured materials through the the Revit API.

Thanks

Balazs Gellert

[Anonymous]

Hi,

It would be nice if we could create textured materials through the the Revit API.

Thanks

Balazs Gellert

[jeremytammik]

Dear Balazs,

I fully agree, and we have an open wish list item for this, CF-234 [API wish: apply photo texturing -- 08963731].

Cheers,

Jeremy

[jeremytammik]

Dear Balazs,

I fully agree, and we have an open wish list item for this, CF-234 [API wish: apply photo texturing -- 08963731].

Cheers,

Jeremy

[jeremytammik]

Dear Balazs,

I added a note of your request to the wish list item CF-234 [API wish: apply photo texturing -- 08963731] to make the development team aware of its importance.

Cheers,

Jeremy

[jeremytammik]

Dear Balazs,

I added a note of your request to the wish list item CF-234 [API wish: apply photo texturing -- 08963731] to make the development team aware of its importance.

Cheers,

Jeremy

[arnostlobel]

To all concerned:

We do recognize the importance. This is not the first time an API for material has been requested. However, there is really not a lot Revit R&D can do about it. Though we do have some plans to improve the current material API, there is only so much we can do, for the entire material functionality is pretty much a black box to Revit. All material libraries, its content, the layout and functionality of the dialogs, all are parts of the material component that is developed elsewhere (though still by Autodesk) and shared among several Autodesk products. Sadly, the team responsible for the development of the library has not provided us with an API that we could easily expose to third party developers. That being said, the request for improving and broadening the material API is already very, very high on the priority list. Every user of our Revit API can rest assured that as soon as we get any improvement from the material team, we will make all effort to make it available to everyone.

Thank you

[arnostlobel]

To all concerned:

We do recognize the importance. This is not the first time an API for material has been requested. However, there is really not a lot Revit R&D can do about it. Though we do have some plans to improve the current material API, there is only so much we can do, for the entire material functionality is pretty much a black box to Revit. All material libraries, its content, the layout and functionality of the dialogs, all are parts of the material component that is developed elsewhere (though still by Autodesk) and shared among several Autodesk products. Sadly, the team responsible for the development of the library has not provided us with an API that we could easily expose to third party developers. That being said, the request for improving and broadening the material API is already very, very high on the priority list. Every user of our Revit API can rest assured that as soon as we get any improvement from the material team, we will make all effort to make it available to everyone.

Thank you

[jeremytammik]

Dear Arnošt,

Thank you very much for this helpful clarification.

Here is another description of the dire straits, urgent need and problematic situation:

"We have a large customer with this requirement, and it also affects all others working in the Office Furniture area.

We all need to deploy our materials somehow.

We have more than 1000 materials based on JPG/PNG texture images scanned from the real materials.

We need to deploy this Library to 3 different audiences: AutoCAD, Revit and 3dsMax.

We have been told for years now that the Autodesk Material Library would become the unique repository to all products, but it does not seem to be happening.

We have a great problem right now to give a solid answer to all those customers willing to automatically maintain and deploy their Material Catalogues across those 3 Autodesk products."

Hope it clarifies the urgency and importance of this issue.

Thank you!

Cheers,

Jeremy

[jeremytammik]

Dear Arnošt,

Thank you very much for this helpful clarification.

Here is another description of the dire straits, urgent need and problematic situation:

"We have a large customer with this requirement, and it also affects all others working in the Office Furniture area.

We all need to deploy our materials somehow.

We have more than 1000 materials based on JPG/PNG texture images scanned from the real materials.

We need to deploy this Library to 3 different audiences: AutoCAD, Revit and 3dsMax.

We have been told for years now that the Autodesk Material Library would become the unique repository to all products, but it does not seem to be happening.

We have a great problem right now to give a solid answer to all those customers willing to automatically maintain and deploy their Material Catalogues across those 3 Autodesk products."

Hope it clarifies the urgency and importance of this issue.

Thank you!

Cheers,

Jeremy

[arnostlobel]

Jeremy,

The content of your last post just underlines the essential problem as it had been discussed and stated before. The user states:

“We have been told for years now that the Autodesk Material Library would become the unique repository to all products, but it does not seem to be happening.”

Indeed, it may indeed seem so to a user of those product. In fact, however, all the products do use the same material library (although I am not ultimately positive about ACAD). However, the library is not the problem. The lack of the API for the library is the issue here. Since there is no API for it (yet), our products using the library have two choices only:

1. Do not expose anything or very limited API – this is what Revit has been doing
2. Do expose some home-brewed API depending on the particular product and the needs of its users – this is what perhaps 3DMax has done.

Neither approach is particularly good for the end users. While exposing some API may solve local needs, it imposes problem father down the road. And not exposing anything is, well, the problem itself.

So, again, we (at Autodesk) need to get our acts together. We need to realize that having a good shared material library is good for the end-user, but in order to make it good for all users (those using APIs as well), the library must have an adequate public API that could be exposed and used across products.

Thank you

[arnostlobel]

Jeremy,

The content of your last post just underlines the essential problem as it had been discussed and stated before. The user states:

“We have been told for years now that the Autodesk Material Library would become the unique repository to all products, but it does not seem to be happening.”

Indeed, it may indeed seem so to a user of those product. In fact, however, all the products do use the same material library (although I am not ultimately positive about ACAD). However, the library is not the problem. The lack of the API for the library is the issue here. Since there is no API for it (yet), our products using the library have two choices only:

1. Do not expose anything or very limited API – this is what Revit has been doing
2. Do expose some home-brewed API depending on the particular product and the needs of its users – this is what perhaps 3DMax has done.

Neither approach is particularly good for the end users. While exposing some API may solve local needs, it imposes problem father down the road. And not exposing anything is, well, the problem itself.

So, again, we (at Autodesk) need to get our acts together. We need to realize that having a good shared material library is good for the end-user, but in order to make it good for all users (those using APIs as well), the library must have an adequate public API that could be exposed and used across products.

Thank you

[Anonymous]

Hi all,

I'd like to add another voice to this request, and some comment.

Firstly, I work for a large retailer - we would love to manage our signage in Revit, but cannot due to the lack of things such as face-based parametric materials (ie, auto-scalable materials that react to the size of the object) as the deeply-buried image parameters are simply not accessible. We have about 2,500 different pieces of signage to manage, and the time it would take to hand-code these in Revit is excessive.

Secondly, while in theory Revit / 3DS Max share the same texture libraries, this is not strictly the case. What-you-see in Revit is NOT what-you-get in 3DS Max. Whatever the shaders the Revit uses, these perform horribly in 3DS Max, which means we rely on 3rd party packages such as vRay or 3rd party conversion scripts to make the Revit textures usable. In particular Max's performance with Revit procedural textures is abysmal, as Max appears to convert the procedural textures on-the-fly to temp raster textures on a face-by-face basis. This results in thousands of temp textures that again vastly slow the render process.

There is no clear, straight out of the box workflow from Revit to 3DS Max that gives the same render image when doing a basic Revit -> FBX -> Max -> Render. My interpretation of 'sharing the same material engine' (and indeed rendering engine) is that such a simple export-import-start render functionality should be possible. In practice it takes a *lot* of fiddling to get Max to produce a similar output to Revit.

That said, I would prefer to do all rendering in Revit, at least for stills; the cloud-render capability is a massive time-saver in this regard, and Autodesk is to be commended for getting this aspect working as well as it does. However we are strictly limited by the inability to place the full singage for a store in Revit, which means our renders always look 'wrong' - the signage adds a huge amount of colour to a store. Yes, we could use decals; but it means placing hundereds per store by hand, that are not able to be scheduled, nor can they have the kind of BIM metadata we need to take from the RVT model (order codes, manufacturer, cost, etc.).

For us it is this BIM aspect that is the killer: the signage is the one component of the design that we cannot (yet) easily bring into the world of BIM - at least not if we want the signage to be WYSIWYG.  

[Anonymous]

Hi all,

I'd like to add another voice to this request, and some comment.

Firstly, I work for a large retailer - we would love to manage our signage in Revit, but cannot due to the lack of things such as face-based parametric materials (ie, auto-scalable materials that react to the size of the object) as the deeply-buried image parameters are simply not accessible. We have about 2,500 different pieces of signage to manage, and the time it would take to hand-code these in Revit is excessive.

Secondly, while in theory Revit / 3DS Max share the same texture libraries, this is not strictly the case. What-you-see in Revit is NOT what-you-get in 3DS Max. Whatever the shaders the Revit uses, these perform horribly in 3DS Max, which means we rely on 3rd party packages such as vRay or 3rd party conversion scripts to make the Revit textures usable. In particular Max's performance with Revit procedural textures is abysmal, as Max appears to convert the procedural textures on-the-fly to temp raster textures on a face-by-face basis. This results in thousands of temp textures that again vastly slow the render process.

There is no clear, straight out of the box workflow from Revit to 3DS Max that gives the same render image when doing a basic Revit -> FBX -> Max -> Render. My interpretation of 'sharing the same material engine' (and indeed rendering engine) is that such a simple export-import-start render functionality should be possible. In practice it takes a *lot* of fiddling to get Max to produce a similar output to Revit.

That said, I would prefer to do all rendering in Revit, at least for stills; the cloud-render capability is a massive time-saver in this regard, and Autodesk is to be commended for getting this aspect working as well as it does. However we are strictly limited by the inability to place the full singage for a store in Revit, which means our renders always look 'wrong' - the signage adds a huge amount of colour to a store. Yes, we could use decals; but it means placing hundereds per store by hand, that are not able to be scheduled, nor can they have the kind of BIM metadata we need to take from the RVT model (order codes, manufacturer, cost, etc.).

For us it is this BIM aspect that is the killer: the signage is the one component of the design that we cannot (yet) easily bring into the world of BIM - at least not if we want the signage to be WYSIWYG.  

[jeremytammik]

Thank you!

I added your notes on this to the wish list item CF-234 [API wish: apply photo texturing -- 08963731] as well to make the development team aware of its importance.

Cheers,

Jeremy

[jeremytammik]

Thank you!

I added your notes on this to the wish list item CF-234 [API wish: apply photo texturing -- 08963731] as well to make the development team aware of its importance.

Cheers,

Jeremy

[Anonymous]

Hi Arnost--

Hope all is well!

I too would like to chime in here about this subject. It would be very helpful for our 4D visualization users if we can get some data on textures via the API. We have developed a nice Revit plugin to export data, and this is big hole. I wonder how it is possible that texture data can be exported to DWF, but not via the API?

Have you moved into the new building? Would love to visit!!

-Greg

Greg Demchak  │  Director of Product Management

+1 617 460-1364

14 Arrow St.Unit 22 │ Cambridge, MA 02138 │  USA

Skype: Greg-Demchak-Synchro | YouSendIt: https://www.hightail.com/u/Greg-Demchak

Send your ideas! https://synchroltd.com/ideas/

[Anonymous]

Hi Arnost--

Hope all is well!

I too would like to chime in here about this subject. It would be very helpful for our 4D visualization users if we can get some data on textures via the API. We have developed a nice Revit plugin to export data, and this is big hole. I wonder how it is possible that texture data can be exported to DWF, but not via the API?

Have you moved into the new building? Would love to visit!!

-Greg

Greg Demchak  │  Director of Product Management

+1 617 460-1364

14 Arrow St.Unit 22 │ Cambridge, MA 02138 │  USA

Skype: Greg-Demchak-Synchro | YouSendIt: https://www.hightail.com/u/Greg-Demchak

Send your ideas! https://synchroltd.com/ideas/

[Dale.Bartlett]

Further to all the previous comment, we are in need of api access to directly edit the .adsklib file. I know this is a collection of XML files and stuff, but I haven't unearthed any documentation to explain the structure and relationships; it is certainly not obvious. Echoing previous comments, to create 100s of materials using the application interface is less than ideal. Please help us Autodesk. 

[Dale.Bartlett]

Further to all the previous comment, we are in need of api access to directly edit the .adsklib file. I know this is a collection of XML files and stuff, but I haven't unearthed any documentation to explain the structure and relationships; it is certainly not obvious. Echoing previous comments, to create 100s of materials using the application interface is less than ideal. Please help us Autodesk. 

[Anonymous]

I have a finite set of actual textures the will be used which doesn't change very often (Basically it's just the set of standard steel roofing colours but the specified sheet thickness and coating type will change for each situation.) I also have control over the project templates that are used so I created a set of template materials with structured naming that identify the texture applied. When i need a new textured material I find the appropriate template material then duplicate it and set the other properties as needed. I have built a little framework around this that allows the user to add new template materials also if they follow the same structured naming scheme. I know this won't work for many, but I just thought I'd share my limited workaround for those it might help.

[Anonymous]

I have a finite set of actual textures the will be used which doesn't change very often (Basically it's just the set of standard steel roofing colours but the specified sheet thickness and coating type will change for each situation.) I also have control over the project templates that are used so I created a set of template materials with structured naming that identify the texture applied. When i need a new textured material I find the appropriate template material then duplicate it and set the other properties as needed. I have built a little framework around this that allows the user to add new template materials also if they follow the same structured naming scheme. I know this won't work for many, but I just thought I'd share my limited workaround for those it might help.

[Dale.Bartlett]

Thanks Scott. I'll think about your suggestion to see if it can apply in our case. Dale

[Dale.Bartlett]

Thanks Scott. I'll think about your suggestion to see if it can apply in our case. Dale