There was some talk about making a new PRT spec. Is that going to coincide with Krakatoa 2.0? Or be discussed afterward?

• Chad

At this point we intend to release what we showed at Siggraph (but finished) as Krakatoa 2.0, then work on point releases to add the things we wanted but didn’t have the time to do. After all, we all want to see KMX 2.0 sometime this fall, not in 2012, right?

Also, we want to get PRT 2.0 right and work with our partners to make sure it does what it is supposed to do.
The initial list of ideas included:
*Metadata with coordinate system info, units info, user notes and whatever else might be needed
*Option to store Proxy representation of the cloud in the first N particles for fast previews
*Bucket-based storage for fast access to volumetric regions without the need to traverse the whole file

Please add to the list to have a discussion…

Dude! that is a most excellent idea! All of the others are by no means shabby either

Those three at least the first two would solve most issue I have ever had. Of course I haven’t had all that many huge ass files that I needed to worry about accessing halfway through the count in a frame to grab a sample of data either.

I am almost sure that came from either Chad or Ben

There’s nothing preventing that from happening now. You can write the points to the PRT in any order, so you can (today) do this.

Storing multiple independent zlib streams makes a lot of sense, since it would make it a lot faster to read PRT’s. Each stream could be decompressed on a differnt thread. I didn’t think about spatial division, though. If you did have them in blocks, you would know that at any point in space you would only need to expand one chunk to find the points there. Very interesting.

I’d like it if there was a vector that could be added to the header to indicate that the points were sorted to that location. Like when you save lit particles, they are sorted to the camera in the PRT file, so it would make sense to compare that sorting vector to the current camera and if they are the same, you don’t have to resort, making it a much faster render.

• Chad

So you saying just store in a chunk that is a Nth of the entire stream, right? The first chunk might, instead of (1 to 100), be (0, 10, 20, 30, ect.)

Here is a copy of the spec I proposed. The weakness of system is it requires the file-system to efficiently handle multiple unknown-length write streams into a mapped file or to make the chunk size small enough to fit into memory before writing.

Additional ideas would be to handle multiple compression algorithms. I also like having more asset tracking fields. This could either be a unique asset GUID or it could be a link back to the asset that created it.

Bounding box would also be nice.

With Krakatoa MY and SR getting into new folks hands, any more thoughts of updating the spec?

KSR and KMY are supposed to aim for feature parity with KMX 2. While the renderer is the same, a lot of things are still missing in KMY that we take for granted in KMX - shader support, deformations of PRT Loaders, Magma just to name a few. There are a few things that KMY and KSR can do KMX cannot (volumefill, deep shadows support), but I don’t think we will go ahead with PRT2 for their release. Possibly around version 3.

That does not mean we should not discuss the specs…

Actually, it’s because of the lack of feature parity that we’re asking.

We expect users to be moving PRT files between applications eg: KMY->KMX->KSR(py)->KSR(c++) to get the results they want. Having faster I/O or additional header data would help such users a lot. Especially for KSR(py), the PRT files are REALLY important. If we want to see good utilities like Partio or whatever, people will be looking at the PRT spec now.

Developers using KSR directly either need to read/write the PRT’s themselves to implement the features they miss from KMX or to deal with the data conversion from their applications. Aside from potential I/O speed gains, we’re using bounding box data and “PRT Generator Index” channels and would like it if that data could be used for other PRT-using applications. Obviously it’s something we need to discuss with everyone, but I think now is the time to do that since I expect now is the time when various parties are busy working with the current spec and may have ideas of their own.

Some of it may be low-hanging fruit, too, and could be something that only shows up in KMX later, but we could add advance support for it now. So maybe we start using “PRT Generator Index” now and later it gets added to the standard channel list. Or maybe adding some sort of bounding box to the header or some pre-sorted Min/Max/Mean indices could be done really easily, while we hold off on the multiple zlib streams until later.