Welcome to the Bifrost Forum. This is the place for artists using Bifrost to ask and answer questions, browse popular topics, and share knowledge about creating effects procedurally using Bifrost.
You can also visit the Bifrost Community on AREA to download an array of ready-to-use graphs, read Bifrost news and updates, and find the latest tutorials.
Auto-suggest helps you quickly narrow down your search results by suggesting possible matches as you type.
Showing results for
Show only
|
Search instead for
Did you mean:
This page has been translated for your convenience with an automatic translation service. This is not an official translation and may contain errors and inaccurate translations. Autodesk does not warrant, either expressly or implied, the accuracy, reliability or completeness of the information translated by the machine translation service and will not be liable for damages or losses caused by the trust placed in the translation service.Translate
Each minor change taking too many seconds to update.
Each minor change taking too many seconds to update.
I was happily learning Bifrost then Maya suddenly realized that it's a "professional" tool so it started lagging for 13 seconds after each change in bifrost parameters. The graph itself is lightweight. Scattering a few thousand low_poly meshes on a moderately dense terrain.
It was working fast and responsively but this issue appeared all of sudden one day..
These things are showing to take the most time in Profiler (attached .txt and image)
@ayushbakshi98 Thank you for reporting this issue. Unfortunately, I cannot tell from your screenshot what exactly is taking so long. If there is a way for you to share the Maya scene file we can take a look for you.
Okay, I checked and almost all the execution time is done in the graph. The problem seems to be that you are scattering a million points (`Max Number` is set to 1000000) using blue noise which is quite expensive. Almost all of these million points are being filtered out due to almost all the density values you've input to the scatter node being zero (or near zero) and due to the `Cull Overlapping` being enabled. It would be much more efficient to generate fewer samples that are actually kept.
Alright. Looks like I got too confident with blue noise thinking it's much faster than blue noise maximal.. I'll try with standard random and cull disabled. Glad to know it's not bz of a bug 😌
