it's not working for me :c

finnthedoggy said:
it's not working for me :c

It's a 180° VR stereogram that's not cross-eyed, if that's the method you're trying to use. It's meant to be used with a video player that allows hemispherical projection (I recommend sView, it's free and open source and works with SteamVR out of the box) and a VR headset.

Glad to see you're back.

I would LOVE to see more like this

What a cute reflection in the window :3

If you have a VR-Device just try this!
It's rly good!
2 sad that there no other good stereograms like this out there >_>

@HelloAnonMyOldFriend: is it hard 2 make stereogram like this out of a normal 3d-Animation?

helloanonmyoldfriend said:
It's a 180° VR stereogram that's not cross-eyed, if that's the method you're trying to use. It's meant to be used with a video player that allows hemispherical projection (I recommend sView, it's free and open source and works with SteamVR out of the box) and a VR headset.

I mean, the video isn't playing

runario said:
is it hard 2 make stereogram like this out of a normal 3d-Animation?

It needs to be re-rendered, obviously. 3840x1920 is 3.5x more pixels than Full HD, and with VR 60 FPS is much more preferable than with normal video. C4D has built-in support for spherical cameras and side-by-side stereograms, so I didn't need to do any ugly hacks like baking reflection textures on a sphere or something. What mainly needed tuning up was the camera motion to not obstruct too much with the throat, and formerly off-camera objects needed to be animated. A bunch of little adjustments, nothing too bad. The shitty metaball cum "fluidsim" had to be rerun at 60 FPS.
The biggest issue, however, was Cinema 4D itself; it really, really hates me, and the whole program would just start spazzing out: I'd set some value, and the program would skip to a random frame or start recalculating the whole animation. I don't know if it's caused by simply too many keyframes, too long animations, or it's the non-linear animation implementation they have that sucks. Wouldn't be surprised with the latter, because it certainly does suck. Oh yeah, and the juicy memory leaks during rendering causing an out of memory every 4.5 hours after filling up RAM and 130 GB of pagefile.

finnthedoggy said:
I mean, the video isn't playing

Works fine for me. Can you play other VP9 WebM videos? Besides, it's not meant to be played in the browser (unless there's some browser extension that connects to a headset and does the right projection) but in a specialised VR video player. The Mega source link contains a higher quality H.265 MP4 version too, you can try that one.

helloanonmyoldfriend said:
It needs to be re-rendered, obviously. 3840x1920 is 3.5x more pixels than Full HD, and with VR 60 FPS is much more preferable than with normal video. C4D has built-in support for spherical cameras and side-by-side stereograms, so I didn't need to do any ugly hacks like baking reflection textures on a sphere or something. What mainly needed tuning up was the camera motion to not obstruct too much with the throat, and formerly off-camera objects needed to be animated. A bunch of little adjustments, nothing too bad. The shitty metaball cum "fluidsim" had to be rerun at 60 FPS.
The biggest issue, however, was Cinema 4D itself; it really, really hates me, and the whole program would just start spazzing out: I'd set some value, and the program would skip to a random frame or start recalculating the whole animation. I don't know if it's caused by simply too many keyframes, too long animations, or it's the non-linear animation implementation they have that sucks. Wouldn't be surprised with the latter, because it certainly does suck. Oh yeah, and the juicy memory leaks during rendering causing an out of memory every 4.5 hours after filling up RAM and 130 GB of pagefile.

So it's a bit more than just pressing a button and waiting for the finished stereogram...
...because more stuff like this would be rly nice.（；´д｀）ゞ
But thx for this beautiful animation anyway...

runario said:
@HelloAnonMyOldFriend: is it hard 2 make stereogram like this out of a normal 3d-Animation?

I know this question isn't for me, but I have basically zero blender experience of any kind, but I have some blender animation files from artists and making it stereoscopic was basically one click and then re-render the whole two scene with two offset cameras and making it VR is just altering FoV.
I'm guessing only reason for artists to not do this is because it essentially doubles rendering time and there's far less people watching porn with stuff on their face and rather have phone in their hand according to how much people browse e621 with their phone.

helloanonmyoldfriend said:
Works fine for me. Can you play other VP9 WebM videos? Besides, it's not meant to be played in the browser (unless there's some browser extension that connects to a headset and does the right projection) but in a specialised VR video player. The Mega source link contains a higher quality H.265 MP4 version too, you can try that one.

