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.
RevitAPI: The given value for name is already in use as an appearance asset name.
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.
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:
The …PosEG-22-011… material exists (for Level EG)
The …PosEG-22-011… Appearance Asset is correct in Revit
That the Extract Material’s AssetsData 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…
Did the Tracking modes for Create Material and Create Appearance Asset exist before v1.0?
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.
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.
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.
@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:
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.
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).
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.
