Results 1 to 14 of 14

Thread: Parts item not moving, but outlines are

  1. #1
    Super Member Nangleator's Avatar
    Join Date
    Sep 2007
    Location
    Massachusetts
    Posts
    2,142

    Parts item not moving, but outlines are

    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.

    We may have democracy, or we may have wealth concentrated in the hands of a few, but we cannot have both.
    ─Supreme Court Justice Louis D Brandeis

  2. #2
    Axes grinder- Dongle #99
    Join Date
    Jul 2003
    Location
    Seattle
    Posts
    14,741
    1) Post scene?

    2) Does Deformation have to be enabled?
    They only call it 'class warfare' when we fight back.
    Praise to Buddha! #resist
    Chard's Credo-"Documentation is PART of the Interface"
    Film the cops. Always FILM THE COPS. Use this app.

  3. #3
    Super Member Nangleator's Avatar
    Join Date
    Sep 2007
    Location
    Massachusetts
    Posts
    2,142
    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.

  4. #4
    Super Member XswampyX's Avatar
    Join Date
    Aug 2010
    Location
    Kernow
    Posts
    2,095
    I think sub-patched objects in earlier versions of LW behaved this way?

  5. #5
    Super Member Nangleator's Avatar
    Join Date
    Sep 2007
    Location
    Massachusetts
    Posts
    2,142
    Oh, thanks, XswampyX! That must be it. Exactly what I was looking for...

  6. #6
    Registered User
    Join Date
    Jan 2005
    Location
    Colorado Springs
    Posts
    1,864
    For subdivided objects in LW2015 or before, you need to have your Subdivision Order in the Parts Object Properties at least after Displacement:

    Click image for larger version. 

Name:	LW2015_AfterDisplacement.jpg 
Views:	37 
Size:	992.6 KB 
ID:	142879

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

    mTp

  7. #7
    Electron wrangler jwiede's Avatar
    Join Date
    Aug 2007
    Location
    San Jose, CA
    Posts
    7,057
    Quote Originally Posted by MonroePoteet View Post
    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?
    Last edited by jwiede; 09-24-2018 at 04:43 PM.
    John W.
    LW2015.3UB/2019.1.5 on MacPro(12C/24T/10.13.6),64GB RAM, NV 980ti

  8. #8
    Registered User
    Join Date
    Jan 2005
    Location
    Colorado Springs
    Posts
    1,864
    No, I was mistaken. The LW2018 Modifier Stack has Dynamics: Parts displayed for the Bullet Parts body, which could be dragged beneath Subdivision:

    Click image for larger version. 

Name:	LW2018_DynamicPartsInModifierStack.jpg 
Views:	26 
Size:	975.7 KB 
ID:	142882

    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:

    Click image for larger version. 

Name:	LW2018_NoStaticBodyInModifierStack.jpg 
Views:	28 
Size:	995.4 KB 
ID:	142881

    mTp

  9. #9
    Electron wrangler jwiede's Avatar
    Join Date
    Aug 2007
    Location
    San Jose, CA
    Posts
    7,057
    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!
    Last edited by jwiede; 09-24-2018 at 04:48 PM.
    John W.
    LW2015.3UB/2019.1.5 on MacPro(12C/24T/10.13.6),64GB RAM, NV 980ti

  10. #10
    Registered User
    Join Date
    Jan 2005
    Location
    Colorado Springs
    Posts
    1,864
    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.

    mTp

  11. #11
    Electron wrangler jwiede's Avatar
    Join Date
    Aug 2007
    Location
    San Jose, CA
    Posts
    7,057
    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).

    _OR_

    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.
    Last edited by jwiede; 09-25-2018 at 03:55 PM.
    John W.
    LW2015.3UB/2019.1.5 on MacPro(12C/24T/10.13.6),64GB RAM, NV 980ti

  12. #12
    Registered User
    Join Date
    Jan 2005
    Location
    Colorado Springs
    Posts
    1,864
    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":

    Click image for larger version. 

Name:	ClassicFX_CollisionMeshType.jpg 
Views:	20 
Size:	701.4 KB 
ID:	142900

    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.

    mTp

  13. #13
    Electron wrangler jwiede's Avatar
    Join Date
    Aug 2007
    Location
    San Jose, CA
    Posts
    7,057
    Quote Originally Posted by MonroePoteet View Post
    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.
    Last edited by jwiede; 09-25-2018 at 05:46 PM.
    John W.
    LW2015.3UB/2019.1.5 on MacPro(12C/24T/10.13.6),64GB RAM, NV 980ti

  14. #14
    Electron wrangler jwiede's Avatar
    Join Date
    Aug 2007
    Location
    San Jose, CA
    Posts
    7,057
    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.
    John W.
    LW2015.3UB/2019.1.5 on MacPro(12C/24T/10.13.6),64GB RAM, NV 980ti

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •