Inside the Factory

Revit Sunrise: Draw Visible Elements Only - Occlusion Culling

I hope you have been able to give our Autodesk Revit Sunrise hosted preview a spin.  We’ve been reading your feedback - keep it coming. 

We posted a What’s new in Autodesk Revit Sunrise article, but you may be hoping for a little bit more detail into some of the features.   We’ll be trying to answer some of those questions and providing a bit more insight into the functionality in some up-coming posts.  To get things started, here is some additional detail about one of the performance improvements. 

The “Draw visible elements only” option improves view performance by occlusion culling. Elements that are obscured by other elements will not be drawn in the view.  This is done using your machines GPU.  In Revit, you will see the most benefit in 3D views with many obscured elements.  On average, we’ve seen a 30-40% improvement in performance during our testing, but your mileage may vary.    

There are a few things to be aware of with this feature as well.  Occlusion Culling is not used when shadows are enabled in a view.  This is so that things that might not be visible in the view can still cast shadows that would be visible.  Also, when selecting elements in the model, this feature will work the same with this turned on or off – even if the objects were not drawn because of this feature, they still can be selected as needed.  

You can enable or disable this feature in the Options dialog on the Graphics tab.  The setting is also stored in the Revit.ini file as “UseGpuOcclusionCulling”.   Because this feature uses your GPU, hardware acceleration must be enabled for this functionality to work and a graphics card that supports Shader Model 5 or higher is required.  This is a change for our system requirements (where the minimum is listed as Shader Model 3).  If your card doesn’t support Shader Model 5, the “Draw Visible elements only” check box will be disabled.   

Another interesting fact is that we developed this feature in partnership with AMD.

-The Factory

 

Revit 2016 | Project Performance - Part 4

When we talk to project teams about Collaboration for Revit, a common thread emerges where everyone agrees -> there’s no such thing as an operation that can be too fast.  We agree, and are constantly optimizing the service to deliver a better performance experience.  With our most recent update to the service – C4R 2015.5 or C4R 2016.0 – we implemented a new technique to deliver the further optimized experience.

As many of you know, transactions between the Revit application and the place of record for the model (aka Central Model) happen in the form of deltas, rather than pushing around the entire model, which can be quite large.

Revit Worksharing

Based upon a number of factors, a single Sync With Central (SWC) operation is going to consist of a number of delta files to be processed by Revit.  There will be inbound deltas consumed by the Reload Latest portion at the start of SWC (from other team members doing a SWC).  There will be outbound deltas consumed by the central model based upon the changes of the current team member.  Up until the latest release, we transferred these deltas between the Revit application one-at-a-time, or “in serial” as our developers call it.

Transferring deltas in serial

Now, with the latest update, we have begun transferring these deltas in parallel, so the data is moving across the pipe faster, and the necessary data is available for processing on either side of the transaction quicker.

Transferring deltas in parallel

When we analyze the impact of this new process using real-world projects from customers like yourselves, we find some nice improvements to performance.

We on the product team are pretty excited about these improvements, and we hope that the teams using C4R enjoy the improved performance.  It’s all part of our continued delivery of value to subscribers.  Rest assured, we have a number of other improvements in the backlog, and we’ll be discussing them here Inside the Factory as they come.

Kyle Bernhardt

A Case for Software Updates

When faced with the "Restart your computer to finish installing important updates" Windows pop-up, I think it's universal to click on the Postpone button. "I'll get to it later," you think to yourself, but sooner or later it's been days and that pesky reminder is still haunting you. Most of us do it; I'll personally admit to having gone weeks before finally taking 5 minutes to reboot. 5 minutes that would have saved me quite a bit of frustration and let Mike, our IT guy, sleep easier at night.

In an effort to change my habits (and possibly yours too), I'm going to tell you two Revit stories that show why regular software updates are so important and the good stuff you get when you take the time to update your software.

 

Story #1 - A Case of Better Performance

The Revit team runs thousands of nightly performance checks. Every day we have an accurate measure of how Revit is performing compared to the day before and compared to previous releases. Our goal - make Revit faster every day.

So imagine our extreme disappointment when one morning Revit view update is suddenly a whole bunch slower. The usual suspect: a component integration. Or is it? We can't reproduce the degradation on some computers. I'm thinking: now it's going to be difficult... Then someone suggests something - have we tried updating the graphics card driver? Somewhat to our surprise, it works! The updated component interacted badly with the outdated driver on the machines. By updating the driver, not only did we gain back all of the performance degradation from the component integration, but we crushed the Revit 2015 numbers. Here are the improvements we saw (thanks to Scott Blouin for the numbers):

