PRT loader holding files for write until Max quit

Krakatoa for 3ds Max
1

Hi guys,

I have a setup where I’m writing PRTs from Naiad, and I’m reading them with a PRT loader. The problem is that the PRT loader is locking the loaded frame, which makes Naiad throw an error when trying to overwrite it. Even closing the scene doesn’t release the hold - only when Max is closed is the file released, which is quite unpleasant.

Thanks!
Hristo

2

How about even if you load a single null/junk frame into the loader? It has been a while, I do recall this happening a while back.

3

Yeah I found out I can make it load blank outside range, and go to a frame outside range and park there while it’s simming.

4

So a non-cache frame on the timeline right?

I guess a good feature request might be a nice big bright red blinking defer load toggle? :mrgreen: (certainly of course only an implementation brainstorm suggestion, anything easily noticeable would work)

So for example, when you are doing concurrent application work, you could defer loading and flush memory of the prt will the other sim bakes, that way one wouldn’t have to mess with ranges, cache files, or any other settings, nothing worse that a simple miffed setting at 3:00 am.

5

Well, the best thing would be that it doesn’t put a hold on the file.

6

I believe this has been brought before.

Sure but how would it know? I mean it has to load it into memory. I am unaware of any application that lets you overwrite an open file I another application. I unfortunately don’t know if you can bypass that. But yes that would be ideal.

7

I have been complaining about it too (as it also happens when you resave PRTs out of Krakatoa).
I made sure it is logged.
Also I have had a Wishlist item for a while to allow recursive resaving like we do with XMesh files (loading previous frame, making changes, saving as current frame) which is currently not possible either. However, that is an explicit check in the renderer that tries to avoid loading and saving the same file at the same time, but applies to the sequence instead.

8

Thanks Bobo

9

That is an interesting approach :slight_smile: You wouldn’t need to defer loading then right?

10

Not sure what you mean when you say “defer”.

Currently the Krakatoa renderer refuses to output to a file sequence that is active in a PRT Loader.
It checks the sequence name and does not allow any overwriting of input files with the Save Particles To File Sequence output.

But if you need to do a History Dependent effect where you accumulate data in a PRT channel by loading from the previous frame, adding to the channel and saving in the current frame, then repeating on the next frame where the just saved data gets reloaded, modified and saved again and so on, a switch to suppress this check would be nice.

I really hope to have this in the next KMX update.

11

By defer loading, when enabled, any sequence or file in the PRT Loader listbox would temporarily deactivate the current timeslider frame and flush it from active memory. So basically disabling the PRT Loader so that any file within its listbox could be overwritten. Typically any file in the listbox can be overwritten as long as it is not the active frame, this would allow that. I guess this would be the same as what you describe.

12

The PRT Loader builds a Viewport Cache for display purposes. So if it is locking files, it is definitely a subtle bug somewhere and not because it actually needs the files locked to read from them. At least that’s my impression. We will continue looking into it.