WIP: Geometry Nodes: playing with PBD #129718

Closed
Jacques Lucke wants to merge 6 commits from JacquesLucke/blender:pdb-solver-experiment into main

When changing the target branch, be careful to rebase the branch in your fork to match. See documentation.
Member

This is an experiment to get to know position based dynamics (PBD) better.

This adds a PBD Solver node which implements some basic constraints for softbody, hair and grain simulation.

Information about PBD:

This is an experiment to get to know position based dynamics (PBD) better. This adds a PBD Solver node which implements some basic constraints for softbody, hair and grain simulation. Information about PBD: * https://animation.rwth-aachen.de/media/papers/2015-EG-Tutorial.pdf * https://www.youtube.com/watch?v=qISgdDhdCro&list=PLfd9K5jHLvZC1dE_O68lc3Jf0kUvidYFr <video src="https://projects.blender.org/attachments/2ef22c22-1938-4b53-91e6-f2ac53b13bbc" controls />
Jacques Lucke added 5 commits 2024-11-02 14:29:36 +01:00
Jacques Lucke added 1 commit 2024-11-02 14:38:15 +01:00
Hans Goudey changed title from WIP: Geometry Nodes: playing with PDB to WIP: Geometry Nodes: playing with PBD 2024-11-02 14:50:36 +01:00
Iliya Katushenock added this to the Nodes & Physics project 2024-11-02 16:52:22 +01:00
First-time contributor

highly recommend throwing the 'x' in there lol (for xpbd)
all you need is to add a tiny term in the constraint that is dependent on dt^2

3 main insights ive learned when playing with this:


  1. surprisingly you get better/faster convergence spending all your resources on substeps (while maintaining a single constraint solve): https://matthias-research.github.io/pages/publications/smallsteps.pdf
  2. using xpbd kills any stiffness-dependence based on substeps/constraint steps - this is good because you want your simulation to look very similar regardless of the number of steps: https://matthias-research.github.io/pages/publications/XPBD.pdf
  3. verlet integration is super cheap and stable

literally read everything by matthias - he's the G

highly recommend throwing the 'x' in there lol (for xpbd) all you need is to add a tiny term in the constraint that is dependent on dt^2 3 main insights ive learned when playing with this: --- 1) surprisingly you get better/faster convergence spending all your resources on substeps (while maintaining a single constraint solve): https://matthias-research.github.io/pages/publications/smallsteps.pdf 2) using xpbd kills any stiffness-dependence based on substeps/constraint steps - this is good because you want your simulation to look very similar regardless of the number of steps: https://matthias-research.github.io/pages/publications/XPBD.pdf 3) verlet integration is super cheap and stable literally read everything by matthias - he's the G
Author
Member

Thanks. I'm aware of the "x" part (I'm kind of using the term PBD for everything related to that currently). Still have to figure out how everything fits together though :)

Thanks. I'm aware of the "x" part (I'm kind of using the term PBD for everything related to that currently). Still have to figure out how everything fits together though :)
First-time contributor

Love to see XPBD getting a tighter integration, thanks for working on this!

One thing I appreciate about implementing xpbd within node groups rather than having a dedicated solver node is the control one maintains over the simulation.

In my experiments with xpbd in Blender, the main missing piece is an efficient way of obtaining contact points between bodies.

In my opinion a contact points node would close the gap for more efficient collision response for simple bodies such as spheres, and could implement GJK and EPA to get contact points between convex bodies.

It's already possible to create xpbd rigid body simulations in geo nodes, but it requires using a repeat zone to iterate through possible colliders and detect contact points.

A collision points node that outputs a new "collision points" geometry could be used with the attribute statistic node to make that process efficient, and would be a great tool to have in addition to dedicated solvers!

edit: I may have spoken too soon, because you would need a group_id input to the attribute statistic node for this to work. It should be possible currently with the accumulate field node though.

