ImageBackground: can **not** animate texCoords! about view3dscene HOT 17 CLOSED

Indeed, I didn't implement animating of texCoords on ImageBackground. I'll fix it soon (tomorrow probably). It's indeed because ImageBackground rendering is "special".

As for the geometry -- I would advise to do it differently. Create a shell script ("batch" script in Windows), that contains a command like view3dscene --geometry 512x512. Save it in a file like my_view3dscene.bat and execute my_view3dscene.bat instead of running view3dscene.exe.

This is a safer solution, since this way you will not "forget" about such preference. And it's more flexible. You can use this technique to use a lot of other view3dscene command-line options, e.g. --fullscreen, pass a specific X3D filename to open etc.

Don't worry about testing with Instant Reality, it's not like I want to be "limited" to support only what Instant Reality supports :) Animating ImageBackground.texCoords makes sense, it should work, regardless of Instant Reality :)

from view3dscene.

P.S. Thanks for the note about invalid URLs in https://github.com/castle-engine/demo-models , I fixed them now.

from view3dscene.

Indeed. Sorry, I simply didn't yet find the time to implement it. This task is on my to-do list, but it's a crowded list now :) I'll try to do it this weekend.

from view3dscene.

Ah, I didn't think of using texCoords to rotate the texture. I didn't even realize that you do it in testcase. This will not work (as you found out) and is a bug. There is no difference here between fixed and shader pipeline.

I know how to fix it. It will require a bit of work, will be done in a few days.

Thank you for testing. I'll let you know when it's fixed.

As for the behavior of color, I did it deliberately and also think it's better. We use color alpha, and we use texture alpha, and we multiply them. If it is partially-transparent, it will be mixed with default background color. This is documented on https://castle-engine.io/x3d_implementation_environmentaleffects_extensions.php , and I also don't think we should change it.

from view3dscene.

Thank you for testing and info. I'll play around with it on the weekend.

P.S. I also saw your email in which in you send the same thing :) Sorry for not answering earlier, no time.

from view3dscene.

Hi Michalis,

new month -- new luck:

I finally found a version of InstantReality framework (from ftp://ftp.igd.fraunhofer.de/irbuild/Windows-i686/archive/InstantReality-Windows-vs2008-x86-2.3.0.25322.msi) that doesn't crash or has any other issues (like missing 'libLAS.dll' etc.).

It's old (version 2.3.0 from 17.07.2013) and only 32 bits but apart from that works like a breeze!

Originally I also wanted to animate the ImageBackground color, but there's no ColorInterpolatorRGBA!
Neither InstantRealityPlayer nor X3D v4.0 has it! -- This should be proposed to the Web3D commitee!

What really is cool about InstantPlayer: it supports to set the window size (and anti-aliasing) from within the X3D-file!

<X3D profile="Full" version="3.3">
  <Engine>
    <RenderJob>
      <WindowGroup>
	<Window size='512 512' sample='8' sampleFilterMode='nicest'/>
      </WindowGroup>
    </RenderJob>
  </Engine>
  <Scene>
    ...
  </Scene>
</X3D>

This is a much better approach than batch files, which circumvent MS-Windows's file-association-mechanism, where I click on a X3D-file and it opens with View3DScene or InstantPlayer, depending on to which executable the .x3d-suffix is set!

That's even better than putting the resolution/geometry information into view3dscene.conf!

• Would be nice if View3DScene also (partially) supported InstantPlayer's Engine/Window node!

With best regards,

Elmar

P.S.: here are my test files: view3dscene_issue_19-1.zip

from view3dscene.

Hi Michalis,

I have just tested view3dscene-3.18.0-win64-x86_64.zip | 2019-09-04 16:05 | 4.0M | Latest Windows version (64-bit), but it still doesn't allow to animate the texCoords property of ImageBackground!

Please help!

With best regards,

Elmar

from view3dscene.

Done :)

( As it happens, I was sitting to this when you wrote the last email to me today :) ).

A new version of view3dscene should be available in ~15 minutes on http://michalis.ii.uni.wroc.pl/view3dscene-snapshots/ as usual.

