topic Re: AVF colored surfaces require a surface? in Revit API Forum

AVF colored surfaces require a surface?

MattKincaid — Thu, 01 Jun 2017 21:13:30 GMT

It seems that in order to use colored surfaces feature of the AVF its a requirement that you supply arguments on the call to SpatialFieldManager.AddSpatialFieldPrimitive() (i.e associated geometry must be supplied). As a test, I modified the SpatialFieldGradient sample code from the SDK to use the zero argument overload for sfm.AddSpatialFieldPrimitive and the colored surfaces no longer worked (markers with text still looked to function properly).

Is my understanding correct? Or is there some way to create colored surfaces without associated geometry?

Re: AVF colored surfaces require a surface?

jeremytammik — Fri, 02 Jun 2017 06:36:26 GMT

You ask two questions.

Here are three answers:

Yes, Yes and No.

You understanding is correct.
You must supply geometry (a surface).
The geometry does not necessarily have to belong to a persistent database resident element; you can also supply a transient pure geometry object.

Several of The Building Coder AVF samples do so:

http://thebuildingcoder.typepad.com/blog/avf

My latest AVF sample, RvtFader, does not:

https://github.com/jeremytammik/RvtFader

This sample, however, does create its own transient geometry:

http://thebuildingcoder.typepad.com/blog/2015/07/intersect-solid-filter-avf-and-directshape-for-debugging.html

Cheers,

Jeremy

Re: AVF colored surfaces require a surface?

MattKincaid — Mon, 05 Jun 2017 20:53:56 GMT

Many thanks Jeremy. That is precisely what I needed.

Re: AVF colored surfaces require a surface?

MattKincaid — Wed, 17 Apr 2019 22:03:59 GMT

Revisiting this a bit. Following the approach suggested by @jeremytammik.

Questions

1. Are there any best practices for creating the geometry (surface)?

2. Is clean up required to ensure the surface doesn't persist in the Revit Database?

Background

We presently handle this by creating an extrusion using Geometry.CreateExtrustionGeometry(), which produces a Solid. Then grab a PlanarFace, off the Solid, to supply to AVF for rendering the ColoredSurfaces.

This is all done, inside of a Transaction, which gets committed.

Is there a better way?

Re: AVF colored surfaces require a surface?

jeremytammik — Thu, 18 Apr 2019 07:56:40 GMT

Your approach sounds quite sound.

However, if you commit the transaction, then yes, you do need to clean up the database afterwards.

Could you try to not commit it? Either just roll it back, or do nothing with it, and the normal Dispose functionality will clean it up for you.

I suggest this approach, if it does what you need:

Within a `using` statement scope:
Start a transaction
Create the geometry
Regenerate the model
Grab the surface you need
Do your AVF thingy
Close the `using` scope

This will leave no trace.

Question is, will it work?

If not, you could try enclosing the whole thing in a transaction group.

That gives you one more level of cleaning up. You can then commit the transaction, and even commit several transactions, within the transaction group, and still throw them all away leaving no trace by rolling back the entire group instead of calling `Assimilate`.

Check out the topic group on handling transactions and transaction groups:

https://thebuildingcoder.typepad.com/blog/about-the-author.html#5.53

Cheers,

Jeremy

Re: AVF colored surfaces require a surface?

Anonymous — Thu, 04 Jun 2020 22:26:56 GMT

Dear @jeremytammik

I am wondering if you have any examples that involve multiple faces that are automatically extracted from elements like ceilings or floors? The examples I encountered are by select face which is only suitable for direct selection. Any advise would point me to a direction.

Thank you!

Re: AVF colored surfaces require a surface?

jeremytammik — Fri, 05 Jun 2020 06:33:07 GMT

Numerous samples show how to select multiple faces. You can either programmatically filter them out of the element geometry object or select multiple facets manually using PickOnjects.