Stereoscopic Cube6x1 - why the odd / mirrored output?

[landrvr1]

Is there a specific reason why Chaos outputs Cube6x1 images the way they do? The entire image is mirrored, and the sequence is odd.

Tnx

[vlado]

The viewers that we tested initially when developing the feature required exactly that specifc output. Most current viewers seem to work fine too.

Best regards,
Vlado

[landrvr1]

Vlado, that's because everyone has had to write scripts to fix the problem. However, with KRPANO - by far the most popular software - any Vray image has to be taken apart and reassembled manually.

[vlado]

Hm, really? I know that lots of people use KRPano (though I haven't used it myself). I'm not against reworking it, mind you, I just want to be sure it's the right thing to do.

Best regards,
Vlado

[AlexP]

Hm, really? I know that lots of people use KRPano (though I haven't used it myself). I'm not against reworking it, mind you, I just want to be sure it's the right thing to do.

Best regards,
Vlado

KRpano needs it to be flipped, would be great to have the option in Vray. Even better would be the option to render out the 6 faces to separate files

http://forums.chaosgroup.com/showthr...092#post704092

[landrvr1]

Indeed. But it's more than just flipped.

Coming out of V-Ray there are two things that have to be corrected for the cubemap to work in ANY VR app or software:

1. Horizontal flip. The entire 12 image strip needs to first be mirrored on the horizontal.
2. After the mirroring, the top and bottom views need to be rotated 180°

In addition to KRPANO, VR services like Yulio actually do these corrections on their end in order for the panos to work in either desktop (mono) or VR mode (stereo). I have confirmed this with a representative from Yulio.

I can also confirm that Revit exports it's cubemap in the same fashion - it's backward and the top and bottom views need to be rotated.

As near as I can tell, this backward imaging became a standard very early on in the gaming industry when the first VR dedicated headsets were coming to market. For some reason, no one challenged this odd output method and now V-Ray, Revit, and other cad/rendering software all do their export the same way.

Unfortunately this has meant one thing: more work for the artist at the post end / special scripts being written by developers. I know that there is a viz artist out there who is currently writing a small program to manually do all this for us, but it's not been released yet.

It would be great to have a Cubemap option out of Vray that could offer a 'corrected' image.

Tnx Vlado!

[vlado]

Our developer tells me that the format was originally intended to work with the Samsung and Otoy players for the GearVR, as well as Virtual Desktop and the free sView.

As we have no immediate plans to support all possible formats in terms of mirroring, rotation and rearrangement of the 6 sides (there are more than a thousand different combinations), it might be faster to contact the developers of KRPano and whoever else so that they can add code to support for the V-Ray format. In my opinion the viewer is the correct place for doing these transformations. If one of these arrangements becomes a predominant one in the future, we will change our implementation, but for the moment we can't support the whims of every single viewer app out there.

Best regards,
Vlado

[landrvr1]

I understand what you are saying. However, the vast majority of VR software and providers are all on the SAME standard - and that standard involves doing the exact same image correction. Every single viewer app or software that relies on a phone is on that same standard. ONLY those dedicated viewers like the RIFT can use the V-Ray images out of the box. Since phone based viewer usage vastly outnumber dedicated viewers.....

At the end of the day what you are suggesting is that everybody needs to get on the same page in terms of providing a common correction, since the problem has existed almost from the start of VR. I guess that works but....

[Neilg]

Every single viewer and app i've used - mobile, desktop 2d and rift/vive takes the way vray renders it as standard, we've never had to edit it.
The problem didnt exist when vr apps first started because they followed the standard set by the otoy viewer on the gear vr. only now there are a ton more apps do you have developers glancing at an example and implementing it wrong.

[landrvr1]

You've never had to edit in most of those cases because it's being done on the back end by the developers/software. This is the case with popular apps like Yulio and Smart2VR, and a slew of others. In fact, I have absolutely no idea why or how those pioneers required images to be backwards. In terms of coding and optics it makes zero sense.

[vlado]

<shrug> We won't do anything for the moment. Let's talk again in 6 months and see where things are at... I'm curious though, how do you define the popularity of an app?

As to what makes sense or doesn't, let's not get there There are so many odd things in CG that have no explanation other than "it's simply been that way forever". Like I said, I have no specific preferences for any particular layout, but we can't go around changing it every few months or so. Btw you can always ask Otoy or Samsung why they developed their viewers in this way...

Best regards,
Vlado

[landrvr1]

Thanks Vlado. It's so difficult to know the trajectory of VR. CGarchitect had an interesting poll with graphic results not too long ago:

http://www.cgarchitect.com/2016/07/s...ge-in-arch-viz

Kinda short but good info.

As mentioned, there is a guy out there who is apparently working on a small tool to correct the images. I'll post here again as that progresses.