Numerical Error

[Truffi]

I can confirm, with inertia force set to 1, it works better but not 100% save. This happend with inertia force set to 1.0:
https://www.dropbox.com/s/zqcn1idz2c...t0%29.mp4?dl=0


Let me list two other even worse bugs:

2) The UI in the command panel (to the right hand) dissapears in some PhFD scenes, sometimes and after a while with no apparent trigger. If I hit the symbol on top of the command panel to switch between panels it is empty, for example from Create to Modify. I then hit the Modify symbol again and the buttons and tabs in the panel appear as they should, but if I open a RollOut inside the panel (for example Resimulation), again it does not update. This happens to all objects. Even when rebooting and loading the glitchy scene, the bug remains. Only solution: abandon the scene - as a sidenote it never happened on my system before, so it is 99% caused by something going on with PhFD.

3) 3dsMax freezes during the simulation process without reason or error message. This first occured when I set up a pflow particle system and used it as emitter. Without a warning, the cursor just turns into blue cirlcle (I use Win7) and when I left click the screen turns milky, so to move on I have to restart and restore the sim. The same things happens if I stop the Pflow system to function as emitter. If it is deactivated altogether, the sim calculates to the end as it should. What is strangest, Pflow and PhFD3.0 worked well together in the same scene before. I didn't really change my setup. The freeze always occurs after it simulated 125 frames succesfully - so always around the same frame. Up until then the result looks fantastic and the emitter is doing the work it is supposed to (ideally when set as Volume Inject Emitter). I keep trying, maybe it can be tackled by modifying the Pflow Set-Up.

Sorry to throw all this at you, I know you guys are busy, but the bugs seem severe. This scene is not complicated or special at all. I just try to get longer fire trail. https://www.dropbox.com/s/8rvlm7352y...Pflow.rar?dl=0

On the pro side there are no numerical errors anymore thou

I keep reseting 3dsMax, starting new scenes, merging my geometry in, creating the gridcage and helper from scratch with slightly adjusted values and set-up, then I press that Start button and hope for the best. Let's see.

[Svetlin.Nikolov]

Roger that, I'm on these until we fix them.

Haven't really ever seen an issue like the one with the panels though... does this happen for you with the attached scene as well? It's not a rare occasion for me after I've had my PC on for a couple of weeks and I've started 3ds Max many times a day, to have the UI in the panels start to lag for a couple of seconds or more until it displays. I've tried to debug it and it turned out that we are waiting inside 3ds Max's dlls for something. This gets fixed by a restart of the PC though, so if this doesn't help, my only other guess would be if you might be having problems connecting to the Phoenix license and it takes time until it displays the interface. Are you using a dongle or a license server? Also, does this happen only with the Phoenix UI, or with any other object as well?

Just reached frame 126 of the simulation, waiting for it to get stuck. I'll update you when I have something.

Thanks very much for helping track these issues down!

[Truffi]

Hey,
I can give an update on the crash nr 3):
The freeze only happened with a pflow set-up with an emitter geometry ("position object" with animated vertices checked), that changed it's polycount during the simulation.
There were no problems in another test with Pflow, this time having a more simpler static geometry act as an emitter object for Pflow.. The sim runs through fine and the particles work as emitters like they should. In both cases the emitter object was not supposed to have and should not have a direct influence on the PhoenixFD sim, only on the Pflow sim. At least this difference was the only thing I could make out comparing the problematic version with the working version, no clue if it helps to explain it.

Concerning the error nr 2. Yes, the UI problem affects all tabs, not only Phoenix. Also the graph editor shows up delayed or without any UI elements. I got to click inside and then part of it appears. Like I said the bug occurs only when I get Phoenix Objects into the scene. It does not occur necessarily, but the longer I mess around with the same scene with PhoenixFD the more likely it will occur at one point. Running multiple test requires me to set up everything from scratch many times, saving the scene a lot also helps.

[Truffi]

And here is an error nr4, the 3dsMax scene just quits without error message when I simulate with a simple wind force. I hope it's not me doing everything I can causing it to crash.. Actually I do this to get to a finished version which I sure will some time. Details: The wind is set to sphere, has a decay and its strength is set to 0,01. The sim ran succesfully for 1hour 40 minutes, until frame 202, then 3dsMax simply closes. It happened before multiple times, only if it interacts with wind. Actually it never endured so long. I guess the issue is known?
This time I got the chance to send a crash protocol to Autodesk, which I provide for you here in case it's useful:
https://www.dropbox.com/s/2boil3guw9...Scene.rar?dl=1

[Svetlin.Nikolov]

Wow, you totally destroyed it

So #3 is because for some reason the texture sampling at frame 145 becomes extremely slow. Basically you can wait for it and it would eventually finish the frame and then it would most likely be extremely slow for the rest of the frames as well. If you disable the texmaps on PHXSource001 it should not happen. I'm yet to figure out why it suddenly decides to be slow after 120 frames though. About animated geometry - Phoenix sources will ignore geometry with changing normals at each frame when the vertex count changes - do you really need the particles to be meshed? You could plug the particle system directly into the PHXSource and choose the particle shape from there instead.

