As per the title really - in Revit Assets come through with type-based parameters:
EnscapeAssetId
EnscapeNativeAssetHeight
which we, as authors, can introduce to our own content to make any family redirect to an Evermotion asset when in Enscape = which is great! 8)
However, sometimes, having this “locked” at a type level isn’t ideal (use case example: appearance and size swap-outs of more-commonly instance-based items like trees)
Switching/employing the parameters in a family on an instance-basis doesn’t appear to be recognised by Enscape - and I was wondering if this could supported please?
Pardon, could you kindly elaborate on how you’re switching / employing these parameters? I think I followed the same procedure like you when I tried it myself, but just to make sure. 
We can’t upload .rvt files?
@snowyweston , pardon, not yet! Can you briefly upload the project to wetransfer.com? I’ll get together with our corresponding department to discuss more about the ability to allow you to also upload projects accordingly. Alternatively, you can of course also zip the file.
Mega old thread but surprised I couldn’t find many other discussions around this topic (as it appears to still be a limitation).
Revit family files have the “EnscapeAssetId” text parameter, which reports the GUID and presumably tells Enscape what asset to render. This parameter is Type based, and if it’s changed to Instance based then the link is broken and Enscape no longer renders the asset.
We have generic families that are heavily instance based. Users should be able to use different id GUIDs on an instance basis, without the parameter having to be Type based.
Is this a known limitation and/or is it something that can be updated? It would be a pretty significant improvement in terms of allowing users to link Enscape assets to their own Revit family files.
In the interim found an acceptable solution by nesting in a shared family (with an EnscapeAssetId text parameter - Type based) and linking it to a Family Types instance label.
It means the nested family can have multiple types preset or duplicated in project, each with a unique AssetId, and then the main Parent family uses the drop down Family Types instance selection to freely swap between these empty families i.e. swap between different AssetIds.
Is there a reason that the AssetID has to be a Type Parameter? Seems like it should be something that is easily read regardless of if it’s an instance parameter or type parameter?
We would very much like to be able to change the AssetIDs for some of our Revit families without having to create a new Type for every variation.
Hi @na_na11 and @Grey_Block (and @snowyweston ,who started this a long time ago),
thanks for bringing this one back up, and sorry that it went silent for so long. We looked into it with an internal Revit user and now understand the pain: every variation of an asset in Revit means a new type, and the instance parameter route breaks the link to the asset. The need is clear to us, both for your own families and for vegetation of different sizes.
We will take this with us and check with our developers what it would take to read these parameters on instance level as well. No promise at this point, but I will come back here when we know more (we can already see there are a few cons of changing this). @na_na11, thanks for sharing the nested family workaround, I hope this helps others in the thread in the meantime.
Hi na_na11, Grey_Block and everyone following,
a short update, as promised. We checked this with our Revit developers and the ID part is doable: for your own families, Enscape will read EnscapeAssetId from the instance when it is there, and fall back to the type as today, so existing families keep working as they are. No date yet, but it is on the plan. I will update here when it is released.
One thing we will not change is the Height of our own assets. I must be honest here, this is a Revit limitation, not our choice: the proxy you see in Revit can only scale through the Planting category Height, which is a type parameter in Revit, and making it per instance would break the match between what you see in Revit and in Enscape.
