Motion Paths off by one #70381

New Issue

Wayne Dixon · 2019-09-30T07:48:13+02:00

Wayne Dixon commented

2019-09-30 07:48:13 +02:00

System Information
Operating system: Darwin-17.2.0-x86_64-i386-64bit 64 Bits
Graphics card: NVIDIA GeForce GTX 1050 Ti OpenGL Engine NVIDIA Corporation 4.1 NVIDIA-10.27.6 378.10.10.10.20.109

Blender Version
Broken: version: 2.81 (sub 12), branch: master, commit date: 2019-09-29 23:17, hash: 64c222ff58
Worked: (optional)

Short description of error
It seems that the end frame will calculate up to but exclude the end frame, which is inconsistent with the rest of Blender.
(ie - if you want to include frame 40 in the motion paths, you must choose to end the motion paths on frame 41. But if you want to end your animation and render it to frame 40, you set the end frame to be frame 40)
This has been present in 2.79 as well, it is unneccessary though afaics (but I need to double-check the following comment still)

current frame must be within the range the cache works for, is inclusive of the first frame, but not the last otherwise we get buffer overruns

Also in 2.8 (that was not present in 2.79) in that the indication around the current frame (green fading lines) are "off-by-one" [drawn at the previous frame]

Exact steps for others to reproduce the error
motion_paths.blend

When you click update motion paths, it seems that it only updates if it is already in the buffer.
So if you extend the end frame and click update, it won't update anything that wasn't already calculated.
The only way to extend the wanted range is to remove and then recalculate which seems like unwanted behaviour.

this one is not considered a bug

blender_bug_MOTION_PATHS.mp4

