AVF colored surfaces require a surface?

[MattKincaid]

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?

[jeremytammik · Accepted solution]

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-debu...

Cheers,

Jeremy

[MattKincaid]

Many thanks Jeremy.  That is precisely what I needed.

[MattKincaid]

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?

[jeremytammik]

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

[Anonymous]

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!

[jeremytammik]

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.