The easiest way to watch this video is actually just playing it fullscreen on phone and putting it on cardboard box. Bit outdated system at this stage already, but it still works and I actually even have my old cardboard with lenses in great condition.
Also as for e621, content posted here should be directly visible and viewable by the users regardless of what it is, so if there is problem viewing post directly, then there is a problem that needs to be looked into.

The main culprit for the video not playing is bt470bg colorspace. I have to admit, whenever there's stuff or problems around colorspaces, I start to scream. Usually with video problems I can find some sort of documentations or forum posts or something to explain stuff and have solutions, however with colorspace stuff, most are just assumptions and commands that seem to fix problem but not sure why, sometimes straight up nothing.
However I do know that bt709 is like the default, modern, HD colorspace and bt2020 is like the newest HDR colorspace and quick googling bt470bg is PAL DVD colorspace.

finnthedoggy said:
it's not working for me :c

Try now, poke or flag if there's still problems.

mairo said:
Try now, poke or flag if there's still problems.

That change has utterly fucked up the colors on my end (scaled versions and original affected): https://files.catbox.moe/6qtyxj.jpg
For comparison, it looked like this before (direct upload of AE render): https://files.catbox.moe/esxdda.jpg
Beforehand the video played just fine in Firefox, Chrome, Edge, and VLC (though VLC has some different unrelated issues regarding to color ranges and hardware acceleration). Now it's messed up in all of 'em.
The ffmpeg command I used to create the video was the following:

ffmpeg -y -framerate 60 -i "(path)%04d.jpg" -pass 2 -c:v libvpx-vp9 -pix_fmt yuv420p -b:v 12.2M output.webm

