When I send a large pflow to render, during the preperation stage, it causes my system to hang whilst its calculating. No other plugins or parts of 3dsmax seem to have this effect on the OS. What is the cause of this problem? is it bad memory handling by the OS or 3ds?
During the calculation none of my four cores hits 100%… so I wonder why it causes the OS to grind to a halt!

Im running the calculation on a Quad core 2.6Ghz 8Gb system.  xp64pro

Any ideas?

patrick.reformstudios.com

Remember: pFlow by default shows only 50% of the particles in the viewport - maybe while editing it´s okay for your system, but when rendering twice the particles its too much? But x64 and 8 gig ram? What kind of scene is this?

How much of that 8G is used during calc?

Are you spawning particles and ending up with millions of them?

Are you using dense instanced geometry as particles?

How many particles are being generated?

Its a forest of low-poly trees(200polys) being spawned based on an animated texturemap. So… The problem only occurs when I go over 100k particles. ( and I have increased pflow upper limit to 1m). Yes the memory usage does hit 8Gb, so that’s why I know its due to overloading the memory-controller… I just wonder if there’s a way for these calculations to not cripple the OS even if it does involve heavy swap-file usage.
Its interesting as for most other instances where you end up using a swapfile, there is no degredation in OS performance (well… there may be SOME degredation, but not total a total freeze).

Im just doing a test to see if its a per-pflow-render event limit (ie make two pflows with different seeds limited to <100k particles.)

I can render 93k instanced shape tree particles no problem (3mins), but going up to 101k hits the memory limit and render time jumps to 8m.

patrick.reformstudios.com

Well.. That is 20 million polys

Sounds like you are just hitting the edge of your system’s memory.  thin it out.. ? Use multiple passes?

best..

Heh, yea, well I know its pushing the limits, but I was curious as to why it kills OS performance, when you’d think at least one core, and a few clock cycles could be left for the OS to keep working…

I guess its down to the architecture of the Core2Quad platform.

patrick.reformstudios.com

Yes.. Sorry for being redundant. I can’t stand it when I am looking for help and someone points out the obvious!

There are many reasons for what you are seeing.

In fact it may be that the system is in fact still working but due the swap file activity simply takes forever.
It could be that data is arranged in such a way as to create a situation where a block occurs and is never resolved.

PFlow code is pretty old actually. From what I understand newer versions of the code in stand alone apps are more graceful.

That said… 3DSMax has a VERY BAD HABIT of blocking threads and locking out the UI in SO MANY parts of the app. It is indeed one of its worst attributes.

There are so many places in the app where you have to WAIT and can not interrupt processes which you do not want running.. PFlow is notorious for this although in most cases an ESC will trigger a prompt to stop PFLow when working in the viewports.

Every app I have ever written where I am using multiple threads provides a method for the user to interact or cancel the process. I can’t imagine writing anything nowdays without it.

jona vark 30 May 2008 02:13 PM

Every app I have ever written where I am using multiple threads provides a method for the user to interact or cancel the process. I can’t imagine writing anything nowdays without it.

#### PLEASE TAKE NOTE ADESK PROGRAMMERS!!!! ####

patrick.reformstudios.com