Really interested in SSD since more and more reliance on single threadedness bottlenecks and caching to disk just keeps increasing, nice to see some specs and thoughts from those that get to play with the latest and greatest.
Mmmn, I see, so if you deleted it and then recreated it a few frames later would it come back with the same ID, wouldn’t it? A visibility bool?
PRT Volume in Pflow or TP would be a big fat slice yum.
Well if those tidbits just didn’t start me drooling all over my keyboard…do tease please
I have no way of knowing, since the “Retrieving Particles” doesn’t break it down to read vs decompress. But I suspect that they are interleaved since it isn’t broken down. Read some, unzip some, read some, unzip some, etc. If that’s the case, then it wouldn’t be full out saturating the I/O. It might also be sending really itty bitty I/O requests, too, which would be worst case for the SSD. Not sure what kind of I/O the z_stream generates.
It may be CPU bound, yes, but it’s not multithreaded. But how often are we reading in a single PRT? It might be easier to just handle multiple PRT reads/unzips simultaneously. You can now (affordably) have 48 core workstations and farm machines, so it can be pretty crappy to have just one core pegged.
We were (for workstations) very close to getting some 48 core machines. AMD makes some really cost effective solutions now that the “4 socket tax” is gone. The problem is that while we would have completely awesome Fusion workstations, too much of 3ds max isn’t multithreaded. We’re still looking at them for VM servers, though.
-PRT Mesher (-PRT Shape Instance (if the mesher will work with other renderers, we might as well include a shape instance to choose any geometry for each particle )
-KrakaGlow - Inspiration would be kytrail plugin, which is sometimes able to create a similar look to krakatoa voxel renders, but usesalot less particles, and can create trails and other useful things for motion graphics and fx, so a glow around the particles (and u cannot get same glow as kytrail just by doing post effect)- and more options of choosing the visual style of the rendered particles, it also uses the trajectory as a trail path, but this is different than mere motion blur, it would really allow new possibilities and integrate new options of rendering particles (i know there might be people that dont see the point in this one, but this is my wishlist and looking at kytrail i could think of many ways of making a better version that is fully krakatoa integrated)
-Variable Point Scale, regardless of “correct lighting” let us determine the size of the particle “pixel”, for non-realistic renderings, similar to viewport where the particles are bigger
(-Voxel Scale - let particle scale determine voxel size, similar to matthias idea and the one above, but universal for particle renderer as well)
What is the top one annoyance / weakest feature of Krakatoa as of v1.6.0 (for example, prior to v1.6.0 it was probably the Shadow Casting on Geometry workflow).
Render settings taking long time to load because of deadline search
– edit – just saw “Do Not Detect Deadline” in the drop-down list
If you could optimize/improve just one existing workflow in Krakatoa to make you more productive, what would be it? (Examples: Saving Particles, Iterative Rendering, integration with other renderers, integration with compositing applications etc.)
-PRT Noise Offset at Render w/ clone count // Would be nice to not have to partition something just to try if 10 partitions with tiny noise offset would work for a setup, but just at rendertime set the noise size, and amount of partitions, and do this process automatically at render time, so PRT loader --> render setup --> noise size --> prt count (how many times to duplicate prt with random seed noise) --> render!
)