Rendered frame shifted while using sequencer #30663

Closed
opened 2012-03-24 17:34:06 +01:00 by Jérôme Scaillet · 19 comments

%%%Hello guys...

Frame rendering is shifted while using the scene in the sequencer.

In my file, i render an image in the viewport : current frame 60
If the start sequence is set to 60 for exemple, the rendered frame will be 120

In fact, the amount of the start sequence and the current frames are added.

If i delete the scene in the sequencer, render is normal.

Blender: 2.62.2 r45110

CPU: AMD Phenom II X6 1100T
RAM: 8Gb
GFX: nVidia GTX 580, 1536MB
OS: Ubuntu 11.04 x86_64
Kernel : 2.6.38-13-generic
Drivers: Forceware 290.10%%%

%%%Hello guys... Frame rendering is shifted while using the scene in the sequencer. In my file, i render an image in the viewport : current frame 60 If the start sequence is set to 60 for exemple, the rendered frame will be 120 In fact, the amount of the start sequence and the current frames are added. If i delete the scene in the sequencer, render is normal. Blender: 2.62.2 r45110 CPU: AMD Phenom II X6 1100T RAM: 8Gb GFX: nVidia GTX 580, 1536MB OS: Ubuntu 11.04 x86_64 Kernel : 2.6.38-13-generic Drivers: Forceware 290.10%%%

Changed status to: 'Open'

Changed status to: 'Open'

#33298 was marked as duplicate of this issue

#33298 was marked as duplicate of this issue

#38132 was marked as duplicate of this issue

#38132 was marked as duplicate of this issue

#42235 was marked as duplicate of this issue

#42235 was marked as duplicate of this issue

#44291 was marked as duplicate of this issue

#44291 was marked as duplicate of this issue

#50139 was marked as duplicate of this issue

#50139 was marked as duplicate of this issue

#52583 was marked as duplicate of this issue

#52583 was marked as duplicate of this issue

%%%Behavior was changed in svn rev44068 and now scene strips are using start frame from scene's settings. In your case you're putting the same scene into a sequencer and changes start frame of this scene. This introduces that offset you're talking about.
In fact both of current and old behavior makes sense, but old behavior implied storing start frame on a time when you're adding new scene strip and you cannot change it anymore which si weird. New behavior is much more useful for animators' workflow.
Wouldn't actually consider this is a bug.%%%

%%%Behavior was changed in svn rev44068 and now scene strips are using start frame from scene's settings. In your case you're putting the same scene into a sequencer and changes start frame of this scene. This introduces that offset you're talking about. In fact both of current and old behavior makes sense, but old behavior implied storing start frame on a time when you're adding new scene strip and you cannot change it anymore which si weird. New behavior is much more useful for animators' workflow. Wouldn't actually consider this is a bug.%%%

%%%Ok, thank you Sergey to investigate. I might be wrong but i'm afraid that the things are not so... simple for me.

For you information... In fact, i'm using the time remapping and the superposition of rendered step frames to obtain a motion blur effect with cycles.
I'm using the frames steps offset and the sequencer to combine 16 channels of the same scene in the sequencer. Each scene or channel has an offset of -1 frame.
For exemple channel zero start à 0, channel 1 start at -1, channel 2 at -2, etc.... until 15.

