EEVEE image sequence frame offset not working [in multiple image texture nodes having the same image datablock] #70028

New Issue

Alexandre Bon · 2019-09-18T15:09:46+02:00

Alexandre Bon commented

2019-09-18 15:09:46 +02:00

System Information
Operating system: WIN 10
Graphics card: RTX 2070

Blender Version
Broken: 2.81 date 2019-09-08
Worked: none

Short description of error
if I use one video texture in different materials, I only change the frame offset of the texture node

CYCLES: work as expected ( image is offset in time)
EEVEE: all materials use the same frame of the video texture

test_offset_blender-02.zip

Exact steps for others to reproduce the error
set viewport to "rendered" mode. just switch from EEVEE to CYCLES to see the difference (the number displayed on the texture is the frame number of the texture)

**System Information** Operating system: WIN 10 Graphics card: RTX 2070 **Blender Version** Broken: 2.81 date 2019-09-08 Worked: none **Short description of error** if I use one video texture in different materials, I only change the frame offset of the texture node - CYCLES: work as expected ( image is offset in time) - EEVEE: all materials use the same frame of the video texture ![test_offset_v02_eevee.jpg](https://archive.blender.org/developer/F7755558/test_offset_v02_eevee.jpg) ![test_offset_v02_cycles.jpg](https://archive.blender.org/developer/F7755559/test_offset_v02_cycles.jpg) [test_offset_blender-02.zip](https://archive.blender.org/developer/F7755561/test_offset_blender-02.zip) **Exact steps for others to reproduce the error** set viewport to "rendered" mode. just switch from EEVEE to CYCLES to see the difference (the number displayed on the texture is the frame number of the texture)

Alexandre Bon commented

2019-09-18 15:09:46 +02:00

Added subscriber: @albo

blender-admin commented

2019-09-18 15:09:46 +02:00

#75241 was marked as duplicate of this issue

blender-admin commented

2019-09-18 15:09:46 +02:00

#72666 was marked as duplicate of this issue

blender-admin commented

2019-09-18 15:09:46 +02:00

#74920 was marked as duplicate of this issue

Jacques Lucke commented

2019-09-19 13:39:15 +02:00

Added subscriber: @JacquesLucke

Jacques Lucke commented

2019-09-19 13:39:15 +02:00

Confirming, because the behavior of eevee and Cycles is different. However, isn't eevee correct and Cycles wrong? You are on frame 22, with an offset of 10. In eevee it shows frame 32 (which is what I'd expect) while in cycles it shows 21 instead.

Alexandre Bon commented

2019-09-27 14:15:35 +02:00

According to me behavor in CYCLES is OK.
EEVEE seems to drop the frame offset of image texture nodes. Only when multiple nodes point to the same image file sequence.

This may come from an optimisation check to avoid loading copies of the same image... But that check should be disabled when frame offset is different.

Workaround: for now i have to duplicate my file sequences physically on disk... wich is really space hungry

According to me behavor in CYCLES is OK. EEVEE seems to drop the frame offset of image texture nodes. Only when multiple nodes point to the same image file sequence. This may come from an optimisation check to avoid loading copies of the same image... But that check should be disabled when frame offset is different. Workaround: for now i have to duplicate my file sequences physically on disk... wich is really space hungry

Philipp Oeser commented

2019-12-04 14:53:04 +01:00

Added subscribers: @fclem, @brecht, @lichtwerk

Philipp Oeser commented

2019-12-04 14:53:04 +01:00

@JacquesLucke: point here is that there are two materials [one using an offset of -1, one using an offset of 10]. Cycles displays different numbers on different faces of the cube, whereas Eevee displays the same.

However, isn't eevee correct and Cycles wrong? You are on frame 22, with an offset of 10. In eevee it shows frame 32 (which is what I'd expect) while in cycles it shows 21 instead.

For me, Eevee shows 32 for both materials (which might be wrong), whereas Cycles shows one face with 32 [offset 10 in Material.001], one face with 21 [offset of -1 in Material.002] (which might be correct).

@albo : it does work though for Eevee as well if you are using a different Image datablock [pointing to the same filepath on disk -- so you dont have to duplicate your sequences on disk] like so:
test_offset_v02_corrected.blend

So the offset is set on the Image Texture nodes ImageUser, in the provided file this should point to the same Image datablock, no?
Not even sure how cycles manages to have different offsets on the same block (but I havent really checked internals here...)

In my opinion, the preferred solution for this kind of scenario would be to use different image datablocks with different offsets like in the "corrected" file I posted.
This then works reliably for both cycles and eevee.
This would also mean that this is not a bug....

On the other hand, maybe @fclem and/or @brecht could share their wisdom here how this is really designed/meant to be used?