Will check #4 now...

[Truffi]

Well I had it set up like you say - I plugged the Pflow particles into the PHXSource to function as emitters via Volume Inject. I have no clue why the texture sampling rises up suddenly like this and what it has to do with Pflow particles. But there must be somehow a mysterious link. Actually there are two PHXsources in the scene: One for the rolling tire. This one uses a texture to emit. It worked a dozen times without freezing problems. The second one uses the Pflow particles to support the fire trail. The latter must have caused the freeze somehow. If the Pflow particles are deactivated, there is no freeze. To get it to work again all I did was changing the Pflow emitter geo. I kept the particles in and again there was no freeze. So I am fine now and the current simulation looks pretty promising and I will try my luck with a resimulation now.

Error number 4 was avoided just by ignoring the wind via the interaction tab. The wind force did not affect the fire very much anyways, and I guess for the future I'd probably just try to replace the wind force with a plain force (even thou I didn't find out yet how to make the force pressure radial).

The most annoying error is nr 2, the UI. But I see that it is hard to reproduce, I will send an update as soon as I have more signs of evidence of what causes it.

[Svetlin.Nikolov]

Alright, #3 is down - the textures were invalidated in the middle of the Phoenix calculations and thus they need waaay longer time to be read by Phoenix.

Would it be possible to share the setup with the Wind as well? I tried putting it in the middle of the simulation, but couldn't break it. The dmp file can sometimes prove useful, but no luck this time...

I also found some clues as to what the problem with the instabilities could be, but it needs some more time to progress.

Not really sure about #2 though, I've honestly never seen something like it so far, neither have my colleagues. I'll also think about what you can try...

Cheers and thanks a ton for helping catch these nasty issues!

[Truffi]

#3 Still seems unclear how the texture invalidation could be affected by Pflow.. Can it be outruled that there is a connection and the repeating error was just a conincidence? This seems unlikely in practice, because the same scene with same simulation worked fine with all the same set up many times.
With the non-static Pflow emitter it crashed at the same frame about three or four times. With "non-static" I mean the fact that the Pflow emitter geometry changed the polycount (via "Volume Select" and "Delete" modifyers). I know this factor seems irrelevant since this geo is not emitting anything inside Phoenix, but on the button line that was the only difference I could spot between the working and freezing sim. Other than this, is there a theory or idea why the problem occured in this particular set-up? Could be useful to avoid it next time..

#4 Here is the scene that produced issue number 4 - that is 3dsMax suddenly closing during simulation with a wind force included.
https://www.dropbox.com/s/obiqwbl4pn...hWind.rar?dl=1

Have a nice weekend!

[Truffi]

Finally I just have to report one more glitch - not so nasty but yet pretty odd error:

Is it normal that the fire's position shifts when doing a resim?
Compare the position of the gridcage content between the two images (before and after hitting the start Resim button):
https://www.dropbox.com/s/l7mm90554v...eGrid.jpg?dl=0
https://www.dropbox.com/s/gyp8bo0hwf...Resim.jpg?dl=0

Anyways, I doubt it will cause serious trouble, since I guess I will be able to just transform it to its propper position later after the process, at least I hope that will be possible

[Svetlin.Nikolov]

Ah, yes, we found this one as well. You would be able to work around it also if you start the resimulation from a frame when the grid hasn't adapted yet.

[Svetlin.Nikolov]

I didn't answer about the issue with the texmaps - the 3ds max sdk requires them to be updated before they are read from. Phoenix left a gap between the updating and the moment sources read the texmaps, so it was possible for other scene nodes to in turn update the same texmap, invalidating it for the Phoenix operation. Generally this may depend on the order nodes are created in the scene, but in this case they were scrambled again because if the way Phoenix processes sources internally.

Also it looks like the wind issue is similarly caused by the force interacting with the pflow particles and Phoenix simultaneously. I still have to find out the exact reason, but the crash is because while Phoenix reads the velocity from the wind, the wind thinks it's interacting with the particle system.

[Svetlin.Nikolov]

Alright, the wind issue is down as well - alongside it we found that if you animate the direction of the 3ds Max Wind, Phoenix doesn't register the change, so this one is down as well. I hope by the next week we'll be done with important post-release fixed and will make the 3ds Max nightlies open again, so the fixes should be available then.

Again, thanks a ton for finding those and for the excellent reports!

[Truffi]

thanks to you for updating. does animated wind strength cause this error too?

[Svetlin.Nikolov]

Nope, it's a PFlow+Wind+Phoenix interaction thing. Animating the wind strength might work actually, I'm not sure if this was affected before.

[Truffi]

So far animating Wind strength didn't cause any problems for me as far as I can remember, but it could be a hint.
I am asking because I had the numerical issue and strange spraying behavior without any pflow system in the scene. There was just a wind and the wind direction did not change (it was my very first attempt to create a fire trail).

So about the texmap issues, will that be fixed in the next update or is there a work around to avoid getting stuck with this again?