Food for thought: Revit doesn't work in isolation - other software has bugs too. 30%+ faster performance may be just a driver upgrade away.

 

Story #2 - A Case for Greater Stability

Anthony explained MTBF (Mean Time Between Failure) in a previous post. I'd like to use some MTBF numbers as a data point to show why updating to the latest update release of Revit might keep you happier.

Update Releases (URs) contain critical bug fixes to the Revit software. This includes things like security patches, functionality fixes, and especially crash fixes. Each UR makes the software safer and more stable and the Revit team highly recommends installing the latest update. Each UR includes a list of fixed issues. If you're curious, here's the list for 2015 UR7. Code word for crash fix is "Improves stability."

When broken down for each update release, the Revit 2015 MBTF numbers below show a clear trend. Note: a couple of URs are not in this chart due to low adoption.

Revit 2015 UR3+ is approximately two times as stable as the originally released version of 2015. That means that users on UR3+ crash approximately half as often. That's a lot of work saved.

It's still early for UR5+, but we expect to see numbers that are consistently higher than UR3 as adoption grows.

Food for thought: Revit URs are designed to fix critical bugs and improve stability. MTBF is just one measure of how much impact they can have.

We'll keep making Revit faster and more stable, but in the meantime, happy updating!

Sasha Crotty

So, When's Sundial Coming Out?

Veterans of Autodesk conversations know that 'deskers get all squirrely when a question starts with "When".

That happens for some good reasons around regulatory controls in the USA concerning predictive statements by publicly traded companies, restrictions that don't always obtain for companies based elsewhere in the world or in quite the same way in every situation for every American company. Find me in person sometime at an industry event and ask about this, and I guarantee I can bore you into glancing hurriedly at your watch and suddenly remembering an urgent appointment.

However, some folks are getting excited about some of the things they see in Sundial, and wondering whether they'll actually be able to use the new features in production. For example, the PDF hyperlinking in the export sure sounds like a great feature to some customers. They can't actually try it out in the hosted environment, so that enhancement for now remains in the realm of "Imagine if you will...", or in other words, maybe not the most compelling demo ever.

So, I think I'm safe in the regulatory environment in which we function to say the following:

1. Sundial features could be available sooner than you think.
2. They might become available in a way you don't expect.

To the legal scholars with whom I occasionally discuss my public comments, please note I say "could" and "might", allowing sufficient uncertainty that I actually predict nothing at all, but only, perchance, speculate.

I'll also say that the Revit team and Autodesk are committed to finding innovative ways to get as much value to our committed customers as rapidly as we can.

More later!

Anthony

 

 

How much?

I'm going to get a little philosophical with this post.

 

I recall when I first started working on Revit how it pushed the CPU on my Pentium more than anything I had ever seen before - much more than the CPU would move on our company mail server which I thought was doing quite a bit of work.  Later I taught students my Revit theory on the conservation of work.  The theory posits that the effort of making a set of drawings consistent after... say a floor to floor change does not disappear but instead moves to the processor.  The effort shifts from man to machine.

I also remember having a conversation with one of our developers.  I asked if Moore's law might work in our favor and Revit was just a little bit ahead of the curve and processing capacity would soon catch up.  He confidently assured me that new capacity would be eaten up by new product features and/or changes in what user's model.  He has been right so far, despite several major efforts to enhance performance.

My question to the readers is does this ever stop?  If so when?  Think to the future.  What will you expect to model then and why?  Will it be less or more?   Perhaps model more and annotate less?  What is the projection and can we even discern a logical end?

_erik

Revit and your Graphics Card

A technical post for those who like to know a little more about what is under the hood.

In the 2011 release Revit added some graphics technology called OGS  (One Graphics System).  The name is derived from the use of the technology across multiple products in the company.  This incorporation enabled the realistic view option where bitmap textures are shown in non-rendered views.  I have been asked by a few customers if Revit will cache textures in graphics RAM just like a game system might?  In this situation the amount of RAM on a video card becomes more important when making hardware buying decisions - especially if you spend a lot of time in realistic views. I am happy to say the answer is yes – Revit will fully use this RAM and the graphics team is continually looking to make improvements in memory management.  This means textures will be processed on the board as long as memory on the card is available. When memory is not available the system will start to page and performance will deteriorate.  Having the textures processed on the video card improves performance and the more materials with textures you use the more gain you will see.  Also the more memory the more textures you can have before paging kicks in. I do not have hard performance data to share between cached on HW vs. not cached on HW but am rather confident that hardware with more memory will reduce any chance of paging and therefore aid performance.  Note that textures stored in RAM are raw images so the size when loaded into RAM is often  bigger than the images appear on disk.  How much bigger?   This is hard to say as it varies with the file format.  The “lossier” the compression algorithm the bigger the difference will be between disk and memory.  For example BMP images will have a small ratio while JPG might be big – especially if you lower the quality.