I have also added your testcase to demo-models, to https://github.com/castle-engine/demo-models/blob/master/background/background_image_animated.x3d . Please let me know if you don't want this, I'll remove it then. (The demo-models are distributed on open-source GNU GPL >= 2 license, see the bottom of https://github.com/castle-engine/demo-models ).

from view3dscene.

P.S. Note that I have created nice docs for ImageBackground on https://castle-engine.io/x3d_implementation_environmentaleffects_extensions.php , and also just improved how transparent ImageBackground (in case the texture or color has alpha) interacts with underlying color.

from view3dscene.

Hi Michalis,

Sorry for my late answer, but my internet was down for several hours, probably because of the fifty years old TeleCom phone lines (urgh!!!)

Thank you for enabling fixed shader pipeline for me again and of course for trying to fix texCoords animation in ImageBackground node, but sadly it doesn't behave at all like in InstantPlayer!

[background_image_still_pattern_8080.png]

The background simply scales the texture horizontally and vertically (at least it's animated!), but does not rotate the pattern, as it does in InstantPlayer! -- Is that again a fixed/pure shader issue?

You probably also noted the different coloring (especially of the background). The reason seems to be, that InstantPlayer discards the alpha channel of the pattern and then multiplies it with the background RGBA color! That's why I used image="2 2 2 0xFFFF 0x8080 0x8080 0xFFFF" and not image="2 2 2 0xFFFF 0xFF80 0xFF80 0xFFFF", which works fine in View3DScene-3.18.0-64bit but not in InstantPlayer-2.3.0-32bit! -- (I prefer View3DScene's behavior!)

[background_image_still_pattern_FF80.png]

I'm afraid you have to fix the animated texCoords issue again -- sorry!

But please leave View3DScene's color behavior as it is!

I include an improved version of this, which not only uses 0xFF80 but also animates the texture and the cube! If you like it, put it to the demo-models!

BTW: you can stop the animation by pressing CTRL! (does not work in InstantPlayer)

With best regards,

Elmar

P.S.: here are the files: view3dscene_issue_19-2.zip

from view3dscene.

Rendering of the ImageBackground was rewritten. This fixes this issue -- texCoords are now supported fully, and the animation inside your testcase is OK.

Also:

• The new code has other benefits: it is more consistent with the rest of the X3D rendering.

• In particular MovieTexture is now supported too inside ImageBackground.texture. I added a demo to demo-models, https://github.com/castle-engine/demo-models/blob/master/background/image_background/background_movie.x3dv . All ImageBackground demos are now in one directory, https://github.com/castle-engine/demo-models/tree/master/background/image_background .

• I also updated docs on https://castle-engine.io/x3d_implementation_environmentaleffects_extensions.php a bit.

As usual, new view3dscene should be available on http://michalis.ii.uni.wroc.pl/view3dscene-snapshots/ in ~15 minutes.

from view3dscene.

Hi Michalis,

sorry again for my late answer, but I was testing the latest build of View3DScene with your fix:
view3dscene-3.18.0-win64-x86_64.zip | 2019-09-23 03:07 | 4.0M | Latest Windows version (64-bit)

Wow, it works perfectly:

The image above is an animated PNG. You should see a 1-sec-animation if your browser is up to date!

The Animated Portable Network Graphics (APNG) file format is an extension to the Portable Network Graphics (PNG) specification. It allows for animated PNG files that work similarly to animated GIF files, while supporting 24-bit images and 8-bit transparency as you can see here:

APNG is supported by up to date versions of Chrome, Firefox, Safari, Opera and the new Chromium-based Microsoft Edge internet browser. FFmpeg and XNview also support APNGs.

• You should consider to support APNG as MovieTexture via e.g. Vampyre Imaging Library ;)

I attach a ZIP with my inproved version of background_image_animated.x3d to be added to your demo-models/background/image_background repository replacing the old background_image_animated.x3d!

• It also contains both APNGs and the batch files to create them!

I only used View3DScene (for producing twenty-five 24bit PNGs), PNGquant (for optionally reducing color depth to 8bit) and APNGasm (to create the actual optimized animated PNG with 25 fps)!

The flame animation above, for instance, was produced with APNGasm flame.png *.png 1 25 in my copy of your demo-models/movie_texture/flame/seamless directory!

Even MovieTexture works now -- fantastic!