Love to see XPBD getting a tighter integration, thanks for working on this! One thing I appreciate about implementing xpbd within node groups rather than having a dedicated solver node is the control one maintains over the simulation. In my experiments with xpbd in Blender, the main missing piece is an efficient way of obtaining contact points between bodies. In my opinion a contact points node would close the gap for more efficient collision response for simple bodies such as spheres, and could implement GJK and EPA to get contact points between convex bodies. It's already possible to create xpbd rigid body simulations in geo nodes, but it requires using a repeat zone to iterate through possible colliders and detect contact points. A collision points node that outputs a new "collision points" geometry could be used with the attribute statistic node to make that process efficient, and would be a great tool to have in addition to dedicated solvers! edit: I may have spoken too soon, because you would need a group_id input to the attribute statistic node for this to work. It should be possible currently with the accumulate field node though.
First-time contributor

Sorry if this is not the place for that type of question:
Is this an experimental branch of Blender?
Because this is what I see in 4.3 and 4.4 when opening the .blend file from the header post of this thread:
image

Sorry if this is not the place for that type of question: Is this an experimental branch of Blender? Because this is what I see in 4.3 and 4.4 when opening the .blend file from the header post of this thread: <img width="450" alt="image" src="attachments/5c16e49f-b1b1-4214-82bd-ebc5ecdbe0c0">
Author
Member

This is a personal experiment of mine, it's not really something that can be tested well by others unfortunately, because I hard-coded all kinds of assumptions in the code.

Will close this to avoid confusion.

This is a personal experiment of mine, it's not really something that can be tested well by others unfortunately, because I hard-coded all kinds of assumptions in the code. Will close this to avoid confusion.
Jacques Lucke closed this pull request 2024-11-21 12:21:10 +01:00

Pull request closed

Sign in to join this conversation.
No reviewers
No Label
Interest
Alembic
Interest
Animation & Rigging
Interest
Asset System
Interest
Audio
Interest
Automated Testing
Interest
Blender Asset Bundle
Interest
BlendFile
Interest
Code Documentation
Interest
Collada
Interest
Compatibility
Interest
Compositing
Interest
Core
Interest
Cycles
Interest
Dependency Graph
Interest
Development Management
Interest
EEVEE
Interest
Freestyle
Interest
Geometry Nodes
Interest
Grease Pencil
Interest
ID Management
Interest
Images & Movies
Interest
Import Export
Interest
Line Art
Interest
Masking
Interest
Metal
Interest
Modeling
Interest
Modifiers
Interest
Motion Tracking
Interest
Nodes & Physics
Interest
OpenGL
Interest
Overlay
Interest
Overrides
Interest
Performance
Interest
Physics
Interest
Pipeline, Assets & IO
Interest
Platforms, Builds & Tests
Interest
Python API
Interest
Render & Cycles
Interest
Render Pipeline
Interest
Sculpt, Paint & Texture
Interest
Text Editor
Interest
Translations
Interest
Triaging
Interest
Undo
Interest
USD
Interest
User Interface
Interest
UV Editing
Interest
VFX & Video
Interest
Video Sequencer
Interest
Viewport & EEVEE
Interest
Virtual Reality
Interest
Vulkan
Interest
Wayland
Interest
Workbench
Interest: X11
Legacy
Asset Browser Project
Legacy
Blender 2.8 Project
Legacy
Milestone 1: Basic, Local Asset Browser
Legacy
OpenGL Error
Meta
Good First Issue
Meta
Papercut
Meta
Retrospective
Meta
Security
Module
Animation & Rigging
Module
Core
Module
Development Management
Module
Grease Pencil
Module
Modeling
Module
Nodes & Physics
Module
Pipeline, Assets & IO
Module
Platforms, Builds & Tests
Module
Python API
Module
Render & Cycles
Module
Sculpt, Paint & Texture
Module
Triaging
Module
User Interface
Module
VFX & Video
Module
Viewport & EEVEE
Platform
FreeBSD
Platform
Linux
Platform
macOS
Platform
Windows
Severity
High
Severity
Low
Severity
Normal
Severity
Unbreak Now!
Status
Archived
Status
Confirmed
Status
Duplicate
Status
Needs Info from Developers
Status
Needs Information from User
Status
Needs Triage
Status
Resolved
Type
Bug
Type
Design
Type
Known Issue
Type
Patch
Type
Report
Type
To Do
No Milestone
No Assignees
4 Participants
Notifications
Due Date
The due date is invalid or out of range. Please use the format 'yyyy-mm-dd'.

No due date set.

Dependencies

No dependencies set.

Reference: blender/blender#129718
No description provided.