AWS Thinkbox Discussion Forums

PRT Loader with CSV and Load First Nth

Deprecated Krakatoa MX Beta Bug Reports
#1

Loading some CSV’s (yay!) into the PRT Loader, but the “Load First Nth Particles” mode for the viewport doesn’t seem to work. My particles are written in order of ascending Z position, so I should see particles being filled in from bottom to top. But instead it appears to be doing the “Every Nth” method and sparcely filling the volume evenly.



Saving out the PRT Loader to a .PRT allows me to see the bottom to top filling I would expect.


  • Chad


#2

This is the expected, yet not quite documented behaviour. We cannot load the first N particles from a CSV file because we do not know how many particles are in the file.



We made the decision to avoid counting the number of newline characters in the file because this is non-trivial for any decent sized particle file.

#3

This is the expected, yet not

quite documented behaviour.



It is documented now, at least in the internal version of the reference.

#4

But if the % is 100, and the limit is say, 2 x 1000, can’t you just read in the first 2000 lines of the CSV?



It’s not a huge deal, just caught me as odd. Now that I understand why I can cope.


  • Chad
#5

But if the % is 100, and the

limit is say, 2 x 1000, can’t

you just read in the first

2000 lines of the CSV?



It’s not a huge deal, just

caught me as odd. Now that I

understand why I can cope.





That would be a special case. In 90% of the cases, the limit is not enabled and the Render % might not be 100. (In fact, I have never used either Limit in my life.)



The trouble is that if the limit is 2x1000 but the file contains 1000 and you requested 50%, you wouldn’t get 500 particles, which would be worse. The limit is just an emergency brake that stops loading if the number of loaded particles reaches that number. It does not really define any normalized space to calculate percentages from. If the Render % was an absolute count, it would have been possible, but we wanted it to be relative to whatever the count is, and unfortunately we don’t know what the count of a CSV is.

#6

But if the % is 100, and the

limit is say, 2 x 1000, can’t

you just read in the first

2000 lines of the CSV?



This seems reasonable to me, I like the idea of matching the behavior of PRTs as closely as possibility within the informational/performance constraints we’ve got with CSVs.



-Mark

#7

But if the % is 100, and the

limit is say, 2 x 1000, can’t

you just read in the first

2000 lines of the CSV?



This seems reasonable to me, I

like the idea of matching the

behavior of PRTs as closely as

possibility within the

informational/performance

constraints we’ve got with

CSVs.




So the limit would practically become the "count" of the CSV file?
In that case, should I make the Limit values animatable so people can dial in varying limits per frame matching the actual counts in their files?

Even more, shouldn't then the Limit REPLACE the count for ANY file incl. PRT and BIN? If the Limit is lower than the count found in the file, the Render Percentage would apply to the limit value and not to the actual total? Right now, the limit is just a cap of the count, not a real guideline affecting the Render Percentage. If CSV files would use it in that manner, shouldn't all files do that for consistency?

Opinions?
#8

That’s not quite what I was imagining. Rather, I saw 100% as a special case, where it can behave just like with PRT files. Any % below 100 would behave exactly as it does now.



-Mark

#9

That’s reasonable sounding to me, but I suppose it will be a dead issue once we get the PRT spec as that will probably reduce CSV usage dramatically.


  • Chad
Privacy | Site terms | Cookie preferences