Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
Help  Managing dynamic constraints
#1
Hi, I have several questions about creating constraints during runtime.
As far as I know constraints are stored in blueprints or directly in actor (pin).
Then those constraints are pushed to solver and copy is created and merged in solver.

There is mechanism to make constraints dirty, this causes constraints tobe rebuilt, by taking all actors constraints, however what about stitch constraints?
I can't see them stored in actors or blueprints, so is there only runtime representation? What if I marked stitch constraints as dirty, would that mean that all stitch constraints are cleared and cannot be rebuilt, because there is no blueprint/actor (original) copy?

Also what if I wanted to create some pin constraints during runtime via custom script and modify offsets every step? I want to avoid making constraints dirty every frame, but at the same time it does make sense to modify actor copy in case it's rebuilt, so should I modify both? How can I diffrentiate my own batch from all other solver batches to avoid dirtying?
Reply
#2
(23-12-2025, 10:40 AM)Qriva0 Wrote: Hi, I have several questions about creating constraints during runtime.
As far as I know constraints are stored in blueprints or directly in actor (pin).
Then those constraints are pushed to solver and copy is created and merged in solver.

There is mechanism to make constraints dirty, this causes constraints tobe rebuilt, by taking all actors constraints, however what about stitch constraints?
I can't see them stored in actors or blueprints, so is there only runtime representation?

Correct, stitch constraints only exist at runtime. They're not part of an actor (since they may affect different actors) and they're not part of blueprints since they're created at runtime.

(23-12-2025, 10:40 AM)Qriva0 Wrote: What if I marked stitch constraints as dirty, would that mean that all stitch constraints are cleared and cannot be rebuilt, because there is no blueprint/actor (original) copy?

In case of stitches there's no "original" (actor/blueprint) copy. We deal with the solver batch directly.

(23-12-2025, 10:40 AM)Qriva0 Wrote: Also what if I wanted to create some pin constraints during runtime via custom script and modify offsets every step? I want to avoid making constraints dirty every frame, but at the same time it does make sense to modify actor copy in case it's rebuilt, so should I modify both?

Yes, you should modify both copies. This is exactly what pinhole constraints do (see ObiPinhole.cs)

(23-12-2025, 10:40 AM)Qriva0 Wrote: How can I diffrentiate my own batch from all other solver batches to avoid dirtying?

You use the actor.solverBatchOffsets dictionary: for each constraint type, it contains a list of start offsets in the solver. Again, ObiPinhole.cs is a good reference for this. You'll notice that every time we modify constraint data (see its UpdateParameters() method), we modify both the actor copy and the solver copy, using the solverBatchOffsets array to know where the solver copy "lives" and differentiate it from all other batches in the solver.


----
As a side note, in Obi 8 we've simplified this system significantly. Batching and clustering are done incrementally at runtime every time a constraint is added/removed (with O(1) cost), so no constraint "dirtying" needed, there isn't any need to expose batches directly to the user, and at runtime you often only deal with one copy of the constraints. It's also more performant since the cost of adding or removing actors no longer depends on how many actors are already in the solver, only on the amount of constraints in the actor.

Basically just int index = AddConstraint(), and then you can use the index to access constraint data in the solver arrays. When dealing with blueprints, there's an array that maps index in the blueprint to index in the solver.
Reply