@JacquesLucke: point here is that there are two materials [one using an offset of -1, one using an offset of 10]. Cycles displays different numbers on different faces of the cube, whereas Eevee displays the same. > However, isn't eevee correct and Cycles wrong? You are on frame 22, with an offset of 10. In eevee it shows frame 32 (which is what I'd expect) while in cycles it shows 21 instead. For me, Eevee shows 32 for both materials (which might be wrong), whereas Cycles shows one face with 32 [offset 10 in Material.001], one face with 21 [offset of -1 in Material.002] (which might be correct). @albo : it does work though for Eevee as well if you are using a different Image datablock [pointing to the same filepath on disk -- so you dont have to duplicate your sequences on disk] like so: [test_offset_v02_corrected.blend](https://archive.blender.org/developer/F8189371/test_offset_v02_corrected.blend) So the offset is set on the Image Texture nodes `ImageUser`, in the provided file this should point to the same Image datablock, no? Not even sure how cycles manages to have different offsets on the same block (but I havent really checked internals here...) In my opinion, the preferred solution for this kind of scenario would be to use different image datablocks with different offsets like in the "corrected" file I posted. This then works reliably for both cycles and eevee. This would also mean that this is not a bug.... On the other hand, maybe @fclem and/or @brecht could share their wisdom here how this is really designed/meant to be used?

Philipp Oeser changed title from ~~EEVEE video texture time offset not working~~ to EEVEE video texture time offset not working [in multiple image texture nodes having the same image datablock]

2019-12-04 14:54:38 +01:00

Philipp Oeser commented

2020-03-19 11:50:35 +01:00

Added subscriber: @ChristophWerner

Philipp Oeser changed title from ~~EEVEE video texture time offset not working [in multiple image texture nodes having the same image datablock]~~ to EEVEE image sequence frame offset not working [in multiple image texture nodes having the same image datablock]

2020-03-19 11:51:18 +01:00

Philipp Oeser commented

2020-03-19 11:54:05 +01:00

Added subscribers: @clepsydrae, @Jeroen-Bakker, @DanielBystedt

Philipp Oeser commented

2020-03-19 11:55:06 +01:00

Just dropping following comment from #72666 as this might help:

In #72666#854492, @Jeroen-Bakker wrote:
Issue is related how images are cached and drawn. In EEVEE and Workbench an image can hold a single GPU texture and is refreshed when it is requested to do so GPU_texture_from_blender.
In the new drawing pipeline all textures are first updated. And then the draw calls are sorted to increase performance.

There are more related issues around this area and needs to be addressed by a good design and implementation so will mark this as known issue for now.

Just dropping following comment from #72666 as this might help: > In #72666#854492, @Jeroen-Bakker wrote: > Issue is related how images are cached and drawn. In EEVEE and Workbench an image can hold a single GPU texture and is refreshed when it is requested to do so `GPU_texture_from_blender`. > In the new drawing pipeline all textures are first updated. And then the draw calls are sorted to increase performance. > > There are more related issues around this area and needs to be addressed by a good design and implementation so will mark this as known issue for now.

Christoph Werner commented

2020-03-19 12:50:46 +01:00

Please don't forget this issue. It's still important to be fixed, please. Same issue posted by me can be found here, with an additional example scene: #74920

Alexandre Bon commented

2020-03-19 13:55:29 +01:00

This issue is still important to me.
For crowds it is not realistic to duplicate files so many times on disk.

To avoid performance issues the optimisation of single load on GPU could be a preference switch.
I think EEVEE should have many performance vs quality switches. It would alleviate the unsolvable problem to balance between quality and speed.

This issue is still important to me. For crowds it is not realistic to duplicate files so many times on disk. To avoid performance issues the optimisation of single load on GPU could be a preference switch. I think EEVEE should have many performance vs quality switches. It would alleviate the unsolvable problem to balance between quality and speed.

Philipp Oeser commented

2020-03-19 14:35:00 +01:00

In #70028#894456, @albo wrote:
This issue is still important to me.
For crowds it is not realistic to duplicate files so many times on disk.

You dont have to duplicate them on disk, see

In #70028#823558, @lichtwerk wrote:
it does work though for Eevee as well if you are using a different Image datablock [pointing to the same filepath on disk -- so you dont have to duplicate your sequences on disk] like so:
test_offset_v02_corrected.blend

> In #70028#894456, @albo wrote: > This issue is still important to me. > For crowds it is not realistic to duplicate files so many times on disk. You dont have to duplicate them on disk, see > In #70028#823558, @lichtwerk wrote: > it does work though for Eevee as well if you are using a different Image datablock [pointing to the same filepath on disk -- so you dont have to duplicate your sequences on disk] like so: > [test_offset_v02_corrected.blend](https://archive.blender.org/developer/F8189371/test_offset_v02_corrected.blend)

Christoph Werner commented

2020-03-19 14:54:24 +01:00

In #70028#894481, @lichtwerk wrote:

In #70028#894456, @albo wrote:
This issue is still important to me.
For crowds it is not realistic to duplicate files so many times on disk.

You dont have to duplicate them on disk, see

In #70028#823558, @lichtwerk wrote:
it does work though for Eevee as well if you are using a different Image datablock [pointing to the same filepath on disk -- so you dont have to duplicate your sequences on disk] like so:
test_offset_v02_corrected.blend

I've overlooked your hint.
Very nice workaround, but it should be defined finally the same for both, Eevee and Cyles.

Thank you.

> In #70028#894481, @lichtwerk wrote: >> In #70028#894456, @albo wrote: >> This issue is still important to me. >> For crowds it is not realistic to duplicate files so many times on disk. > > You dont have to duplicate them on disk, see > >> In #70028#823558, @lichtwerk wrote: >> it does work though for Eevee as well if you are using a different Image datablock [pointing to the same filepath on disk -- so you dont have to duplicate your sequences on disk] like so: >> [test_offset_v02_corrected.blend](https://archive.blender.org/developer/F8189371/test_offset_v02_corrected.blend) I've overlooked your hint. Very nice workaround, but it should be defined finally the same for both, Eevee and Cyles. Thank you.

Alexandre Bon commented

2020-03-19 15:54:04 +01:00

Very nice, thanks.