How to cache standard explosion from browser?

How to cache standard explosion from browser?

pixerati
Enthusiast Enthusiast
1,373 Views
9 Replies
Message 1 of 10

How to cache standard explosion from browser?

pixerati
Enthusiast
Enthusiast

Trying to cache the output of the standard explosion. I can't seem to find any way to cache it, since the file_cache converts the output geometry into an object array. Tried alembic, but I just got the source geo with animated surface.

 

Also tried caching between the simulate_aero and assign_material nodes and had the same problem.

 

What's the correct method for caching this aero simulation?

0 Likes
Accepted solutions (1)
1,374 Views
9 Replies
Replies (9)
Message 2 of 10

pixerati
Enthusiast
Enthusiast

To clarify: I'm talking about the "standard_explosion" from the Bifrost Browser.

0 Likes
Message 3 of 10

Christoph_Schaedl
Mentor
Mentor

Have you tried to use the cache node. 

----------------------------------------------------------------
https://linktr.ee/cg_oglu
0 Likes
Message 4 of 10

pixerati
Enthusiast
Enthusiast

Yes, as mentioned in the initial post, I tried a file_cache. The output of the file_cache is incompatible with the output's 'out_geometry' input.

0 Likes
Message 5 of 10

arminmueller2051
Participant
Participant

I think you have to connect the file cache node to a new port on the output node for some reason I don‘t understand. . (The plus sign) 

0 Likes
Message 6 of 10

pixerati
Enthusiast
Enthusiast

You can do that, but then it only exports the source geometry, not the textured explosion. 

 

0 Likes
Message 7 of 10

jonah.friedman
Community Manager
Community Manager
Accepted solution

You can use it like this:

 

Note two things:

  1. The file cache is before assign-material. That keeps assign material live whether it's set to read or write. This material is a "material scene reference", which means the material does not exist in the Bifrost graph but is in the Maya scene, so the bob file written to disk will not contain the material. 
  2. We're using the "first object" output. That's because what's coming in is a single value, not an array. You can tell what is an array by looking at the graph by looking at the shapes of the ports - hats are arrays. http://help.autodesk.com/view/BIFROST/ENU/?guid=Bifrost_Common_build_a_graph_port_types_html

On point 2, that's why file_cache has two outputs. It had to be array in for reasons I won't get into that have to do with interaction with auto-looping, so it has two outputs depending on how it's used. 

 

 

image.png

Jonah Friedman
Bifrost Product Manager
0 Likes
Message 8 of 10

pixerati
Enthusiast
Enthusiast

Ah, thanks Jonah. I had tried that, but I realize now that I actually forgot to set the file_cache to write mode after applying there and was thus getting only the undulating source geometry coming through. Could I suggest that you produce some kind of null response if the file_cache node is set to Read and there's nothing to read? It's confusing getting some kind of output result; if I'd got nothing or an error I think I would have more quickly realized my stupidity and set it to write.

 

Also, while on the topic of this particular explosion preset, what's the quickest way to increase the resolution on this sim to eliminate the striations (I'm assuming the result of coarse voxel size)? 

VoxelStriations.PNG

 

Should we adjust fluid detail size?

 

What would be really helpful is a tutorial video specifically focused on design time and render workflow: best practices for dialing back a simulation during design time while keeping the overall shape predictive of the final high-quality render.

0 Likes
Message 9 of 10

michael_nielsen
Autodesk
Autodesk

Regarding the striations, please see the pdf document in the post here:

https://forums.autodesk.com/t5/bifrost-forum/how-to-avoid-artifacts-when-doing-aero-simulations/m-p/...

Adjusting the fluid detail size will help, but there are also other ways.

Cheers,

Michael



Michael Nielsen

Principal Engineer
0 Likes
Message 10 of 10

aaronfross
Collaborator
Collaborator

Hey,

 

I just struggled through the same thing, which should have been super easy. I was trying to cache the procedural_cloud sample graph.

 

May I suggest that the sample graphs be wired up correctly to actually work? I know that may be a revolutionary idea.  😉

 

In this case, the file_cache node was hanging out on a different branch of the graph, when it needed to be inline between the create_cloud_volume node and the assign_material node. It would have been easy to just set the file_cache node to "passthrough" and provide basic instruction in the backdrop.

 

It's super unhelpful to provide sample graphs that are wired incorrectly and expect users to wire them correctly without any guidance.

 

Just my snarky $0.02

0 Likes