Appearance Asset and Extract Material's Assets in v1.0

Were there major changes to the way Create Appearance Asset and Extract Material’s Assets work for Rhino.Inside Revit v1.0 and Revit 2019?

I notice that the Create Appearance Asset throws two errors if the asset already exists.

  1. RevitAPI: The given value for name is already in use as an appearance asset name.
  2. Transaction RolledBack and aborted.
    -The component processed existing Assets in the more recent WIP without error.

My work around was going to be 1) create a new material then 2) refresh the Query Materials component and 3) Extract Material’s Assets but the Extract Material’s Assets sees the list length of the current query, but the Materials ID of the previous operation. See this image, and the actual Revit Material in the following.

Something inside Extract Material’s Assets appears to not be working right…
Does anyone have a clue how to proceed? I will try a restart first…

Yes there are definitely changes from the recent v1.0 to WIP that affect this workflow.

I’m not quite following the Extract Material Asset question. Is this in the 1.x or 1.0?

v1.0; I installed the first release but not yet v1.1.

It is tricky to explain: thanks for being patient with me…Simply put, the Extract Material Asset component AA data out it is totally different than the data in.

  • Data In into the Query Material shown in the photo is for level EG (…PosEG-22-011… circled in red)
  • Data Out of the AA output of the Extract Material’s Asset component shown in the photo is for level U1 (…PosU1-22-001… circled in red)

I ran data for Level U1 before moving on to Level EG. The Appearance Asset Data Out is from the most recent data stream (ex: Material data for elements on Level U1), but it is super confusing that the list length is the same as the Data In.
The second photo just confirms that:

  1. The …PosEG-22-011… material exists (for Level EG)

  2. The …PosEG-22-011… Appearance Asset is correct in Revit

  3. That the Extract Material’s Assets Data Out in Grasshopper does not match #2, the correct data showing in Revit.

With this workflow, I am not sure how to write the Material data to elements created further down stream in the script. Is it a bug?

@japhy, I see now that the components are reading the Asset Appearance data correctly but that tracking is related to material creation (and deletion) and it is not clear how to access existing Asset Appearances. Here is my broken workflow.
a) I enable the Create Material component
b) I create a new Asset Appearance and modify that AA with the Modify Appearance Asset (Generic) component.
c) I switch the input (data for level U1 to data for level EG).
d) A new material is created but the Create Asset Appearance component is picking up name data from the previous Data stream and I do not know what to feed into the M-GA

  1. Did the Tracking modes for Create Material and Create Appearance Asset exist before v1.0?
  2. Would Create Appearance Asset overwrite an existing AA before v1.0? Also, I now have troubles with Create Material in v1.0; now it writes a new Material if one by the same name exists.
  3. Do we have a Query Appearance Asset component where I can grab an existing AAs?

In v1.0, it seems that I get only 1 opportunity to create and assign an Appearance Asset.

Tracking was new to all Add Components in v1.0, disabling Element Tracking in an Add Component will revert it to Pre-v.1.0 (where you will get a warning that material has same name)

I think you need a Template Material that will serve as a holder for your Existing AA.

Query Materials with a Extract Assets is essentially a Query Assets, no?

Actually, no. Query Materials with a Extract Assets is essentially a Query Appearance Asset assigned to that Material. An Appearance Asset can exist without being assigned to a material.

If in fact the Create Appearance Asset cannot overwrite an existing asset by that name, I would want to have access to the list of assets available in the file (shown in the this image, where I would go to assign them manually).

There are about 300 materials, with 300 unique assets for 300 elements, and the JPG asset changes as the design is developed (means that I update the assets every couple of weeks). This update process worked ok in the WIP, but now cannot update in v1.0.

Can I query available Assets in the file? If so, I can assign it to the matching Material.

Gotcha, creating an Class filter will get you the Appearance Assets for the document.

1 Like

@Japhy Thank you very much!

My apologize for the long-winded explanation; I was learning about how the class elements were structured and when I started, did not really know what I was asking for.

1 Like

@japhy, One more question about the Create Appearance Asset component in v1.0:

It seems that I can feed a new list of Names to create new assets but, if any-one of those names already exists, no new assets can be created .
Is this correct?

Hear is what I want to create; index 10 already exists:

And if I isolate the new assets, they can be created:

Could it be that Create Appearance Asset in the WIP would create assets if they did not already exist and skip assets if they did?

That looks like a bug, will the replace tracking mode work in this case or are you editing the asset after?

I cannot say if the replace tracking mode makes a difference but my tracking mode is disabled here.

In v1.0, I have to first check Names for existing assets, then feed a unique, none existing Name list to Create Asset (new assets); next I step back in the script, reload my Asset Query and move forward to apply the assets to the correct material. Assets are edited and applied after these steps…
The extra steps were not necessary in the WIP: I could create, and recreate my Appearance Assets as many times as I wanted; previous versions were ignored or overwritten, I never noticed.

Seems that Create Asset (and Create Material too) could easily run an if-then statement rather than toss the whole basket for one bad apple.

The Update Tracking mode will maintain the appearance asset name, its element ID, any changes made via the Revit UI. *currently bug in the name

The Replace mode will replace the asset, keeping its name only. *works fine

Tracking Mode disabled will fail with a same name.

Were you able to test these scenarios?

I ran it only in disabled mode because the component will not write any assets if any one asset already exists (in any mode I think).

Yes, tested and submitted a bug report. The only thing to note is that i’m in the daily build and revit 2022.

Thanks for all your help :smiley:

When running my script again this week to make design updates, Add Material with tracking disabled would remove materials assigned to families instances I placed sometime last week.
It was a very strange effect.

In the end, I deleted the Add Material component, added a new Add Material component with the default Tracking Mode Reconstruct, synced the Revit central model, and ran it all again a few times before it would create the new materials.
Having material components enabled also causes a delay in the canvas redraw when bringing a new panel in, for example; the wheel spins until the Query Materials component can recalculate.

Following the operation above, I placed new instances placed with Add Component (Location), tracking disabled, and assigned material parameters with Element Parameter; these two components got caught in a repeating loop until I could interject and disable the solver.

The result was multiple instances of the elements overlapped and the loop behavior repeated every time there was an error in the data (I think I forgot to add the correct element parameters to the family before trying to write the data into the Shared Parameter).


Please test out the latest Daily Build’s Error Mode (1.6.8082.16834)

Default is Skip (top in image below)
Continue will use existing Named Elements such as Appearance Assets

There is a Query Appearance Assets since v1.4.

Super cool!
Thanks @Japhy !
Thanks @kike !

Generally, we get many errors when working with crappy Rhino geometry (geometry not related to this example, but in general). Revit does not like small faces or badly modeled surfaces.

We know the rule garbage-in = garbage-out, but I thought you’ll like to have the feedback.


1 Like