Update Engine prototype
parent
aa492d3a11
commit
e854cc7d16
@ -27,7 +27,7 @@ Some of these are obvious, but we may as well write them down. Note we may want
|
||||
|
||||
* Keep the network of entities (or variables?) and constraints. Only ever work on one connected component of this at a time.
|
||||
* Conversely, track rigid subnetworks, and replace them with fewer working variables. [What do we do about/how do we display over-constrained subnetworks? Do we display the configuration "nearest" to satisfying all the constraints in some sense but show it some bright alarm state the violated constraints, perhaps graded by "how badly" the constraint fails?]
|
||||
* Track the current displayed witnesses of satisfying the constraints (after all, that's what we are showing). In lightly constrained networks, temporarily add constraints fixing all the entities except for the ones that are being moved, backing off on some temporary constraints by distance in the constraint network until we get a low-dimensional component that we are on, and move just along that component.
|
||||
* Track the current displayed witnesses of satisfying the constraints (after all, that's what we are showing). In lightly constrained networks, temporarily add constraints fixing all the entities except for the ones that are being moved, backing off on some temporary constraints by distance in the constraint network until we get a low-dimensional component that we are on, and move just along that component. We may be able to take advantage of the fact that fixing some of the entities will linearize the remaining constraints, so we can very rapidly check if there are any overall solutions with those points fixed, and even tell something about conditions on the values of those entities that do or don't allow the linearized system to be solved.
|
||||
|
||||
## Overall solver approaches
|
||||
|
||||
|
Loading…
Reference in New Issue
Block a user