Are PRT's all loaded at once?

Deprecated Krakatoa 1.0 Beta Discussion
1

If I have a PRT loader with 50 partitions, and I load First N, 1%, does it load the first 1% of each PRT, or does it total up all the PRT counts and load in 1% of the total starting from the first PRT on?



Why do I ask?



Partitioning largely assumes that any one partition is pretty much the same as any other, just with different seeds. A future option that would be nice to have is the ability to load a % or limit of just ONE PRT, say the first one? I don’t mind having all of part001of100 loaded, since that’s, in theory, 1% of the particles.



So maybe an option for “First N partitions” and it loads the whole PRT (or CSV), but not the other PRT’s in the file list.



Low Priority :slight_smile:


  • chad
2

If I have a PRT loader with 50

partitions, and I load First

N, 1%, does it load the first

1% of each PRT, or does it

total up all the PRT counts

and load in 1% of the total

starting from the first PRT

on?



Why do I ask?



Partitioning largely assumes

that any one partition is

pretty much the same as any

other, just with different

seeds. A future option that

would be nice to have is the

ability to load a % or limit

of just ONE PRT, say the first

one? I don’t mind having all

of part001of100 loaded, since

that’s, in theory, 1% of the

particles.



So maybe an option for “First

N partitions” and it loads the

whole PRT (or CSV), but not

the other PRT’s in the file

list.



Low Priority :slight_smile:







When you have First N, it gets the counts of all PRTs, then starts with the first parition and loads until the 1% of the total count is reached. Thus, the first partition would be loaded, the rest might never be opened.



If you have Every Nth, it loads every Nth from each partition.



NOTE that CSVs are ALWAYS loaded as Every Nth, even when the loader is set to First N, because we don’t know how much we will load. It just says, ok, 1% means load every 100th particle. We load one, skip 99, load one, skip 99 and so on.



In the future, I would love to add a way to disable partitions in the PRT Loader (like a checkbox in front of each partition), so we can temporarily disable any of them at will.



Also, if you have PRTs with First N, you can use the Reorder > To Top option in the File Editor to define which partition will be actually loaded first. That’s why we do have those reorder methods to start with… it is even more important if you are loading two sequences that are NOT partitions, like a teapot and a sphere sequence. If you want to see the teapot but not the sphere, you can move the teapot sequence to top and the loader will always start with it. You want the sphere? Reorder the list and the Sphere will load first. (When First N is set, of course)


3

Oh, ok. That would explain why my loaders are looking more even as I add more PRT’s to them. It’s loading more of the first PRT.



On a slightly related note, can modifiers get PRT channel values from the PRT Loaders? Like if we wanted to make a PRT Select modifier, or a PRT Delete Point modifier, or PRT Clone modifier?


  • Chad
4

Oh, ok. That would explain

why my loaders are looking

more even as I add more PRT’s

to them. It’s loading more of

the first PRT.



On a slightly related note,

can modifiers get PRT channel

values from the PRT Loaders?

Like if we wanted to make a

PRT Select modifier, or a PRT

Delete Point modifier, or PRT

Clone modifier?





Max was not designed to do what we are doing with Particle Modifiers. It is a wonder that it works. Basically, instead of evaluating the modifier pipe like Max does, the PRT Loader gets the modifiers, evaluates them itself and shows the result in the base object. So we HIJACK the modifier stack to do the deformations, but there are no particles actually moving up the stack the way vertices do.



Having said that, if a modifier higher on the stack would contain a bitarray of indices and the PRT Loader would use that data to ignore particles, or apply deformations only to the ones on the list, it would potentially work. But that would assume that you are showing millions of particles in the viewport and saving explicit lists (read: millions of bits) in each modifier, something Max wouldn’t like.



Thus, the Volume Culling we added IS a form of a “Volume Select + Delete” modifier. We could potentially go the same way and allow you to add real Volume Select modifiers where the gizmo defines the spatial selection without explicit lists and following deformation modifiers would for example affect only particles within that volume, or assign a material based on the selection (remember? we were talking about gizmo-based shading before!)



The idea is really cool and I will add it to the wishlist so we don’t forget about it…

5

I was more wondering if we should be making custom modifiers for the PRT Loader or making our own PRT base class, and making modifiers for that.


  • Chad
6

I was more wondering if we

should be making custom

modifiers for the PRT Loader

or making our own PRT base

class, and making modifiers

for that.





Our plan is to define a Krakatoa particle manipulation interface that anyone could use to create Krakatoa-specific modifiers including procedural selections, adding and removing particles, affecting any particle properties (like position, velocity, color etc.) and so on. This way, we would allow 3rd parties to develop their own modifiers as they see fit.

Also, we could generalize the way we deal with deformations AND culling and allow you to use gizmo selection and particle deletion at any point of the stack instead of the current fixed order of culling after transforms and space warps.