Max 8 sp2, Krakatoa beta 16.
Start new scene, add a PRT loader, select a file (1 of 25), add a bend modifier.
This crashes max. I tried FFD 4x4x4 and noise, both crash max as well.
- Chad
Path Deform WSM works fine though.
- chad
Hmmm, I know we tested Max 8 with deformations before we posted the build, we actually spent a whole week fixing Max 8 crashes in deformations ;o)
(It is not as straight-forward as it sounds, we had to hack the Max modifier stack to get it working, and there were differences between 8 and 9).
I could reproduce this crash.
Deformations are very new and we fixed some other issues today where they were killing particle colors.
Max 9 should work ok with modifiers though - we are using them in production right now.
Ok, I’ll try that. We just installed beta 16 on 3ds max first since that’s where we have all our other plugins working.
- Chad
Trying this in max 9, the OSD like Bend and FFD 2x2x2 don’t get the correct bounding box. Is that expected?
- Chad
Edit: I tried to get the PRT Loader’s bounding box to manually set the modifier subobject TM, but it seems to just get the icon bounding box.
The Bounding Box of OSMs is based on the icon size of the PRT Loader.
This is because the icon size is constant, while a particle cloud is dynamic and the bounding box changes constantly from frame to frame, so the deformation would “jump” all the time.
Thus, you can just change the PRT Loader’s icon size to be the size of the bounding box you want. If you need PRECISE control over the bounding box, use a WSM Modifier-based deformer where you can type in the bbox size explicitly.
OSMs were a side effect of the fact we needed WSMs implemented. In many cases, they can be used, but WSMs were our main focus.
Hijacking the modifier system and making it do what we want without actually pushing vertex data through the stack was a nightmare.
In the case of my current PRT loader, it’s a single frame, so I didn’t worry about the dynamic bounding box. Would be cool if we had a button that set the icon to be the same as the bounding box of the PRT loader at the slidertime where the button is pushed. Like how the FFD has a “fit”.
I do say, running a Patch Deform Modifier on 53 million particles in the viewport is very cool. (using the velocity drawing method).
What methods should we be using to make deformers for PRT Loaders? We’re looking at making a skinning system that would be PRT-compatible, but don’t want to do anything “dangerous”.
At this point, we do not support skinning using Max Skin Modifier, but in general creating a SimpleMod which gets a position and index and outputs the resulting position is what should be safe. I even have scripted SimpleMod modifiers that work with (limited numbers of) particles.
Please see
http://support.franticfilms.com/manuals/index.php?title=Krakatoa:Particle_Deformations
for the current documentation and let me know what is missing.
From technical point of view, nothing should be dangerous (if it is a modifier and it crashes, it is a BUG, not a limitation).
But in general, we do not support stuff that is changing topology. Also, modifiers operating on vertices/faces as opposed on generic points are not supported (like SkinWrap for example does not work because it expects geometry but finds none). None of these should crash, it should just sit there doing nothing.
Bend and the other deformers operate on arbitrary point data, because they were made to work with meshes, patches, NURBS and splines, not just meshes. So feeding positions in and getting the positions out is all that is necessary. I actually got a Skin modifier to deform, but particles were being affected by just one bone (and the wrong one on top of that) and switching between bones over time, not knowing how to blend, so at this point we don’t really support Skin, but we might someday if we have the time to investigate.