Skinning is crazy slow. And I understand why. But maybe we can:
make the renderer more responsive, indicate more info about what is going on. I only see “retrieving particles” this doesn’t tell me if it’s an IO problem or the kcm or the skinning and which object has the problem.
I’m always in favor of more granularity of where the caching happens. Currently the pcache is only useful for the step right before the lighting. What about before the material? or before some or all skinning or kcm assignments. I can’t change the density without throwing away the pcache (with the skinning)
create scripts that assist with baking of kcms and skinnings. I don’t mind saving prt’s when I’m making a new asset. What is tedious if I’m using SaveParticles render as a cache in my existing workflow. example (make a smaller prt just for viewport speed: * hide other objects
turn off viewport xform
fix culling
change viewport/render settings
render
change all settings back
import new prt
further adjustments and/or linking if new object
Inevitably, I mess something up in the settings. Also this discourages iterations.
The problems here are pretty generic and not specific to skinning. Mostly my waiting over an hour for “program not responding” to go away. (cancel doesn’t work either)
I think we need the KCM concept on the renderer itself. This way we can make the renderer make more sense on a per case basis. I want to compose the procedure instead of this one-size fits all solution.
I would love this too, not sure how much is technically possible though. KSW is just another modifier. Krakatoa tells the PRT Loader (or whatever object) to give it particles and that object evaluates its stack. We should investigate whether it would be possible for Krakatoa itself to report what the objects in the scene are doing with various deformers on their stacks. It might be possible with the PRT Loader since it is the one running the stack, not sure about other types of sources. As for the skinning speed itself, it is the performance of the Nearest Point function that is making it slow. I benchmarked something related to that kdtree code the other day and our NearestPoint function is about 10 times slower than our RayIntersect function. When using Radius-based skinning (as opposed to Count 1), a large number of nearest point lookups have to be performed which makes it even slower. Not sure how much actual speed up could be introduced in that code unless we can find a way to multithread inside Max modifiers (don’t think that is safe yet).
The PCache is simply the final state of the particles in memory from the previous rendered frame (we just don’t release the memory). Since the Lighting channel is something calculated by Krakatoa (as opposed to most other channels that are provided by scene objects), we could allow the relighting of pre-loaded particles when LCache is off. Only global properties like the Global Density multiplier can be changed with PCache on. Currently, the particles in PCache don’t know what system they came from, thus it is not possible to update specific channels like those set by Materials or Modifiers. If you see the previous discussion about local caching and SourceID channels, the SourceID approach could allow us to know which particle came from what object and potentially allow the updates of any channel (say, per-particle density, color, specular level etc.) by reevaluating the materials or modifiers applied to the corresponding source object even after the PCache was populated. This is one of my favorite wishlist items and I will keep on pushing for its implementation.
There is a large refactoring task planned that would make the “Save Particles To File Sequence” a separate function of Krakatoa independent from the Render call. Thus saving particles would become a special feature (that could be called from MAXScript) and not something triggered by pressing the Render icon of Max (or calling ‘Max Quick Render’) in a special mode. We have been pushing this back because of the complications it will bring to Deadline processing - all partitioning would have to be done via scripting and the current potential ability to just send a regular network job in Save mode to Deadline or Backburner would be lost. On the bright side, this approach would make the development of the kind of tools you mentioned much easier as it wouldn’t require major tweaking of the UI settings to achieve the desired result.
Allowing some form of KCMs to run post-cache would be quite useful to tweak things inside the renderer. But keep in mind that we are aiming at a separation of Krakatoa from 3ds Max, and we don’t know whether KCMs will make sense outside of Max at this point (what would a Softimage user do with KCMs if he has the glorious ICE?). I know you probably don’t care about non-Max users, but we have to take these future plans into account.
We used to have some larger plans along the lines if modularized Krakatoa stages glued together by some sort of graph (think Krakatoa Schematic Flow with actual user-defined wiring) or script. In theory, in that model one could wire a custom renderer that behaves as desired by the pipeline developers instead of how Darcy has hardwired it. Unfortunately, this major change won’t be part of 2.0 as it is scheduled right now. But I hope some of the other improvements will ease the pain…
Multithreading inside of a Modifier::ModifyObject() call is safe. I’ve been using OpenMP just fine for processing arrays of points and meshes. TBB should work as well.
For our needs we might be able to record some sort of index channel that corresponds to the face index, or bone index at the time of prt creation. If we limit the bone count to 32 it could be a bit array. I kind of like using a higher order surface to describe the deformation like the FFD or SkinWrapPatch rather than storing multiple bone/faces per points. Then each point only has to know the index of the closest or bound patch.
I could prototype something if I had a little guidance on read/writing krakatoa data. I would need an interface to get and set points. Can I use Object::GetPoint() or is there a special interface to get the position channel. Do I need a special krakatoa SDK?
Reguarding krakatoa as a portable renderer. That’s fine but I just need something that stays fun and easy to work with. I get great results sometimes, and terrible painful results other times.