Thank you very much!

for all your tedious work to make texCoords animation work properly!

With best regards,

Elmar

P.S.: here are the files: view3dscene_issue_19-3.zip

from view3dscene.

Thanks for testing!

Since APNG is already supported by ffmpeg, it may be trivial to add simple view3dscene support for it. I'll look into it soon.

from view3dscene.

And thank you for the updated background_image_animated.x3d -- I committed it to demo-models.

from view3dscene.

Hi Michalis,

on https://castle-engine.io/x3d_implementation_texturing.php you wrote:

We can also open movies from images sequence. This doesn't require ffmpeg, and allows for some tricks (movie texture with alpha channel).

Because of that, I proposed the idea of using animated PNGs as partially transparent movie textures.

Now I have found out, that it is indeed possible to create partially transparent MP4 movies and use them as movie textures in View3DScene!

I made use of the fact that FFmpeg is able to copy a sequence of PNG files into a MP4 container.

It was quite simple:

:: create temporary directory
md temp
 
:: X3D animation -> 100 PNG images
View3DScene background_image_animated.x3d --geometry 512x512 --anti-alias 6 --no-sound
--viewpoint 0 --screenshot-transparent --screenshot-range 12 0.04 100 temp\temp@counter(3).png
 
:: reduce image size (adds '-or8' to filename)
PNGquant --strip --ordered --speed=1 --quality=50-90 temp\*.png
 
:: 100 PNG images -> MP4 with transparency!
FFmpeg -i temp/temp%%03d-or8.png -r:v 25 -c:v copy -map 0:v -t 4 -shortest
-y background_image_animated.mp4
 
:: cleanup
rd/s/q temp

• I have attached a ZIP with the conversion batch files, the resulting MP4 and APNG files and a X3D movie texture test file: view3dscene_issue_19-4.zip

• You can add the files to your demo-models/movie_texture repository if you like!

BTW: the resulting MP4 file is only slightly bigger (407 kb) than the animated PNG (391 kb) produced with the same optimizations!

With best regards,

Elmar

P.S.: the MP4/APNG files can not be viewed in XNview (shows an error) but show alright in FFplay!

from view3dscene.

Hi Michalis,

in the meantime I have tested further video codecs that support transparency:

• png 8bit (with palette) [MP4]
• png 32bit [MP4]
• qtrle 32bit (quicktime run-length-encoded) [MOV]
• v408 32bit (yuva444p) [MOV]
• rawvideo 32bit [AVI]

Some of the files are very big (v408 and rawvideo), but qtrle is acceptable.
All work with View3DScene/FFmpeg but do not play in InstantPlayer or OctagaPlayer.
The paletted 8bit png video shows in freeWRL, but not completely correct (for unknown reasons).

With best regards,

Elmar

P.S.: as always I attach the test files: view3dscene_issue_19-5.zip

from view3dscene.

Hi Michalis,

I found a minor issue when FFmpeg is used.

In castlevideo.pas you use FfmpegExecute(Executable, [ '-i', MovieFileName, '-y', '-qscale', '1', '-vframes', IntToStr(MaximumVideoLength), '-f', 'image2', FfmpegTemporaryImagesPattern ]); to read in images/videos,

but FFmpeg warns: Please use -q:a or -q:v, -qscale is ambiguous

although the FFmpeg documentation says:

-q[:stream_specifier] q (output,per-stream)
-qscale[:stream_specifier] q (output,per-stream)

Use fixed quality scale (VBR). The meaning of q/qscale is codec-dependent. If qscale is used without a stream_specifier then it applies only to the video stream, this is to maintain compatibility with previous behavior and as specifying the same codec specific value to 2 different codecs that is audio and video generally is not what is intended when no stream_specifier is used.

• So probably, because at the moment audio is not extracted, it would be nice to change '-qscale' in castlevideo.pas into '-qscale:v' or '-q:v' to get rid of the warning. -- I have tested it: it works alright!

• This change seems to be compatible with AVconv, according to its documentation.

Also I found a reference to 'http://ffmpeg.mplayerhq.hu/' in castlevideo.pas, which seems not to exist anymore and is re-directed to 'http://ffmpeg.org/' anyway.

With best regards,

Elmar

from view3dscene.