Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
feat!: New
AlternatePattern
argument forSequenceEffect
#3322base: main
Are you sure you want to change the base?
feat!: New
AlternatePattern
argument forSequenceEffect
#3322Changes from 2 commits
80166b1
dd1fc7b
d107787
faa32b9
d05e3ee
ed63c41
ece8953
6dd88a1
2ea5e9f
File filter
Filter by extension
Conversations
Jump to
There are no files selected for viewing
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hmm, is this really correct?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
After thinking about it some more yesterday I think the issue wasn't the reflected vector itself, but rather that the direction vector was incorrect when the camera has a viewport-aware bounds behavior. This causes it to never reach its destination and so the reflective vector is incorrect. That's why taking the absolute value was ok after I added the step to recalculate the vector.
The camera won't be the only component that may never complete its effect with regards to
MoveToEffect
so this matter should be resolved in the PR imo.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
But this will potentially overshoot the destination right? And also it won't be matching the time anymore?
If you are at 0.99 progress and the delta progress is -0.02 when the effect is going forward it should have moved 0.03 "steps", since it'll start going back again, but with this it will simply move to 1.01.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm not sure I'm understanding your question precisely, but it seems that you've noticed the possibility of under-fitting the expected step amounts, time-wise. Yes this does happen with the viewport-aware behavior as described (the camera cannot exceed the bounds, and therefore never arrives to its destination). ATM with the changes I've added, I have not seen any noticeable problems.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Simply put; I don't think it will always be at the expected place at each time step when
abs
is used, that was what I tried to describe in the last comment, the delta doesn't become correct. If it overshoots its destination it should start going back, in the cases where it is alternating.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
progress
will be decrementingdt
units from1.0
during the reverse phase of the alternating pattern, whilepreviousProgress
retains theprogress+dt
value from before. ThereforedProgress = progress - previousProgress
would be negative, which we don't want to use. It's better to recalculate the starting position and use positive scalars instead.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
But it'll surely overshoot the end value then?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hi. No it never does for this effect or any as far as I can tell. The same math could have overshot in the reverse direction when
dProgress
was negative.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
In the case that
dProgress
becomes negative it is supposed to go backwards. Say that the previous progress is 0.9 and it it supposed to move backwards to 0.8, thendProgress
should be-0.1
, not0.1
.Try running only the the
MoveToEffect
withalternate: true
.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hi. A negative progress value for this effect specifically is not only unintuitive but also does not solve the
MoveToEffect
starting vector issue.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If
infinite
(or N runs) is used together withalternate
, shouldn't the first also be excluded on runs that are after the first and not the last?There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It already behaved this way. Only the last one was ever being repeated.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I've corrected the default pattern behavior. The alternating pattern now plays both the first and last
Effect
elements in the list, instead of just the last element as it did before this PR. This default behavior isAlternatePattern.repeatLast
. The term "last" used here is relative to the playback direction.To avoid playing first and last
Effect
s twice-in-a-row when the sequence reverses,AlternatePattern.doNotRepeatLast
is appropriate.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can you explain this a bit? In what cases is the
_index
negative? This doesn't seem like it would follow howprogress
works for the rest of the effects.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The way the
SequenceEffect
has been written for some time now is that it uses a negative_index
to determine if the pattern is in its reverse phase. To be clear, I did not write it this way. This code was like this when I started this PR,