Locators and the Bifrost Graph.
Flower tutorial.
Deformer weights and Bifrost.
New compound pack from Jason.
Brain
Bifrost USD at 17min.
This is goin to be epic.
Nice new Tutorials
Image Sampler for Bifrost
1 Like
Here the answers of the Bifrost ask me anything. Just in case you dont have an AREA account.
https://area.autodesk.com/community/groups/bifrost/7430560561984
**Thank you to everyone who joined us for yesterdayās AMA! **
Hereās a recap of the Bifrost AMA Questions and Answers:
Question 1:
Sean Willis: Any plans for community projects or events specifically for Bifrost?
Answer 1:
Jason Brown: While the team has no specific plans for any community projects or events currently, the Bifrost Addicts Discord holds events on a semi-random basis and there are faint murmurings of community projects also.This is independent of us here in the Bifrost team and the Discord is a great community.
Question 2:
Hernan Santander: Would love to hear what is the plan to make MPM more viable for production work. To make it a pair with nucleus in terms of speed and options. Thanks.
Answer 2:
Phill Mayer: The MPM solver uses a fundamentally different architecture than the nucleus solver, so itās not going to be an exact 1:1 comparison when looking at nCloth and MPM cloth solves. For particles, the Bifrost particle solver is quick and has similar collision options as nParticles. In general, for MPM simulations, keeping a coarser grid size for quicker iterations while developing an effect is advised, and to keep an eye on source properties that impact simulation time such as vibration speed. The development team is currently working on performance and usability of the MPM solver.
Question 3:
Hyunseok Ryu: Is there a node or compound to use texture color map by uv coords?
Answer 3:
Jonah Friedman:
Also answering - Christoph Schaedl: Why is there no native image sample node in Bifrost?
There isnāt one yet, no. Itās something that we know is important to users, and something we have our eyes on.
I think the most likely form this would take is to read image files directly in Bifrost. In the graph the image data could be opaque data, or it could be pixel data in a Bifrost object. You could then use it in various ways, including sampling it or iterating through the pixels. However there are some concerns. For one thing, you couldnāt use arbitrary Maya shader graphs or the Maya āfile nodeā which is commonly used to read textures, which may not be what users expect.
It would also make a lot of sense to integrate images with fields. The images should also work the same way fields do with the interpreted auto weights ports found on scatter pack and simulation nodes, ports which can take raw data, values or fields as inputs. We would want a representation that could work with these.
In any case, the design space on this issue is a bit tricky and itās not yet clear to me what the best representation is. Feedback from graph users about how they would want to use images, or any responses to the above, would be very welcome.
Question 4:
Hernan Santander: There is some kind of lambada mechanism in the works for sims? (Some kind of sop solver in H terms) So for example in the particle solver, you do not need to go so deep into the solver to find custom effects?
Answer 4:
Jonah Friedman: The closest thing we have to a lambda-based workflow for simulation is currently fields, which let you define a spatial field for lots of things on simulation solvers including source properties, influences, etc. Beyond that you can always āgo deepā and edit the node graph itself, as some of our users have actually done.
As for proper lambdas- the programming concept thatās key to many functional languages (and incidentally, Bifrost is a functional language), itās something thatās been on our minds more or less since the beginning of Bifrost. However itās quite a tricky thing to do, and will be a large project, and we need to make sure we do it in such a way that it has good usability and is applicable across a wide range of use cases in Bifrost.
Question 5:
Hernan Santander: Any plans to integrate ONNX (Open Neural Network Exchange) or such in Bifrost? Itāll be great to deploy deep learning models straight into Bifrost.
Answer 5:
Jonah Friedman: We have no specific plans to integrate this, but we are working on an SDK that allows C++ users to integrate third-party libraries with Bifrost. It could be used to integrate machine learning frameworks, both for training and applying ML models in the graph. It could also be used to pre-process training data. Itās a very interesting concept for sure!
Question 6:
Maxime Jeanmougin: People seems to be craving for more high level geometry nodes. Are there plans to add such toolset and new workflows in the near future?
Answer 6:
Jonah Friedman: Bifrost visual programming, thanks to being a JIT-compiled graph, can create efficient and expressive geometry processing. However, in doing so we found a limitation ā user data. If you (or us) want to create even a simple geometry node in Bifrost that does something like some faces, not only do you need to make sure to handle UVs and normals, you need to also handle user data of all types. This results in repetitive graphs and is often a reason why operators are written in C++ instead of the graph.
To lift this restriction, we are creating some systems around property transfer. In the delete faces example, you would create an operator that knows how to deal with all the properties of various kinds without needing to handle them all individually.
This will open the door to both us and our users creating geometry operators that handle UVs, normals and user data easily. As part of this work, weāve created prototypes of many geometry operators and the system works.
It is in our sights, and we are working on it!
Question 7:
Maxime Jeanmougin: Working within Bifrost itself is a really nice experience, but as a standalone compute engine, itās current weak point is the interaction with the DCC itself. Could we expect in-graph manipulators like selection, transform pivot, curve / point drawing in the future?
Answer 7:
Jonah Friedman: Itās a topic thatās always in our minds and is clearly important for the future. I think the UFE project, which was created for the USD side, really shows a great glimpse of whatās possible here. A project to create a manipulation system is likely a large project. In the shorter term, the Maya features of Falloffs (which are very much like fields) and component tags (which should be directly usable in Bifrost) are very interesting to us as well and those features could both bring capabiltity to Bifrost workflows and allow Bifrost to bring capabilities to Maya workflows.
Question 8:
Maxime Jeanmougin: When can we expect Cached Playback support for simulations?
Answer 8 :
Jonah Friedman: There is in fact a prototype of this already which you can enable with an environment variable. One reason we never exposed it is because it does not work well with heavy simulations, since the UI locks while computing a frame of the simulation, but does work ok with light ones.
Note that this is totally unsupported at this time. To try it out, set the environment variable:
$BIFROSTGRAPH_ENABLE_CACHE_WITH_SIMULATION=1.
A more practical way of doing this is the Rebel Pack node, memory_cache. But of course, Maxime would already know about that :).
Question 9:
Maxime Jeanmougin: What is the usual process when implementing new technologies into Bifrost? For example, when developing a new type of simulation solver. Does core research starts before thinking about interface and UX, or are all aspects of the said solver being developed by the different departments.
Answer 9:
Ian Hopper: The technical architects are always experimenting with new algorithms and new approaches to improve the performance and quality of different solvers long before UX is involved. As the fundamentals are better understood, designers get involved to improve the usability of the graph, and then it becomes a tighter collaboration between design and development.
Question 10:
Christoph Schaedl: Is there a way to save an OBJ to disk via Bifrost?
Answer 10:
Jason Brown: Not at this time unfortunately.
Question 11:
Christoph Schaedl: Is there any way to reference a VDB into Bifrost USD? Or a Bifrost Volume to USD?
Answer 11:
Guillaume Laforge: We donāt provide yet a high level compound to do that but since Bifrost USD is able to create USD prim, attributes and metadata, it is already possible for a TD knowing Bifrost and USD to build pretty much any kind of USD prims, including USD Volume. Iāve got a wip sample scene, I might share it on the Bifrost Addicts channel at some point (after cleaning it a little 
).
Question 12:
Christoph Schaedl: Is there active development on the Bifrost SDK?
Answer 12:
Jonah Friedman: Yes, there is, itās very active right now. The Bifrost SDK will be released in stages. Our first release will be all about creating C++ operators ā which are Bifrost nodes that are written in C++. We are ourselves using only SDK within that scope to build all of Bifrost-USD, so the scope is large enough for a project on that scale. It also includes documentation and examples.
Question 13:
Christoph Schaedl: In this Vision Series are Rigid Body and Fracture mentioned. How is the development going? https://www.youtube.com/watch?v=4D02lB-Tq4Y
Answer 13:
Phill Mayer: Currently we are looking at two different solutions: a rigid body solver and a physical fracture solver. Development and implementation are still early. Feedback on what you want out of a destruction system is welcome. The rigid body solver approach is what many users are most familiar with, an example of one such solver is bullet. The physical fracture solver is a research project to create physical shattering and fracturing based on material properties and would provide dynamic results. Itās a more novel concept altogether.
Question 14:
Maxime Jeanmougin: Whether technically or at a higher level, from the development teamās point of view, What is the area of Bifrost which you canāt wait to push further?
Answer 14:
Jonah Friedman: My own view is that Bifrost is more than the sum of its parts, and itās always the combination of many features that produces exciting results. For example, geometry queries or fields are both features that donāt actually create things on their own, but empower all the systems they interact with and more importantly, empower the users of those systems. And Bifrost is a system thatās very much designed to allow users to create things that we havenāt thought of. Thatās what I really get excited about, the endlessly inventive and innovative things our users are creating using Bifrost.
1 Like
This is super usefull!
1 Like
USD Nodes help doc.
https://help.autodesk.com/view/BIFROST/ENU/?guid=Bifrost_Common_reference_usd_pack_html
Really good tips inside.
