Baking PFlow to prevent recalculating every Frame? Any Tipps?

#1

Hello again,

its a bit quite in this forum at the moment, am i right? :slight_smile: My last thread still has no answers and is almost 2 weeks old :-/

Anyway, i have another question and i hope that someone has a solution:

Is there a way to bake a PFlow Mesh animation together with their assigned (static) materials - apart from PFlow Baker which instantly crashes?

I have poly reduced asteroids all over the place - big ones, med sized ones and a decent amount of small ones (for a believable debris field). Altogether i have 400000 particles and i need to render them with “Mesh per particle” which in turn leads to 400000 objects and Final Gather definitely has a problem with that :-/ Generating the map takes insane amounts of time and it isnt even a detailed one yet :-/

Any help would be very appreciated guys. This Pflow Baker Tool does not need to be free of charge - maybe it is even good if such a tool costs some money. It may finally works then. Because the Pflow Baker Script doesnt, it crashes even if i just display 10 % of the Source in the Viewports ^^ It also doesnt take any of the applied maps into account. This however is mandatory for me.

Thanks again for your help in advance
subb

#2

XMesh would work for sure. Supermesher may work without issue (I haven’t tried the latest version) No idea what version of max you are on but you could try Alembic export BUT I am not sure how solid the particle export is.

#3

Hey,

many thanks for your answer!

While i wasnt able to download a demo of XMesh directly, i was able to try the SuperMesher. Caching works with it; it also retains the animation (which the native Mesher in 3ds max does not for me - for whatever reason) and it saves the Material IDs so that i can just reapply the Multi-/Sub-Object Mat and have it all mapped correctly again. So i think this may already be it. Thanks for that tipp.

Alembic Export hasnt worked at all for me. Although it exported something and i ended up with a 2,5 GB ABC-File … when i imported it, i just got some Dummy’s from the PF Sources but nothing was shown in the viewports or at render time. So i assume that this is just not working for PFlow or i did something wrong and dont get what it is.

Im on 3ds max 2016 SP1, using the Student Version.

It all hasnt solved my problem with Final Gather though :frowning: It still takes an insane amount of time to create the Final Gather Map - cached or not. I opened threads regarding this issue already but it seems that no one really has a solution.

Anyway, thanks for the Tipp with those cache applications. One of em already worked. If you ´have any tipps on Alembic though, it would be awesome if you could share them with me.

Otherwise i wish you a happy new year! :slight_smile:

Greetings
subb

#4

Regrettably I haven’t used Alembic much, just haven’t had the time to waste on it yet. I have used Supermesher (older version 1.01) and XMesh pretty extensively both work incredibly well.

I need to do some work with Alembic as it is the built in solution, just time is valuable, and hammering out bugs and workflow for free is well free, when I could be getting paid.

That said, Changsoo @gandhics, knows it pretty well maybe he will drop in and offer up some advice.

#5

yeah, i was just wondering why it doesnt came up with anything while still creating such a big cache file. but its not a big deal if i cant get to know it right now. as mentioned in the next thread i just opened caching hasnt solved my FG problems anyway so this easily has time now :slight_smile:

thx for your help on this anyway!

#6

Possibly its created a ‘default flow’ (for view and render)?
So you need to add the nodes for size, and shape, etc again?
So pretty much a similar setup to your original asteroids but that now is cached.

Just a guess mind you I don’t have Max in front of me these days…

If you are having trouble rendering what sort of machine spec do you have?

#7

Hi Circusboy,

 no, the Alembic Import seems to be broken when you export particles with it. At least in my version (Max 2016, Student Version) i had nothing in the scene. There was also no real PFSource to be found (just that dummy of it) and therefore no new Flow in the scene. So i either have done something wrong or it is just not implemented the way it should be.
 
 Regarding rendering i use a pretty basic machine only: Core i7 4770K @ 3.5 GHz and 16 GB Patriot DDR3 RAM (Clocks at 800 MHz and uses a CL of 9). For viewport and everything CUDA i use a GTX 770. I never really had problems with this machine. I can render a single object with literally millions of polygons pretty quickly. But as soon as i have a lot of simple geometry and am not able to MR Proxy it, the problems start. For me it seems that the RAM might be the bottleneck. But as i found no other solution to optimize the shape instances with PFlow i reworked the scene and used manual animation baked into several different MR Proxys in the first place. And then i scattered thousands of these proxys all over the place with different size, rotation and what not.

And this works; no problem with FG Map Generation anymore and rendering starts instantly. Although it is a bit sad to do it that way (i loose all the great benefits from having a particle system dynamically control such type of scene) i will avoid using PFlow with shape instances now. I hope that one day they will allow you to use MR Proxys in there. This would solve those problems - definitely.