(originally from Max Hammond works : http://vimeo.com/36650120)

So... Everything worked fine until the revision 45110 i presume.. maybe before. I noticed a commit in the sequencer at r45068...
Anyway, before this revision i was able to use the same scene in the sequencer without having an offset trouble. And i was able to start my animation at any desired point too. And its far after the revision 44068. (I update blender every two days or so.)

For the time being, i'm unable to start my animation as before this build at a random start point without this start point being doubled internally.
Start point 10480 makes the rendered frame equal to 20960 but saved as number 10480. I'm ok to consider that is not a bug but.. there's something wrong for my own opinion.

If i deactivate the sequencer checkbox in the Post-processing section of the render panel. I can start my animation at the frame desired but the other frames (frame steps) are not rendered.

Another thing i've noticed while writing those lines. In my sequencer, and since recently, two of my channels (13 & 14) are superposed on the same channel. (13) You are OK with me that if you grab manually a scene and want to put it over another scene, this grabbed scene is automatically placed before (maybe occasionally after) the one you wanted to "mix or override". That never happen that two scenes are on the same time on the same channel... Am i wrong ? Anyway, i really carefully placed my scenes on each channel when i set up my animation. And now two of them have collapsed into one.

And.. a new 16th scene on the 15th channel has been created. .. I've never added this channel because i only needed 16. So with the zero channel + 16 other channel, i have 17 channels of the same scene for a frame step of 16. something is wrong here...

An alternative i've found to continue my actual work is to render the new frames in an other folder and start at half the point i want to restart my animation. This way, the rendered frames don't override the other i've rendered before..

For your information too. I have 850 images in my animation and each combined images takes approximately 15 minutes to render. Because I can't let my computer working day and night at the moment, i have to restart each day at the point i stopped the day before.

So.. I hope that everything make sense and you would consider reopen this bug report. Beause there is a bug for my own perpective.

Thank you.
Jérôme.%%%

%%%Ok, thank you Sergey to investigate. I might be wrong but i'm afraid that the things are not so... simple for me. For you information... In fact, i'm using the time remapping and the superposition of rendered step frames to obtain a motion blur effect with cycles. I'm using the frames steps offset and the sequencer to combine 16 channels of the same scene in the sequencer. Each scene or channel has an offset of -1 frame. For exemple channel zero start à 0, channel 1 start at -1, channel 2 at -2, etc.... until 15. (originally from Max Hammond works : http://vimeo.com/36650120) So... Everything worked fine until the revision 45110 i presume.. maybe before. I noticed a commit in the sequencer at r45068... Anyway, before this revision i was able to use the same scene in the sequencer without having an offset trouble. And i was able to start my animation at any desired point too. And its far after the revision 44068. (I update blender every two days or so.) For the time being, i'm unable to start my animation as before this build at a random start point without this start point being doubled internally. Start point 10480 makes the rendered frame equal to 20960 but saved as number 10480. I'm ok to consider that is not a bug but.. there's something wrong for my own opinion. If i deactivate the sequencer checkbox in the Post-processing section of the render panel. I can start my animation at the frame desired but the other frames (frame steps) are not rendered. Another thing i've noticed while writing those lines. In my sequencer, and since recently, two of my channels (13 & 14) are superposed on the same channel. (13) You are OK with me that if you grab manually a scene and want to put it over another scene, this grabbed scene is automatically placed before (maybe occasionally after) the one you wanted to "mix or override". That never happen that two scenes are on the same time on the same channel... Am i wrong ? Anyway, i really carefully placed my scenes on each channel when i set up my animation. And now two of them have collapsed into one. And.. a new 16th scene on the 15th channel has been created. .. I've never added this channel because i only needed 16. So with the zero channel + 16 other channel, i have 17 channels of the same scene for a frame step of 16. something is wrong here... An alternative i've found to continue my actual work is to render the new frames in an other folder and start at half the point i want to restart my animation. This way, the rendered frames don't override the other i've rendered before.. For your information too. I have 850 images in my animation and each combined images takes approximately 15 minutes to render. Because I can't let my computer working day and night at the moment, i have to restart each day at the point i stopped the day before. So.. I hope that everything make sense and you would consider reopen this bug report. Beause there is a bug for my own perpective. Thank you. Jérôme.%%%

%%%Well, still don't think it's indeed a bug, for me it works in much more predictable way as it was before. Using such a tring to deal with moblur in cycles is more a workaround way and shouldn't actually be solved in such a way.
But discussed with Campbell and probably it'll be useful to have independent setting for start/end frame.
Peter, i hope you can handle this report.%%%

%%%Well, still don't think it's indeed a bug, for me it works in much more predictable way as it was before. Using such a tring to deal with moblur in cycles is more a workaround way and shouldn't actually be solved in such a way. But discussed with Campbell and probably it'll be useful to have independent setting for start/end frame. Peter, i hope you can handle this report.%%%

%%%Hello Peter and Sergey...

Returning back sfra property in the sequence structure didn't changed anything for me. So i don't think that the offset come from here.
But, you already knows that i'm not a dev.
I tried today on a windows 32 bit system with a build from graphicall. rev 45201 and my report.blend react as in my own build on linux. (rev45133)
(http://www.graphicall.org/93)

One thing i wanted to know... Do you actually have the same frame offset with my report.blend ?
I begin to wonder if i'm not dealing with a wrong way to make such things...
I mean, it's not an incorrect way to use blender if you put your actual scene in the sequencer... right ?
So... i should be able to start my animation at 30 without having the 60th frame being rendered and saved as the 30th.

If i do something incorrectly, please let me know...

About my moblur workaround. I precise that this way to obtain it is a efficient way because you can have reflection and refraction too.
Anyway... workarounds are commonly used in the community... Result is the goal. ( ^_ - )

Than you
Jérôme.%%%

%%%Hello Peter and Sergey... Returning back sfra property in the sequence structure didn't changed anything for me. So i don't think that the offset come from here. But, you already knows that i'm not a dev. I tried today on a windows 32 bit system with a build from graphicall. rev 45201 and my report.blend react as in my own build on linux. (rev45133) (http://www.graphicall.org/93) One thing i wanted to know... Do you actually have the same frame offset with my report.blend ? I begin to wonder if i'm not dealing with a wrong way to make such things... I mean, it's not an incorrect way to use blender if you put your actual scene in the sequencer... right ? So... i should be able to start my animation at 30 without having the 60th frame being rendered and saved as the 30th. If i do something incorrectly, please let me know... About my moblur workaround. I precise that this way to obtain it is a efficient way because you can have reflection and refraction too. Anyway... workarounds are commonly used in the community... Result is the goal. ( ^_ - ) Than you Jérôme.%%%

%%%Hello All !!

First... I want to apologize if i messed up the buildslave and rebuilded the 45065 as the latest build in buildbot this day.
I was pretty sure to rebuild it for myself ONLY. You should have seen me turning to green behind my screen when i saw my build in the buildbot...
(Saying that, i should not have access to that function... : / )
Sorry for that !!

So... I rebuilded r45065 and the issue is not present in that build. I can start my animation at any desired point and render an image without encountering an offset issue.
That makes me think that the commit 45068 has something to do with that bug report.

For being as clear as possible... The issue is easily reproducible.

  • Create a new scene.
  • Add the current scene in the sequencer.
  • clic the Checkbox sequencer in the port-processing section of the render panel.
  • Start a render animation at any desired point above 1.
  • You should have the rendered frame with an offset of twice the amount of the "start frame" value.
  • Rendered frames will be saved normally but with that offset.

Thank you for your time and sorry again for my "rookie" mistake.
Jérôme.
%%%

%%%Hello All !! First... I want to apologize if i messed up the buildslave and rebuilded the 45065 as the latest build in buildbot this day. I was pretty sure to rebuild it for myself ONLY. You should have seen me turning to green behind my screen when i saw my build in the buildbot... (Saying that, i should not have access to that function... : / ) Sorry for that !! So... I rebuilded r45065 and the issue is not present in that build. I can start my animation at any desired point and render an image without encountering an offset issue. That makes me think that the commit 45068 has something to do with that bug report. For being as clear as possible... The issue is easily reproducible. - Create a new scene. - Add the current scene in the sequencer. - clic the Checkbox sequencer in the port-processing section of the render panel. - Start a render animation at any desired point above 1. - You should have the rendered frame with an offset of twice the amount of the "start frame" value. - Rendered frames will be saved normally but with that offset. Thank you for your time and sorry again for my "rookie" mistake. Jérôme. %%%
Member

%%%Hi Jérôme,

problem is: the behaviour you want to restore, I actually consider a misbehaviour.

To make it more clear, why the old thing was actually a bug:

when you added a SCENE strip to the sequencer, the start frame was pulled from the scene and pushed into the scene strip data, left there unchangeable.

That means: if you wanted to change the start point within the scene afterwards there was no way to propagate that change into the SCENE strip within the sequencer (well, there was, you could always change the scene back and forth to force a reload, but that isn't that nice).

And: adding the same scene into the sequencer isn't such a bright idea either. Most people just use that for testing purposes and I think, displaying a black frame to prevent an eternal loop could be just as well justified for that use case.

So: may I ask, why you don't just add another scene and put that into your timeline?

Cheers
Peter%%%

%%%Hi Jérôme, problem is: the behaviour you want to restore, I actually consider a misbehaviour. To make it more clear, why the old thing was actually a bug: when you added a SCENE strip to the sequencer, the start frame was pulled from the scene and pushed into the scene strip data, left there unchangeable. That means: if you wanted to change the start point within the scene afterwards there was no way to propagate that change into the SCENE strip within the sequencer (well, there was, you could always change the scene back and forth to force a reload, but that isn't that nice). And: adding the same scene into the sequencer isn't such a bright idea either. Most people just use that for testing purposes and I think, displaying a black frame to prevent an eternal loop could be just as well justified for that use case. So: may I ask, why you don't just add another scene and put that into your timeline? Cheers Peter%%%
Member

%%%... maybe something you haven't tried (you can try that with an older release, to see the same "offset problem"):

  • start up blender
  • change the start frame of the scene to 60
  • add your little cube animation
  • go to the sequencer timeline and add your scene strip
  • be surprised, that you will see the same offset, you opened the bug report to begin with.

I hope we can agree, that the start of a SCENE strip shouldn't be dependend on the order of operations, right?

Cheers
Peter%%%

%%%... maybe something you haven't tried (you can try that with an older release, to see the same "offset problem"): * start up blender * change the start frame of the scene to 60 * add your little cube animation * go to the sequencer timeline and add your scene strip * be surprised, that you will see the same offset, you opened the bug report to begin with. I hope we can agree, that the start of a SCENE strip shouldn't be dependend on the order of operations, right? Cheers Peter%%%

%%%Hello Peter,

Well i made my tests with those new informations and as i expected... And since r45068, i don't use the sequencer as it should be used.

If i summarize correctly, the new normal way is :

  • to create a new scene to put the sequence on
    or
  • to create a new scene of linked objects to be used in the sequencer of the current scene

Well.. I always used the sequencer in the now called "old" behavior manner and i always found logical to set my start frame to zero before importing my scene. The reason why i never had a problem with that "old" behavior is that you instantly see where the problem is.

Since two days i was wondering why anyone would consider that there's a bug... And sincerely, i didn't thought one second that this wasn't a bug. I never expected that the simple use of the sequencer could be complicated that way... And you actually have to resolve an offset issue unlogically. Unless you are aware on how to make an efficient set up.

For my humble opinion, this new behavior act as it is bugged if you use the sequencer logically. I'll not be surprised that this behavior could be debated in the future. (Just think to the newbies )

So.. i guess that this "false bug" report can be closed but there's one thing i have to request before... Now that you have changed that behavior, at least.. make the importing of the current scene in the current scene sequencer not possible. Such like the current scene not appearing in the add scene selection menu.

Thank you guys for your time and efforts.
Regards,
Jérôme A. Scaillet.%%%

%%%Hello Peter, Well i made my tests with those new informations and as i expected... And since r45068, i don't use the sequencer as it should be used. If i summarize correctly, the new normal way is : - to create a new scene to put the sequence on or - to create a new scene of linked objects to be used in the sequencer of the current scene Well.. I always used the sequencer in the now called "old" behavior manner and i always found logical to set my start frame to zero before importing my scene. The reason why i never had a problem with that "old" behavior is that you instantly see where the problem is. Since two days i was wondering why anyone would consider that there's a bug... And sincerely, i didn't thought one second that this wasn't a bug. I never expected that the simple use of the sequencer could be complicated that way... And you actually have to resolve an offset issue unlogically. Unless you are aware on how to make an efficient set up. For my humble opinion, this new behavior act as it is bugged if you use the sequencer logically. I'll not be surprised that this behavior could be debated in the future. (Just think to the newbies ) So.. i guess that this "false bug" report can be closed but there's one thing i have to request before... Now that you have changed that behavior, at least.. make the importing of the current scene in the current scene sequencer not possible. Such like the current scene not appearing in the add scene selection menu. Thank you guys for your time and efforts. Regards, Jérôme A. Scaillet.%%%

%%%Oops... "Unlogically" (AH AH) ... I meant "Illogically" of course !%%%

%%%Oops... "Unlogically" (AH AH) ... I meant "Illogically" of course !%%%
Member

%%%closing "false bug"%%%

%%%closing "false bug"%%%
Member

Changed status from 'Open' to: 'Archived'

Changed status from 'Open' to: 'Archived'
Added subscribers: @massimiliano.leoni, @JasonSchleifer, @dfelinto, @MathieuAuvray, @Blendify, @willybid-4, @Psy-Fi, @jhonwallace, @candreacchio, @ideasman42, @mardy, @NikosPriniotakis, @Funkster-3, @mont29, @JulianEisel, @brecht
Sign in to join this conversation.
No Label
Interest
Alembic
Interest
Animation & Rigging
Interest
Asset Browser
Interest
Asset Browser Project Overview
Interest
Audio
Interest
Automated Testing
Interest
Blender Asset Bundle
Interest
BlendFile
Interest
Collada
Interest
Compatibility
Interest
Compositing
Interest
Core
Interest
Cycles
Interest
Dependency Graph
Interest
Development Management
Interest
EEVEE
Interest
EEVEE & Viewport
Interest
Freestyle
Interest
Geometry Nodes
Interest
Grease Pencil
Interest
ID Management
Interest
Images & Movies
Interest
Import Export
Interest
Line Art
Interest
Masking
Interest
Metal
Interest
Modeling
Interest
Modifiers
Interest
Motion Tracking
Interest
Nodes & Physics
Interest
OpenGL
Interest
Overlay
Interest
Overrides
Interest
Performance
Interest
Physics
Interest
Pipeline, Assets & IO
Interest
Platforms, Builds & Tests
Interest
Python API
Interest
Render & Cycles
Interest
Render Pipeline
Interest
Sculpt, Paint & Texture
Interest
Text Editor
Interest
Translations
Interest
Triaging
Interest
Undo
Interest
USD
Interest
User Interface
Interest
UV Editing
Interest
VFX & Video
Interest
Video Sequencer
Interest
Virtual Reality
Interest
Vulkan
Interest
Wayland
Interest
Workbench
Interest: X11
Legacy
Blender 2.8 Project
Legacy
Milestone 1: Basic, Local Asset Browser
Legacy
OpenGL Error
Meta
Good First Issue
Meta
Papercut
Meta
Retrospective
Meta
Security
Module
Animation & Rigging
Module
Core
Module
Development Management
Module
EEVEE & Viewport
Module
Grease Pencil
Module
Modeling
Module
Nodes & Physics
Module
Pipeline, Assets & IO
Module
Platforms, Builds & Tests
Module
Python API
Module
Render & Cycles
Module
Sculpt, Paint & Texture
Module
Triaging
Module
User Interface
Module
VFX & Video
Platform
FreeBSD
Platform
Linux
Platform
macOS
Platform
Windows
Priority
High
Priority
Low
Priority
Normal
Priority
Unbreak Now!
Status
Archived
Status
Confirmed
Status
Duplicate
Status
Needs Info from Developers
Status
Needs Information from User
Status
Needs Triage
Status
Resolved
Type
Bug
Type
Design
Type
Known Issue
Type
Patch
Type
Report
Type
To Do
No Milestone
No project
No Assignees
5 Participants
Notifications
Due Date
The due date is invalid or out of range. Please use the format 'yyyy-mm-dd'.

No due date set.

Dependencies

No dependencies set.

Reference: blender/blender#30663
No description provided.