**System Information** Operating system: Darwin-17.2.0-x86_64-i386-64bit 64 Bits Graphics card: NVIDIA GeForce GTX 1050 Ti OpenGL Engine NVIDIA Corporation 4.1 NVIDIA-10.27.6 378.10.10.10.20.109 **Blender Version** Broken: version: 2.81 (sub 12), branch: master, commit date: 2019-09-29 23:17, hash: `64c222ff58` Worked: (optional) **Short description of error** It seems that the end frame will calculate up to but exclude the end frame, which is inconsistent with the rest of Blender. (ie - if you want to include frame 40 in the motion paths, you must choose to end the motion paths on frame 41. But if you want to end your animation and render it to frame 40, you set the end frame to be frame 40) This has been present in 2.79 as well, it is unneccessary though afaics (but I need to double-check the following comment still) > current frame must be within the range the cache works for, is inclusive of the first frame, but not the last otherwise we get buffer overruns Also in 2.8 (that was not present in 2.79) in that the indication around the current frame (green fading lines) are "off-by-one" [drawn at the previous frame] **Exact steps for others to reproduce the error** [motion_paths.blend](https://archive.blender.org/developer/F7781203/motion_paths.blend) > When you click update motion paths, it seems that it only updates if it is already in the buffer. > So if you extend the end frame and click update, it won't update anything that wasn't already calculated. > The only way to extend the wanted range is to remove and then recalculate which seems like unwanted behaviour. this one is not considered a bug [blender_bug_MOTION_PATHS.mp4](https://archive.blender.org/developer/F7781200/blender_bug_MOTION_PATHS.mp4)

Wayne Dixon commented

2019-09-30 07:48:13 +02:00

Added subscriber: @WayneDixon

Philipp Oeser commented

2019-09-30 15:04:32 +02:00

Added subscribers: @LucianoMunoz, @Sergey, @dr.sybren, @lichtwerk

Philipp Oeser commented

2019-09-30 15:04:32 +02:00

I think the issue about the changed range not reflected in the update mechanism is not really a bug, each motionpath that is updated acts upon the range it has been created from.
This could be changed I guess, but would not be considered a bug in my opinion.

The "off-by-one" I can confirm (in 2 forms):

first one (the one you describe) has been present in 2.79 as well, it is unneccessary though afaics (but I need to double-check the following comment still)

/* current frame must be within the range the cache works for, is inclusive of the first frame, but not the last otherwise we get buffer overruns */

the second crept into 2.8 (and was not present in 2.79) in that the indication around the current frame (green fading lines) are "off-by-one" [drawn at the previous frame]

Will look into both "off-by-one" issues, for the issue about "changed range not reflected in the update mechanism", I would like to hear an opinion of @dr.sybren, @LucianoMunoz, @Sergey (but like I said, I would not consider this a bug...)
Will confirm (temporarily) for the "off-by-one" issues...

I think the issue about the changed range not reflected in the update mechanism is not really a bug, each motionpath that is updated acts upon the range it has been created from. This could be changed I guess, but would not be considered a bug in my opinion. The "off-by-one" I can confirm (in 2 forms): - first one (the one you describe) has been present in 2.79 as well, it is unneccessary though afaics (but I need to double-check the following comment still) > /* current frame must be within the range the cache works for, is inclusive of the first frame, but not the last otherwise we get buffer overruns */ - the second crept into 2.8 (and was not present in 2.79) in that the indication around the current frame (green fading lines) are "off-by-one" [drawn at the previous frame] Will look into both "off-by-one" issues, for the issue about "changed range not reflected in the update mechanism", I would like to hear an opinion of @dr.sybren, @LucianoMunoz, @Sergey (but like I said, I would not consider this a bug...) Will confirm (temporarily) for the "off-by-one" issues...

Philipp Oeser changed title from ~~Motion Paths don't update correctly.~~ to Motion Paths off by one (also updating is not taking changed range into account)

2019-09-30 15:05:36 +02:00

Philipp Oeser self-assigned this 2019-09-30 15:25:55 +02:00

Philipp Oeser was unassigned by Dalai Felinto

2019-12-23 13:48:46 +01:00

Luciano Muñoz Sessarego commented

2020-01-02 14:58:08 +01:00

I believe i had seen this firs hand a couple of days ago, will test again.

Philipp Oeser commented

2020-02-27 11:18:18 +01:00

So after talking to @dr.sybren, looks like the "update mechanism" is not considered a bug, will update report description accordingly

Philipp Oeser changed title from ~~Motion Paths off by one (also updating is not taking changed range into account)~~ to Motion Paths off by one

2020-02-27 11:27:00 +01:00

Sybren A. Stüvel commented

2020-02-27 14:34:06 +01:00

In #70381#881290, @lichtwerk wrote:
So after talking to @dr.sybren, looks like the "update mechanism" is not considered a bug, will update report description accordingly

That, and a report should not be about two things at once anyway.

> In #70381#881290, @lichtwerk wrote: > So after talking to @dr.sybren, looks like the "update mechanism" is not considered a bug, will update report description accordingly That, and a report should not be about two things at once anyway.

Sybren A. Stüvel commented

2020-02-27 14:38:46 +01:00

Changed status from 'Confirmed' to: 'Resolved'

Sybren A. Stüvel closed this issue

2020-02-27 14:38:46 +01:00

Sybren A. Stüvel self-assigned this 2020-02-27 14:38:46 +01:00

Sybren A. Stüvel commented

2020-02-27 14:38:47 +01:00

In #70381#786375, @lichtwerk wrote:

the second crept into 2.8 (and was not present in 2.79) in that the indication around the current frame (green fading lines) are "off-by-one" [drawn at the previous frame]

This seems to have been fixed in the mean time already:

@WayneDixon It looks like part of your report was working as intended (the path update mechanics), and part has been fixed already. I'll mark this report as 'Resolved' because of the latter. If we have totally misunderstood your issues, please feel free to add a comment or write a new bug report to clarify this.

> In #70381#786375, @lichtwerk wrote: > - the second crept into 2.8 (and was not present in 2.79) in that the indication around the current frame (green fading lines) are "off-by-one" [drawn at the previous frame] This seems to have been fixed in the mean time already: ![image.png](https://archive.blender.org/developer/F8375632/image.png) @WayneDixon It looks like part of your report was working as intended (the path update mechanics), and part has been fixed already. I'll mark this report as 'Resolved' because of the latter. If we have totally misunderstood your issues, please feel free to add a comment or write a new bug report to clarify this.

Philipp Oeser commented

2020-02-27 15:10:52 +01:00

@dr.sybren: what about this then?:

if you want to include frame 40 in the motion paths, you must choose to end the motion paths on frame 41

Also not sure about the drawing (this might be nitpicky, but...shouldnt the green part be around the current frame?):

2.8 (current frame is black and next frame seems to be fully green)

2.79 (both current frame and next frame seem to be fully green?)

These (endframe not included & drawing) could be split into two different reports, but I actually assume this is rooted in the same issue...

@dr.sybren: what about this then?: > if you want to include frame 40 in the motion paths, you must choose to end the motion paths on frame 41 Also not sure about the drawing (this might be nitpicky, but...shouldnt the green part be around the current frame?): 2.8 (current frame is black and next frame seems to be fully green) ![image.png](https://archive.blender.org/developer/F8375666/image.png) 2.79 (both current frame and next frame seem to be fully green?) ![image.png](https://archive.blender.org/developer/F8375669/image.png) These (endframe not included & drawing) could be split into two different reports, but I actually assume this is rooted in the same issue...

Sybren A. Stüvel commented

2020-02-27 15:59:58 +01:00

Changed status from 'Resolved' to: 'Confirmed'

Sybren A. Stüvel reopened this issue

2020-02-27 15:59:58 +01:00

Sybren A. Stüvel commented

2020-02-27 17:27:52 +01:00

These (endframe not included & drawing) could be split into two different reports, but I actually assume this is rooted in the same issue...

After digging into it, it turns out they aren't rooted in the same issue. The endframe not being included is as it is designed now, so not a bug. The drawing being off by one is a bug, though.

> These (endframe not included & drawing) could be split into two different reports, but I actually assume this is rooted in the same issue... After digging into it, it turns out they aren't rooted in the same issue. The endframe not being included is as it is designed now, so not a bug. The drawing being off by one is a bug, though.

blender-admin commented

2020-02-27 17:41:28 +01:00

This issue was referenced by c20caec7f0

This issue was referenced by c20caec7f0b39b7d15bd600880ea9534c31f6732

Sybren A. Stüvel commented

2020-02-27 17:44:21 +01:00

Fixed:

Fixed: ![image.png](https://archive.blender.org/developer/F8375945/image.png)

Sybren A. Stüvel commented

2020-02-27 17:49:11 +01:00

Changed status from 'Confirmed' to: 'Resolved'

Sybren A. Stüvel closed this issue

2020-02-27 17:49:11 +01:00

Philipp Oeser commented

2020-02-27 18:37:36 +01:00

After digging into it, it turns out they aren't rooted in the same issue

thx digging and fixing!

> After digging into it, it turns out they aren't rooted in the same issue thx digging and fixing!

Sign in to join this conversation.

5 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: blender/blender#70381

Download

What's New

Blender Studio

Manual

Developers Blog

Documentation

Benchmark

Blender Conference

Development Fund

One-time Donations

Motion Paths off by one #70381