View Full Version : Parts item not moving, but outlines are

09-24-2018, 08:35 AM
This is probably a basic problem... something I'm missing, except I used to set this up and have it work.

I set up a static body to be the ground plane. A parts body of a few dozen pill shapes in one layer. I start the calculation... the highlighted outlines around each pill move correctly, but the actual object geometry holds still.

How do I get it to act right? Thanks.

09-24-2018, 11:12 AM
1) Post scene?

2) Does Deformation have to be enabled?

09-24-2018, 01:37 PM
Well, my backup plan over-wrote both my object file and scene file, and now I can't reproduce the error. It's happened to me a few times in the past, too. I can get a good simulation of outlines of the geometry, without the geometry moving. But when it's just me testing, it will always work fine. Thanks, anyway.

09-24-2018, 01:58 PM
I think sub-patched objects in earlier versions of LW behaved this way?

09-24-2018, 02:16 PM
Oh, thanks, XswampyX! That must be it. Exactly what I was looking for...

09-24-2018, 02:20 PM
For subdivided objects in LW2015 or before, you need to have your Subdivision Order in the Parts Object Properties at least after Displacement:


In LW2018, it appears that Bullet deformations are always prior to subdivision.


09-24-2018, 04:25 PM
In LW2018, it appears that Bullet deformations are always prior to subdivision.

In LW2018, the modifier stack seems to allow putting Subdivision before or after Dynamics in the stack. How were you trying to adjust ordering?

09-24-2018, 04:39 PM
No, I was mistaken. The LW2018 Modifier Stack has Dynamics: Parts displayed for the Bullet Parts body, which could be dragged beneath Subdivision:


When I have the Ground Disc selected, it doesn't seem to have anything in the Modifier Stack to change evaluation order, even if the Static body is subpatched:



09-24-2018, 04:46 PM
Ah, yeah, that's normal. It's because a "static" object isn't really "participating" in Dynamics. It's being considered w.r.t. collisions, but Bullet isn't really having any effect on "static" objects themselves in terms of their form or motion. They're kind of the Dynamics equivalent of a "background image" in a rendered scene -- they're considered w.r.t. other objects' results, but the rendering doesn't really impact how the background itself looks.

Hope that helps!

09-25-2018, 12:58 PM
Thanks. As it turns out, Bullet ignores subdivisions on Static Bodies, only doing collision detection on the underlying geometry. So having a Dynamics: Static in the Modifier Stack would be extraneous. To have a high-resolution Static Body, you have to freeze the mesh.


09-25-2018, 03:43 PM
Interesting. I guess I see the rationale, but that really ought to be called out as a specific behavior in the docs, because it's by no means "obvious".

Hmm, thinking more on it, I'm really disliking that answer, it doesn't really make sense functionally.

Keep in mind, the issue isn't just about whether Bullet cares about static objects' subdivisions, after all, it's about the impact all modifiers have on each other that might be applied to the object, and using ordering to control those impacts. IMO, it's not reasonable just to "drop" Bullet from being listed at all just because Bullet itself doesn't care about Subdivision -- the modifier stack is about more than just Dynamics and Subdivision.

Instead, LW should either always show Bullet ("Dynamics: Static") fixed at the top of the modifier stack (with a special note in docs that Bullet doesn't consider object modifiers at ALL).


If other modifiers can affect objects' geometry "before" Bullet in static item cases, then LW needs to allow users to arrange the modifier ordering (incl. a "Dynamics: Static" entry) as expected.

The current behavior appears unclear/ambiguous and unpredictable in terms of how modifiers impact objects used as static items in Bullet processing. The current behavior is a UI/UX bug at best, modifier stack implementation bug at worst.

09-25-2018, 04:11 PM
In the FX Collision object, we had the option of specifying how the Collision object's geometry / mesh is interpreted, including "Object", "Object-Subdiv", "Infinite" and "Object-Advanced":


This allowed the user to choose the level of detail they require, at a computational cost for more detail of course.

IMO, Bullet should provide equivalent options, which would make a Dynamics: Static modifier in the Modifier stack relevant.


09-25-2018, 05:42 PM
IMO, Bullet should provide equivalent options, which would make a Dynamics: Static modifier in the Modifier stack relevant.

Think broader. With modifiers like Metamorphic, just because something is "modified" doesn't automatically mean its being actively deformed during Bullet operation. As I said, it isn't just about how Bullet sees the object during evaluation, it's also potentially about what can be done to the object before any dynamics evaluation begins, or after it finishes.

Sure, the user could "freeze" the Metamorphic-corrected object's geometry out again, but really, we want more dynamism in evaluation, not less. Taking control over when Bullet evaluates geometry is a bigger deal than it seems, and it isn't just about whether it does so "live" either, it also impacts ability to use modifiers for "static adjustments" to fix geometry. That's a bigger deal.

09-26-2018, 04:42 PM
LW needs to provide a means for users to clearly indicate when modifiers are "active" for an object, versus when they are present but not actively changing objects' geometry. Without that, LW faces difficulty (read as: significant stability risk) determining whether deforming geometry can be cached, or needs to be regenerated (sub)frame-by-(sub)frame. Presuming that all modifiers are always active is highly wasteful and performance-detrimental, but as currently implemented, either LW does that, or tries to make some inherently-fragile determination of when each modifier is (as well as could be, the difficult part) active.

For example, "Static" meshes aren't just limited to dynamics, there are lots of cases where a modifier may evaluate the presence or extant geometry of an object without actually deforming it. Knowing at a modifier stack entry level whether the modifier treats the object as a "static participant" or will actually be deforming the object (and if the latter, over what range of frames) would allow a much more reliable and performant geometry caching implementation as part of the animation system.

As a tangible example of other non-dynamics cases where objects participate as "static participants", consider cases like collision deformers, particularly in how the "penetrating object" participates in the evaluation. While the penetrating object doesn't have to be a "static participant", if there's nothing else deforming that object while the collision deformer is evaluating it, then it effectively is a "static participant", and its geometry can be cached -- and the cache (re)used in the modifier's evaluation, instead of continuous live evaluation (offering significant perf. optimization ability).

Right now, the existing implementation is incomplete, failing to provide developers with information needed to properly (and performantly) implement modifiers and integrate them into the rest of the animation system. Attempting to resolve certain other issues, the LW devs already implemented certain workarounds which made the ability to properly implement performant modifiers more difficult (as discussed above).

The LW devs already face plenty of situations where due to prior "less than well-considered" fixes and workarounds, significant LW architectural improvements now require horribly costly and major infrastructure reimplementation. They need to stop and figure out how they intend for modifiers and dynamic geometry caching to work together in LW's animation system going forward (and more generally, how dynamic geometry caching integrates into the anim. system overall) before this becomes another such situation.