_erik

 

User Performance Roundup

I'm going to revisit a topic that was posted a while back here.

User Performance measures the time it takes you to understand and respond to a machine signal. This often means reducing clicks but can also come in the form of the system conveying information in an easier to digest manner so you can more quickly make a decision toward completing a task.

Below are some areas I have gathered and categorized.  I'd like feedback on this and I hope they spark other thoughts.  Take a look and keep these in mind as you perform some tasks over the next few days.  Are there other minor things you see that if addressed could improve your speed?

CONTROLS

1. Allow clicking on any column header to sort by that header
2. Ensure all lists in dialogs have a meaningful default sorting
3. When names include numbers use a smarter sorting algorithm that accounts for units. (e.g. 1'-0”,1”, 12’, 21”, 4”, 5” - bad,  1”, 4”, 5”, 1'-0”, 21”, 12’ - better
4. Make the offset text input field wider to display larger numbers
5. When moving items up or down in the schedule field order automatically scroll when an item reaches the bottom of the list
6. Display the drop down control so one does not have to first activate the field
7. Ensure the selected value of a drop down is placed at the middle of the list so one can see values above and below without scrolling
8. Increase the length of all drop down lists

NAVIGATION

1. Ensure orient to view on the view cube and steering wheel has scroll bars on the view list
2. Constrain the Zoom drag preview box so its proportioned to the active window aspect ratio to better preview the zoom results
3. Double-click on middle mouse wheel button to perform a zoom extents
4. Double-click on a sheet viewport to activate the viewport
5. Double-click to edit a family
6. Enable middle mouse wheel scrolling in all drop down lists

CLICK THROUGH UI

1. Add <New…> and/or <Load…>  to the drop down where one specifies another family (such as a profile) so the one can continue with their workflow rather than exit the dialog
2. Add a button to the right of the selected family/type that takes you to the properties of that type (to alter, duplicate etc) and then return to the original context when that dialog instance is closed
3. When overriding an object if a Fill or line pattern doesn’t exist, you have to exit, create, and start all over again.  Provide a way to access these UI areas to create new styles that can be used in the overrides dialog. (similar to material parameter)

MATERIAL UI

Ability to delete material

GROUP EDIT MODE

Unable to duplicate a wall type or something else when in group edit mode, except from the project browser.  Allow type duplication in this context.

WORKSHARING

To change the workset of an existing object you have to deselect the object and then reselect it before the workset field on the properties dialog is enabled.  Simplify the steps here.

MASS PLACEMENT

Difficult to place a mass because the mass is work plane based and the placement option is not set to default to the workplane placement option.

More examples?

_Erik

Tuning the Graphics Engine

Hello, My name is Tsvetan Tsvetanov, Principal Software Engineer with AEC Solutions User Experience Team at Autodesk. Until recently I was part of the Graphics Group working on Revit and I would like to shed some light on work that was done to improve graphics performance in the 2010 release.
As in any software development there are requests that lead to creation of new functionality and others that are are considered "renovation." In this release we implemented a few changes that may not be immediately visible. These changes are pretty big and will open doors for possible feature enhancements for our graphics output. Our graphics engine is tightly coupled with our geometry engine. That way, we are able to allow our geometry data to define the behavior or our graphics visualization, for example the color change when you hover or select an element. This makes the graphics engine very flexible and allows us to define states and conditions for when and how something would be processed by the pipeline (the algorithms that determine how things will appear on the screen.) But in the same time it is limited by the fact that such flexibility can comes with a performance cost.

So what did we do this release ?

One of the biggest, yet mostly invisible changes this release was the shift to a new graphics engine that allowed us to support DirectX together with OpenGL. Along with that, we have started to cache our graphics data so we can send it directly to the graphics hardware without a need to pre-calculate it on every single view update. This should lead to better performance depending on the hardware in use. This performance gain might not be immediately noticeable. For example, when the cache is originally created or when there is not enough memory and we start to clean it, there is an initial performance hit. However, subsequent displays of a cached view should be noticeably faster (once again, depending on hardware.)

This development effort was done to create a framework and mechanisms that will allow us to work on future user-requested enhancements for our graphics output and functionality. These improvements are already noticeable in the current release and should improve the speed with which you navigate views in Revit.

Has this been consistent with your experience with the release to date?