I’ve not found how to load the sequence automaticly for all the frame numbers. The auto loading dialog is working well for partitions numbers but i can’t make it to work with a single partition saved for each frames.
The weird part is if i manually load the first 3 or 4 PRTs Krakatoa is working as expected, loading the particles in the corresponding frames and so.
But if i generate a file list and try to load the PRTs though the list, the PRT loader detects and list the files as existing but i can’t render anything : the particle counts are going crazy, even showing negative values for certain frames. If i press “update” on the particle count graph tool, i get a maxscript error ‘append function not existing for undefined’ of something like that.
Can you help me ?
any method for automatically loading a PRT sequence of 1000 frames (1 partition) will be appreciated
Note : the PRT files are generated by maxscript from some source data files, they are not saved via the renderer. Those PRT files are working well individually but maybe i’m missing something when generating them for a frame sequence usage ?
Am I understanding correctly that you are adding these file lists via MAXScript to the PRT Loader?
If that is the case, there is a catch: There are TWO properties that must be set at the same time for the PRT Loader to work.
The one property is the array of files (.fileList), the other is the array of integers corresponding to the bit flags defining the Render and Viewport visibility of these sequences (the “vr” flags in front of the list and the checkboxes underneath).
So if you select a PRT Loader and set its list like
I admit this could be documented a bit better and a function could be provided to deal with the synchronization of the two arrays (you pass an array of file names, it sets the flags automatically or something like that).
Hello again. Problem is solved. I used the “limit to custom range” parameter which cleared the problem.
Either krakatoa does not handle automatically the range limits for time sequences (my timeline was lasting longer than the particle sequence), either one of my PRT file was corrupted.
Still a question : is it a normal behavior that the Particle count tool shows an increasing “render count” while advancing the animation in time ? It behaves like accumulating the total particles, regardless of the frame number.
Note : to easily debug my scene is used your advice and used maxscript to load the PRT file which runs smooth :
fl = #()
flf = #()
maxStep = 1130
for i = 130 to maxStep do (
fichier = "F:\RPCDM\particles_part01of01_" + (formattedPrint i format:"4.4d") + ".prt"
append fl fichier
append flf 3
)
$.fileList = fl
$.fileListFlags = flf
Best regards,
PGD
*------- pgdavid wrote :
Hello bobo !
Thanks for your quick answer. That not the problem. I’m manually adding the file list through the dropdown menu of the file sequence manager.
And i already tried earlier to write the filelist like that (but found that omitting the flag loads the file in the same way):
But the problem is still there.
I’ll try to write a maxscript to load the PRT to see if it makes any difference.
Note : in your exemple, you write filename of PRT files for a partionned set (part001of 100 …) but for time frame 0. This is working well in krakatoa. The thing that i can’t get to work is loading a large (1000+ files ) time sequence with filenames like particles_part001of001_00xx <<< where only the 4 last digits change.
There might be a misunderstanding of how the particle loading works.
When “Load Single Frame Only” is UNCHECKED, the frame number in the file name is REMOVED and REPLACED with the current time.
So if you add several frames of the SAME sequence with different frame numbers, they are ALL the SAME sequence in the eyes of the PRT Loader.
That’s why I was adding frame _0000.prt of both sequences (notice that I had the partition counter increased in order to make them two different sequences) - that 0000 only defines the number of digits to expect and replace with the current time (which is also shown in the PRT Loader’s UI at the bottom of the Timing group of controls).
If you check “Load Single Frame Only”, the file names are taken verbatim without modifications, so if you took “particles_0012.prt” and “particles_0042.prt” and put both on the list, PRT Loader will assume you really want to combine the two frames of the same sequence As Is without replacing 0012 and 0042 with the current frame time.
I am not sure why you are trying to add frames of the same sequence to the same PRT Loader, but that is not something I would ever do.
Can you explain again why you are doing what you are doing?
The Custom Range Limit option in the PRT Loader can be set to tell the PRT Loader what to do when a frame is requested – say, you have loaded “particles_0000.prt”, there are frames from 0000 to 0123, but you move the time slider to 0234. In that case, the frame counter of all sequences will be replaced internally to build “particles_0234.prt”, that file does not exist and the PRT Loader would fail. If you enable the Use Custom Range, you can specify 0123 as the highest allowed frame and any frame above that would be either replaced with the frame 0123, or, if you set it to “Blank” instead of “Hold Last”, will output no particles.
I am not sure what the render particle counter is showing, if the content of the frames is changing over time, then it will reflect the count at the current time. So if you have a sequence that has more and more particles on each frame and put it in the PRT Loader, moving the time slider should show you the count increasing as the frame number is replaced with the current time’s frame number. If you add the same sequence multiple times (which the UI functions try to prevent normally), then you have that same count, multiple times and changing over time.
the source data is coming from a scientific simulation done a big calculation server. Particle movement has been calculated using complex cosmologists algorithms so i have to render the particle positions at each time steps “as is”, without performing anykind of collision tests or so as those have already been done in the scientific simulation.
Or in other words, to be sure i’m clear, I’m using krakatoa as a scientific visualisation tool, where i want to render each time steps of a simulation, where each time step of the simulation is writen in a single file (converted to PRT) wit hthe 4 last digits being the frame number.
err i must miss something. Krakatoa do loads each file at each frame number when i leave the "load single frame " unchecked. If i check it, the same particle positions are show all along the animation.
If the sequence has changing frame numbers and the base file name is the same, you have to add just ONE representative frame of the simulation in the PRT Loader and it will deal with the time changing. You have to load more than one frame on the list ONLY if you want multiple sequences to be loaded (like the Partitioning stuff we do). For example, if you had the Milky Way in one PRT file sequence and the Andromeda galaxy in another and wanted to render both, you would load “milkyway_0000.prt” and “andromeda_0000.prt” in the PRT Loader and it will load them both, while replacing the frame number based on the current scene/render time. That’s all you have to do. You don’t have to load 1300 frames of each into the PRT Loader, just one of each.
And I know what you are doing in general (you have shown me some results in the past), I just wanted to understand your logic for doing what you are doing…
You are not missing anything.
If “Load Single Frame Only” is checked, and you have added 100 sequences like “particles_0000.prt”, “particles_0001.prt”, … “particles_0099.prt”, EACH one of them will be loaded AS IS, so you should get a particle system that contains 100 frames worth of particles squeezed into one (time does not flow, and you see 100 frames a la Motion Blur). But they won’t change over time because their frame numbers are not modified.
If “Load Single Frame Only” is unchecked and you have those 100 frames added to the list, EACH one of them will be changed to 0000.prt on frame 0, to 0042 on frame 42 etc, so you will be loading the SAME particles 100 times, getting 100 times higher density, and WASTING TIME (loading 100 files is just SLOOOOOW) )
I hope I explained it better now. One sequence - one file name. Done.
Yes if i leave unchecked i’m loading the same particles, but not at the same position right ? (the position data in the file is different). Your message sounds like i’m not doing what i expect.
How to load file particle_0001.prt in frame 1, particle_0002.prt in frame 2 … particle_000x in frame x then ? Without raising the particle count for a given frame, and letting the time flow ? I’m in dire need of that.
It is not so much what you are doing but what you THINK you are doing ;o)
The fileList is NOT a list of frames in time - it is a method for combining mostly unrelated particle data into one cloud.
In other words, adding 1000 frame file names from the same sequence to that list WON’T play them in order from 0 to 1000 over time of 1000 frames, it will load ALL 1000 and the SAME data, same positions, on top of each other, according to the current time.
So leave it unchecked, don’t add 1000+ sequences there, just one representative for all of them.
Add ONE frame only, regardless of its number (think of the 0001 as ####) and let the PRT Loader do the rest. When the time changes, the #### will be replaced with the correct frame number INTERNALLY and the right particles will show up.
I will try to change the code for v1.6.0 to actually show #### in the list box when “Load Single Frame Only” is unchecked to make that clearer.
Don’t worry, I am happy you understand the idea now. I admit it could be misleading, so we added the #### display to the list now - if you check “Load Single Frame Only”, the actual frame number picked in the file dialog will show up. If you uncheck it, the frame number will be shown as #### again to give the right idea.
Thanks for the feedback, you might have saved other people from going through the same in the future.
)
behavior is obvious when you get it )