Rewind through the descent history #114
No reviewers
Labels
No labels
bug
design
duplicate
enhancement
maintenance
prospective
question
regression
stub
todo
ui
wontfix
No milestone
No project
No assignees
2 participants
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference: StudioInfinity/dyna3#114
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "Vectornaut/dyna3:rewind-history"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
On the incoming branch, you can rewind through the descent history of the last realization using the Step control that's been added to the diagnostics panel.
The starting value of the Step control depends on the realization status. After a successful realization, we show the realized state (the last step). After an unsuccessful realization, we show the initial guess (step zero).
Shortcomings
Awkward factorization of realization results
On the incoming branch, the application gets all the configuration information it needs from the
history
field of theRealization
structure thatrealize_gram
returns. Theconfig
field inRealization::result
is never read. In fact, theconfig
field is never read from anyConfigNeighborhood
structure.The
config
field is still used in tests and examples, however, so we compile it conditionally to avoid a dead code warning.If the history rewind feature ends up being a long-term part of the application, we should refactor the
Realization
structure to avoid this awkward orgnization. Since this feature is engine-dependent, however, I don't think we should plan for its long-term presence yet.Nudging from previous steps
On the main branch, nudging requires a valid tangent space. Right now, we only have a valid tangent space for the last step of a successful realization and (usually) the initial step of a failed realization. On the incoming branch, this raises the question of what to do when we try to nudge from other steps. I've chosen an expedient answer: simply disable nudging from other steps.
We can revisit this shortcoming if we find that it might be useful to nudge from other steps, or if we redesign the tangent space system (which I think we should consider at some point).
This all looks reasonable. Two things:
If either of these is a reasonably quick and simple fix, please go ahead. Otherwise just file (prospective) issues for them (and in any case file a prospective issue for the "awkward factorization" point above) and let me know, and I will merge this PR. Thanks!
The code now allows nudging from the initial step of a failed realization. I've updated the pull request description accordingly.
The description no longer mentions issue #100, because I noticed that it may already have been fixed by pull request #105. Since #100 no longer has a working reproduction procedure, we can't tell how this pull request might affect it.
I've now filed issue #115, which covers this.
This is now filed as issue #116, so I think the pull request should be ready to merge!
View command line instructions
Checkout
From your project repository, check out a new branch and test the changes.