Wishlist for 1.2

Deprecated Krakatoa 1.1 Beta Discussion
1

NOTE: The original message by Chad was destroyed while attempting to move the thread to the 1.2 conference.

Here is a repost:

====================================

I’ve gotten more feedback from artists here at ATI regarding Krakatoa, and some wishes have been expressed.


  1. There’s a wish for a density multiplier in the PRT Loader. The Visibility channel is considered awkward, and since it clamps at 1.0, it’s not much help. So maybe adding a spinner in the PRT Loader for density multiplier?


  2. The viewport/render toggling in the PRT Loader is super nice, but some users have expressed a desire for some more automated way of making proxy PRT files. Something that would make several PRT sequences with different offsets of N points. That way we could convert say, 450M points into 10 different sets of 100,000 points, then have those 10 PRT’s loaded into the PRT Loader and used for the viewport. With 10, we can easily set the display to show a multiple of 100,000 or whatever, depending on the interactive refresh rates we can sustain. It’s possible for us to do all of this now, but it almost requires a TD to handle the optimizations, and all people want is the ability to show more of less of the render resolution in the viewport quickly. Being a TD, I didn’t think this was that hard, but it seems I was mistaken.


  3. Separate cache for the PRT files themselves. The idea is that users might want to have one cache that represents what is sent to the render (what we have now) and another cache is just the PRT data itself. So the PRT Loaders would each have an independant cache, and that would be re-used as we made changes to the modifier stack. This way we could turn on and off PRT Loaders in the scene, or make changes to individual PRT Loaders, and we wouldn’t have to re-cache ALL of the PRT Loaders. This obviously would at least double the amount of memory required, but if you have the memory, it would provide a large productivity boost.



    I have some more wishes that are “my” wishes, but I’ll make separate posts for those. These are wishes “from the trenches”.

====================================

Bobo’s answer:

  1. and 2) are both valid and relatively straight-forward. The Density could be adjusted using the upcoming channels copying modifier, or in the PRT itself.

    We have discussed creation of proxies and all we need is some development time to implement methods for resaving an existing stream with different settings to new locations.

    Thanks for the suggestions, we will log them and try to address them.


  2. is tricky though - the cache we have (and Krakatoa as renderer) does not know which particle came from which PRT. There is one pool with named channels, and all data, both from scene objects and PRT loaders, is stored in these channels with no way of knowing which particles to replace if you made a change in your PRT. I am not saying it is impossible, but would require some serious rethinking of the internal architecture. I will leave it to the developers to comment on in detail though…
2

In the case of 1), we find that density is probably the MOST touched setting in Krakatoa. Reason being that we rough in an pointset with 100,000 points, and then up it from there. As we add more points, we have to keep adjusting the density to compensate. And when you have multiple PRT Loaders involved, you might be trying to balance densities between them, even though they have different spatial densities.



For 3), I was thinking that there would be no change at all to the current cache system for the renderer. I was just thinking that maybe there could be a separate cache implemented in the PRT Loader that would let it keep a cache that would be passed to the regular, current, Krakatoa cache. When we start modifying channel data or reading in Nth points, the lag from the PRT Loader IO is pretty significant. This would be similar to how, say, PFlow will (or at least can) cache the particles separately and pass that to Krakatoa.


  • Chad
3
  1. Ben Lipman is asking when we can make some PRT Modifiers. PRT Skin, PRT Paint, PRT Attach, etc.


  2. Any word on when the PRT Mesher might go to public beta?


  • Chad
4
  1. Render Selected. I want to just have Krakatoa use the objects selected for the rendering if I use this mode. So it would check to see if it is selected AND if it is a type specified in the Krakatoa panel (PFlow phantom, Geometry vertices, etc).


  • Chad
5

>
>5) Any word on when the PRT
>Mesher might go to public
>beta?
>
>- Chad

a mesher for the cached out PRT loaders.


now that would be cool!


what about iso surfaces?


cheers
6

what about iso surfaces?



That’s what it does in essence. You could potentially load a BIN file from RealFlow and mesh it on the fly with it instead of using RealFlow’s meshing. Or take any PRT from Max and turn it into blobs.



It has a preview mode with spheres, but the main purpose is creating blobs.


7

very cool, im super excited to see that released!



cheers