It appears that prt_volumes are doing heavy calculations on every frame even if the dependent mesh doesn’t change. This calculation happens even if the prt_volume is hidden. I can’t scrub the time slider with no objects visible. Bug?
B.
The viewport cache is recalculated on time change, while the underlying volume representation is recached based on the validity interval of the source geometry. I haven’t looked at it in a while, but I think this behaviour is related to the ugly hack we use to get around the Max modifier stack. If you keep the viewport spacing high (meaning fewer particles) this should be less noticeable.
I’d prefer if it worked like every other object in max, where it doesn’t calculate if it’s hidden and all it’s defendants are hidden. If you used a hack once, make another hack that fixes this.
B.
For sure I can deal with the hidden thing. What happens when an object is hidden, but another object has a reference to it and depends on it? Should it still not update or what? As far as I know there isn’t a spec from Autodesk about what objects SHOULD do in all these situations.
Also on this topic, I’m looking at rewriting the PRT objects to be more Max-like but it seems like that is going to kill existing modifiers being able to run on them. Is this a deal breaker?
Are you going to let us know how to make new modifiers that do?
And you can always keep the old PRT object, no? For those cases when you need to apply an FFD or whatever? What do we get in return for losing the ability in the new PRT objects?
I’d like to expose a modifier SDK for particles to deal with losing Max modifiers in order to make up for the loss of existing Mesh modifiers.
I’m still experimenting to see what a real Max object SHOULD do in many situations, so I’ll make a list of why this is a good idea later and we can mull it over. There is a distinct chance that its related to how much I hate the code-base underneath, but that isn’t a reasonable justification for throwing out something that already works.
I just mean that you can maintain the PRT Loader / PRT Volume as-is and come out with new objects that operate under different assumptions. We can always save out a PRT and pull it into a PRT Loader if we need to. Will you be maintaining more code? Yeah, but I can’t imagine you’d be able to fend off the steady trickle of support requests wondering how to put a bend modifier on a PRT Loader in the latest version.
- Chad
Don’t forget that I have extensive practice at delegating those support questions to Bobo. . .
If we had a particle mesher and a way for KCM’s to reference other objects, I suppose reasonable workarounds could be made. But that’s a lot of work, even if some of it is satisfying other wishlist items.