However, I'm not entirely sure if I used yuv420p or yuvj420p, and MediaInfo doesn't tell. That might be an issue, and I thought playing it in three different browsers plus VLC would be enough testing. Actually I'm reasonably sure I used yuv420p because of the kerfuffle with yuv444p below and I didn't want to risk yet another re-encoding. From quick googling, the difference is that yuvj420p encodes in full color space, which should be the desirable outcome; otherwise it squeezes/cuts it to the range of 16-240, losing quality and causing faulty players (like VLC mentioned above unless running in DirectX 9 mode) to somehow mess colours up and make them too dark (not nearly as much as it is now, though, see here (wrong on the left, correct on the right): https://files.catbox.moe/64elo1.jpg ), but both seemed to act identically (fine in browsers, bad in VLC except for DX9 mode).

I can re-encode the video with proper settings if you know of any (I guess arg -colorspace bt709 should do the trick? Seems to then work fine) (I went off from your post on compressing large videos, minus the allowing it to run for hours bit), because as it is now in here, the video looks awful and seems to be the only one on the site to be affected like this for me, so I doubt it's a viewing problem on my end.

Fun anecdote: I thought I could get extra quality with yuv444p that the rendered frames from After Effects use, because hey, more chroma per chroma, but that failed the upload form's validation (probably with good reason), so I had to reencode it again with standard yuv420p.

helloanonmyoldfriend said:
That change has utterly fucked up the colors on my end (scaled versions and original affected): https://files.catbox.moe/6qtyxj.jpg
For comparison, it looked like this before (direct upload of AE render): https://files.catbox.moe/esxdda.jpg
Beforehand the video played just fine in Firefox, Chrome, Edge, and VLC (though VLC has some different unrelated issues regarding to color ranges and hardware acceleration). Now it's messed up in all of 'em.
The ffmpeg command I used to create the video was the following:

ffmpeg -y -framerate 60 -i "(path)%04d.jpg" -pass 2 -c:v libvpx-vp9 -pix_fmt yuv420p -b:v 12.2M output.webm

However, I'm not entirely sure if I used yuv420p or yuvj420p, and MediaInfo doesn't tell. That might be an issue, and I thought playing it in three different browsers plus VLC would be enough testing. Actually I'm reasonably sure I used yuv420p because of the kerfuffle with yuv444p below and I didn't want to risk yet another re-encoding. From quick googling, the difference is that yuvj420p encodes in full color space, which should be the desirable outcome; otherwise it squeezes/cuts it to the range of 16-240, losing quality and causing faulty players (like VLC mentioned above unless running in DirectX 9 mode) to somehow mess colours up and make them too dark (not nearly as much as it is now, though, see here (wrong on the left, correct on the right): https://files.catbox.moe/64elo1.jpg ), but both seemed to act identically (fine in browsers, bad in VLC except for DX9 mode).

I can re-encode the video with proper settings if you know of any (I guess arg -colorspace bt709 should do the trick? Seems to then work fine) (I went off from your post on compressing large videos, minus the allowing it to run for hours bit), because as it is now in here, the video looks awful and seems to be the only one on the site to be affected like this for me, so I doubt it's a viewing problem on my end.

Fun anecdote: I thought I could get extra quality with yuv444p that the rendered frames from After Effects use, because hey, more chroma per chroma, but that failed the upload form's validation (probably with good reason), so I had to reencode it again with standard yuv420p.

First of all why is your image sequence JPG instead of PNG?

Anyway, it seems I actually used wrong -vf colorspace to compensate for the colorspace conversion, so that's what causing the colors to look like that. It's not broken or corrupted file, but the colors were actually changed incorrectly during transcoding.
Problem is you cannot just tell the video encoder that video is specific colorspace, you have to also compensate for the difference between colorspaces. This is also the reason why a lot of posts look more vibrant on 𝕏 and duller on FA, because FA actually removes color profiles without compensation conversion to sRGB, so they just do not display correctly, you have to actually convert the colors so that bright red is bright red also after it and not dull red.
-colorspace 1 -color_primaries 1 -color_trc 1 should work to make the file bt709 as with everything 1=bt709. -color_range is the other setting you are talking about where you either have TV standard (1) where it's that limited 16-240 range or PC (2) where it's full range. yuv420p and yuvj420p should be exactly the same, however yuvj420p is h264 thing and should be depracated already.

And this is why I said I don't really wanna touch colorspaces and color stuff in general because it's not a single setting, it's a lot of settings.

YUV420 is required because browsers streaming video file expects that and anything above will most likely end up showing up corrupted to end users, there's also many threads of people complaining how YUV444 won't play on something like Firefox and statuses for those issues are that it's working as intented and won't be fixed. This should not be too huge of an issue as absurdly huge majority of video content is YUV420 by default. You can get bit better color clarity even with YUV420 by enforcing scaler to use higher quality interpolation, e.g. -sws_flags 'lanczos+accurate_rnd+full_chroma_int', this also works if you do pixel animation, scale on factor of 2 and use neighbor scaler.

But yes, this post still needs correcting it seems.

mairo said:
First of all why is your image sequence JPG instead of PNG?

So that the animation only takes up 18 GB instead of 72. Frankly that's not as big of a difference as I thought (not even considering the amount of page file the leaky memory had frequently occupied), so, a fair point. I'm not re-rendering this one though (at most the AE project that takes an hour to render; no way am I re-rendering the C4D scene for another 15 hours or so, I can see the god dang hot dog just fine without jay-pegh artefacting (in motion at least...)).

mairo said:
But yes, this post still needs correcting it seems.

Anything that needs to be done on my end? I don't know whether this colorspace-swapping-of-existing-video process is lossless or not.

helloanonmyoldfriend said:
So that the animation only takes up 18 GB instead of 72. Frankly that's not as big of a difference as I thought (not even considering the amount of page file the leaky memory had frequently occupied), so, a fair point. I'm not re-rendering this one though (at most the AE project that takes an hour to render; no way am I re-rendering the C4D scene for another 15 hours or so, I can see the god dang hot dog just fine without jay-pegh artefacting (in motion at least...)).

Anything that needs to be done on my end? I don't know whether this colorspace-swapping-of-existing-video process is lossless or not.

Also at least on blender, the PNG files will be 48-bits, meaning that you have significantly much more data to work from as well in editing phase. Know this because I have literally rendered and zipped full PNG renders to fren who needed some computing power.
But if it's already JPG, then it's already JPG and that won't most likely have that huge of impact and when the quality is high enough, the compression stacking most likely is impossible to see at that level.

I can ask admin to just give you replacement system access, after which you should have simple "Replace image" on the left side of the post. Submit file and the file will replace the current file on the post after janitor approves it.

mairo said:
I can ask admin to just give you replacement system access, after which you should have simple "Replace image" on the left side of the post. Submit file and the file will replace the current file on the post after janitor approves it.

Works for me. Or if it would be preferable to not go that route, here's the encoded-again version:
https://mega.nz/file/WxsxwZQL#u8P-79lQGwmXAwRJioO5m3Mi-smiyFk4TxQThT0ZftY
I used the args you provided; the result seems to look good, and MediaInfo says it's BT.709.

So hottt, never came harder in my life ~w~

I wish there was more stuff like this out there. I know making vr games/videos is trickier than we think, but there's a niche that I'd like to see filled more with things other than simple loops.