Visibility settings from Navisworks Timeliner

I have a bit of an issue to visualize the huge amount of information you get when running a timeliner in Navisworks.

Animation; add filters trough Rooms or Masses - Autodesk Community - Navisworks

Would it be possible to bring back this information to Revit, using Dynamo?

So at a certain Key-moment, you get to read of each element in Navisworks whether it is visible or not, and apply this in a number of views in Revit.

So we benefit the most from the capabilities of both softwares…

Kind regards,

Willem

Can you export the needed data to a CSV?

Yes you can,

basically you get the same info as what you exported to Naviswork, (a planning file), In Navisworks this is referred to as a data source. Navisworks can manage multiple data sources simultaneously.

Navisworks export CSV, remark the unique identification (4DSBS, the system breakdown System that runs the planning), and the notion whether something is build or demolished

I guess to run this properly, you still need another level, a register that ties the unique identification of all elements in your BIM environment to this 4DSBS.

So the planning does not need to handle the most detailed level of information, but emphasize on a level that is relevant to avoid conflicts.

But I would like to test this first on the dynamo/Revit side, how can we lookup at a certain date the visibility of all element in the model from this file?

That would be your Element.Id. I guess you can export that to with your CSV.

Here some ideas which may point you in the right direction.


image

1 Like

yeah all @bvs1982 say :wink: i would just use the guid instead…more stable…

Thank you Bas, I am going to give it a try.

Yes Sovitek, as we are handling multiple versions of the same model (unfortunately…) , an unique ID might be more stable.

Might there be restrictions in the next step, I tought the API of Revit is not so easy on visibility settings?

You can control the Visibility in multiple ways.
Simply Hide the Elements in View (you don’t want to see),
push the date to a Parameter and use Filters in Revit or
Isolate Elements in View (if it is temporary).
Phases and Worksets are also an option, but i wouldn’t use that in your (user) case.

Yes, pushing the notion of visibility to a dedicated parameter might be a good idea.

HI @bvs1982 ,
Hi @Nick_Boyts
Hi @jacob.small

thanks to your input in another post, I made a fist version of a graph that gets the visiblity of each element from an external timeliner.

Filter all elements that contain mutiple different parameter values, possible? - Dynamo (dynamobim.com)

I can check the appearance of each element, by entering a date.

I have two questions.

1.Before I add demolition of existing structure, does this appears compact & robust as a graph?
2.Altough the use of a visibility parameter is an easy method for instant viewing, is there an alternative thinkable to visualize several dates in the same model? Maybe something with external register where you simply tie a number of views to an external register with visibility settings on a certain date.

register appearance from timeliner.dyn (81.0 KB)

Kind regards,

Willem

Convert dates to numerals so you can easily filter by “before date” (less than), “on date” (equal to), and “after date” (greater than). Then you can store the creation and demolition dates and use filters to update graphics, create schedules, and make queries. You can use Dynamo to update these views dynamically or to create multiple static versions by date.

You’re essentially recreating the phase parameters but at a much more granular scale. In fact, you could just use Dynamo to create and assign phases for every day of the project to accomplish the same thing.

Or create one filter with a ‘less then project date’ which is a project parameter that you set. Updating that date would update all views.

The only ‘hard’ bit is converting dates to numbers; I recommend ‘days since project kickoff’ as a start point there, likely updating the parameter values programmatically from say excel/others.

1 Like

A project parameter is a great idea for singular control over all views. My initial thought was having views for each project milestone per project.

1 Like

My feeling is that your graph can be optimized, but can’t say for sure without knowing
what nodes you used, what the Python does and without seeing what
goes into the nodes (the data). First two things i can get around by simply downloading your .dyn, but then i still miss a dataset.

But before you optimize i would do this first.

Hi @bvs1982

I should have added the source.

Kortrijk 01reg.7z (5.9 KB)

Uptil now, I only looked at 6(7) for start date, and at 13 (14) for “SBSidentification”
For now, I want to add 8(9) for the task type, in order to add demolition.

As what has to be demolished before a date is inversed to what has to be Constructed before the same date.

I will send an update when that’s done.

Regarding the parameters…I could add a dozen parameters for a dozen Milestones, and add two parameters for “instant viewing”.

But I hoped there would be a more direct solution, e.g. make an external register using Power BI which handles quantification & cost management, and go lookup your visibility over there without
a dedicated parameter for each milestone.

Kind regards,

Willem

Assuming your milestone dates don’t move often (if at all), then this is a pretty “direct” solution once you’ve automated the setup (and maintenance) with Dynamo.

How would show progress without having a point of reference? I only suggested milestones as a set of known reference points. You could also do it based on a provided date but you’d still have to update that value in PBI. The same can be said for Revit, it would just be a Dynamo script that updates filter values behind the scenes.

You can certainly push all this data to PBI and handle it that way. It’s still a lot of the same automation through Dynamo to add the creation/demolition dates to all the elements. You’re just changing the UI/UX to something more intuitive for most users (which is always good). It’s up to you how you want to interact with the data.

Nah - you can call the current date via formula, just like Excel or Dynamo. This link might help should anyone want to look into that: TODAY function (DAX) - DAX | Microsoft Learn

You can’t do so with OOTB Revit though.

True, but (I’m making assumptions again) I’m guessing you’d want to at least preview future dates and potentially track progress against earlier dates on demand and not just see daily updates. Either way, I do think PBI is a good option.

1 Like

Hi there,

the crux is having the planning to stay relevant & accurate.

Dates are handled in MS Project, Milestones are more or less fixed concepts, but the challenge is that there are constantly new insights, which asks to change the adherence of elements to the fixed milestones.

So you have to be able to change the granularity of the planning, with an “assymetrical” composition of the SBS that runs the planning.

E.g. 1 underground passage can be demolished all at once, the other will be demolished element by element.

I would like to have 1 parameter that indicates the “SBSstrategy”, resulting in a dozen strategies for 36.000 elements in 4 softwares.

An EIR database in Power BI could keep track of the situation of each element, so you apply the same logic both in Power BI and Dynamo…to not loose your mind, manage the redundancy of your data, and have the ability to check the consistency of the result.

In order not to have tweak a dozen Dynamo script all the time(for composing the SBS), it would be nice if there was a way to tie them to a number of little json or .csv lists that come from the EIR in Power BI…is there somebody who went down this rabbit hole already?

Regarding this script.

It works.

In order to have it more robust, @bvs1982 can you make it more compact at the exit?

-I would change the input of the central Python code, so the identification and function of the tasks types can come from an external source.
-I would like to ditch the selection of elements too, in order to make it more robust.

register appearance from timeliner 02.dyn (159.6 KB)