Particle Flow not rendering correctly!

[panthon]

Hi!

In my current project I am facing a problem concerning Particle Flow:
rendered particles dont match what i see in the viewport!

I use spawning to create trails of particles, using the rate option, and it looks like the particles are in different positions in viewport and in the render somehow. I have checked the viewports, and it seems to be all correct, no locked viewport on render. The quantity of particles are the same in viewport and in render: 100%

I have tried caching the particles with no luck.

I guess the problem comes from particle flow, some kind of bug? I dont really know what's going on, so any experienced help from you would be appreciated.

I have tried with vray and scanline with the same result.

Here's the example:

[studioDIM]

make sure the timestep is identical for both viewports and renderer.
They default to a frame for the viewports and half frame for the renderer.
Hence the difference

Or so i gather.

Lele

[panthon]

Oh lele, I know now why u are beating me!

You were right, the problem came from the half frame render thingy. It's strange because prior to this project it had worked perfectly...BTW, what is the half frame on render for?

Thanks!

[studioDIM]

lmao!
I beat you because at teh moment i am self-unemployed
Time's on my side, hey!

It's for the calculation of particle-particle and particle-object interaction.
Like for moblur and simulations in general (RB,SB,Cloth and whatnot) the smaller the timestep, the more accurate the simulation is.

Bear in mind, though, that PF can be bitchy.
As you saw from the system you had in place, changing the timestep can have ALL SORTS of adverse effects on your simulation.
It's a good idea to do all those checks in advance, fix a timestep for the viewport, and stick to it for the renderer...

Unless it's a very chaotic, and very little coreographed, simulation.
In which case it's just healthier to lower the timestep for the renderer, to get more accurate interactions and collisions.

Hope it helps...

Lele

[panthon]

Yes it helps a lot.

Now, viewport and render are in sync but when i try to cache it, the process runs out of memory , which it s not true, because its using 900Mb from 2000 available and ends at 48%...Vray crashes too at the same frame using a similar amount of memory...Its not the first time it happens, I think its related to particle spawning and a bad memory management...

Edit: It crashes at about 25000 particles...

[studioDIM]

you got it.
It has plenty memory issues, and the caching, especially with geometric particles, sucks.

there WOULD be a way, i think, to avoid that.
It would involve scripting a "TM dumper", and then applying it (the dumped transformation matrix)to objects, and bypass all the PF crap for good.

The only thing with it is that it has to have a very good memory management (and with scripting it's often the case of slowing the whole process down, to clean the memory), and that given the quantities involved it has to be fairly fast.

It's not much different from that proxy+PF scripts i did, in principle...
In reality, coping with spawning particles and such can be a hassle.

Calling in to Joconnell: any experience writing a disk-cacher for PF, mate?

Lele

[charleyc]

PF Tools Box 3 has some really great disk cache toolsas well as a lot of other power. Well worth it if you are in need of such things.

http://www.orbaz.com/forum/viewtopic.php?t=464

[studioDIM]

aaaah, great thanks!

Lele

[studioDIM]

It's great, but boy, for a disk cache (all i'd need of it at the moment) 395 bucks seem a bit exagerate.
Besides the disk caching is done identically to what the script would do, if surely more efficiently and quickly.

Lucky us that there is a script operator in PFlow :P

Anyways, i'd be curious to try it: some of the logical operators look impressive, with all the independent subnets inside one op only.
And the other stuff on the site is really cool too

Lele

[panthon]

This particle flow box 3 looks like it's too much for me, look at that data operators with bucles and conditions and whatnot...
I think we are going from an event based flow to something else... granted, very powerful, if you know how to use it...

Btw, i have managed to finish the animation which wouldnt render correctly, changing some parameters slightly, like the frame in which the transitions occur and now vray is able to render it without crashing!

All of this is part of a short duration film of mine which i will be pleased to post here when finished! Lots of VFX and hard work to do! And learning on the way!

You can see some stills at my weblog (you can find the url in my www link), but, unfortunately, it's not written in english; however, its updated regularly

[charleyc]

It's great, but boy, for a disk cache (all i'd need of it at the moment) 395 bucks seem a bit exagerate.
Besides the disk caching is done identically to what the script would do, if surely more efficiently and quickly.

Lucky us that there is a script operator in PFlow :P

Anyways, i'd be curious to try it: some of the logical operators look impressive, with all the independent subnets inside one op only.
And the other stuff on the site is really cool too

Lele

For sure, if you are not in need of its power, it is not worth it. But it is truly amazing. Makes me feel like I did when I first got Pflow way back when. I am still trying to wrap my head around the tool, but so far it has opened the doors for what I needed. And I am getting to the point where I am beginning to see new uses for it that I had not initially thought of. Fun stuff for sure.

As for scripted alternatives, I have not tried to create a disk cache tool by script, but I have had enough experience with scripted operators to know that they can really slow down the evaluation of a flow. Box3 has, according to Oleg been optimized to handle large particle amounts much more efficiently. Infact he in one conversation I had with him, he made mention of working with millions of particles. Something that I do not beleive is possible with the standard flow.

But again, if your scipted solution to caching is working, there is probably no need to dish out money.

[studioDIM]

Well, let's put it this way: between 400$ and a fast, efficient solution, and 0$ and something that works, if extremely slowly, i'd first go try the cheap one

That said it does present some scripting issues i'm not sure i could work out, but it'd be worth a try.

AND i want that toolbox, lol

Lele