first of all i suck at c in any possible way so bear with me and my questions. For various reasons i would love to read/write PRT files in various applications.
Now while there is an excellent spec for the format i am still struggeling due to my c++ inability. There aint a working read/write example i assume ? (Asking can never hurt )
Now hereās what bothers me most atm:
What would you guys say is the best way to handle reading and writing PRTs ? When asking a friend of mine how he would takle it he threw some pseudocode
at me :http://pastebin.com/d4d333209
The simpler way (that would be slower to use according to him) would be creating templates for each possible channelType individually and use them in a container with lists of arrays.
What is the appropriate way to tackle getting the data in right ?
On a second note due to the actual data beeing zlib compressed i do have to read all the particle data in first, inflate it and access particles afterwards.
Is there any way to directly load only parts of the particles ?
Kind Regards, and thanks in advance for even reading my gibberish
ZLib supports streaming decompression, which is what our PRT implementation uses. In the zlib docs, please refer to zlib.net/manual.html#struct%20z_stream_s. You would load a chunk of compressed data using a std::ifstream perhaps, into a buffer of some fixed size. Then you would set the next_in member to point at the start of this array, and the avail_in member to be the size of the array. After a call to inflate(), ZLib will decompress as much of that array as it can, leaving the amount of uncompressed bytes in the avail_in member. You would then re-fill the input buffer, and call inflate() again.
Regarding a system for working on particles in the PRT format: The simplest approach that you mention has the drawback that accessing multiple data members within the same particle will potentially cause cache misses, since the individual members are stored in very different locations. We use a system where each particle is stored as a contiguous block, and we use accessor objects to extract the individual data members of a particle relative to the start of a particle.
If you arenāt doing heavy processing (ie. multiple passes), the performance difference is probably negligible. The simpler solution is probably a lot easier to code, debug, and maintain.
(thatās the cigarette smoke example by Allan McKay of course )
While i was at it i remember rumors of a standalone or āSDKā version of Krakatoa to be integrated into other apps by either frantic or third parties.
Has there been any thoughts or updates on that side ?
Note this is neither a complete implementation nor really useful in its current state but it showed a lot of potential for me.
I was rather surprised at the speed it gave even tho going the ascii route.
With 8k particles and creating textured quads on the fly (opacity mapped with a radial gradient) i can still get 15 fps in the viewer.
Nukeās scanline renderer is a different issue tho
The Nuke SDK (referred to as NDK mostly heh) is part of every version you can install. so if you grab the installer from their page and install it it comes with
the full NDK (including docs)
Regards,
Thorsten
P.S. the 3D system is due for an overhaul tho if i am not mistaken.
)