@dtolios said:

Vray 1.49 does export directly to .exr if you want to, so the vray image file conversion step is not required.

Except that it does.

I repeat: exporting directly to exr (or exporting to jpg, png, etc) requires Vray to perform an in memory render, then exporting the result to file by means of a filter. This two step process always fail when rendering huge images, that was the reason for the whole post. Obviously, that's a known issue even to the CG, as they added the NoMemory/proprietary vrimg rendering option, which is a one step process only. Funny thing, there is no conversion utility included with vray for sketchup, so I believed the information provided could be of some use.

But if you don't believe me, try your method with a 64K X 32K render directly to exr, and tell us how it went. I personally made three tests (all failed), but due to excessive render time at such resolutions, I will be not attempting a fourth. Even if such a test would work, it's clear to me there is no reliability in it, as opposed to vrimg rendering that worked every single time.

@valerostudio said:

Would you mind sharing what one of these things look like with a link? I am very curious.

Gladly, in a few days, as I'm currently on the clock with a Project. Maybe monday.

@valerostudio said:

Why would you ever need a 32,000 wide pixel image?

Thanks for the reply.

I found that rendering to VRIMG and then converting was a total waste of time. Pay the $100 and get ProEXR and you will not regret it.

To produce a gigapixel spherical panorama (streetview like) of a virtual environment ready to be sliced and served.

Thoght that outputting to EXR is the same as rendering then saving, as did not allow me to select no memory, so vrimg/nomemory seemed to be the only option to avoid crashes. Also, converting the vrimg to exr was relatively fast so no problem there.

Cheers.

Related posts on this topic:

Rendering huge images with VRay 1.4 for Sketchup
http://sketchucation.com/forums/viewtopic.php?f=322&t=54220&p=491374#p491374

Make a render look like in the sketchup editor
http://sketchucation.com/forums/viewtopic.php?f=322&t=53980

A related follow up:

http://sketchucation.com/forums/viewtopic.php?f=322&t=54220

Vray 1.4 constantly crashed when trying to render at high resolutions like 32K x 16k or quad that. So, exporting to an usable format like PNG or JPG was impossible.
As we cannot wait hours (or days) for renders to complete just to have vray crashing on us on export, an alternative method needed to be found.
This is what I came up with:

STEP 1 - render to VRImage Raw Image file, and leave VFB mode to Preview or No Memory

this will produce a .vrimage file on your hard drive. (options - output)
tip: do not render channels you won't use, so, if you do not need an alpha channel, uncheck it from options - VFB channels

You better have a rendering farm or a spare computer you can forget of for a while at this point. I don't.

STEP 2 - convert .vrimg to .exr

Get chaosgroup utility vrimg2exr.exe - it is part of vray for 3ds, but not for ketchup, so I don't know how you will do that vrimg2exr.exe is a standalone command line utility, that allows transformation of the proprietary .vrimg format to the open .exr.

Example: vrimg2exr file.vrimg file.exr -half -bufsize 2000

"- half" parameter makes the conversion using 16 bit per channel instead of float 32, and not only is crucial to later conversions but reduces file size dramatically as it enable compression (from 3.7 GB to 70 MB in my case)

"- bufsize 2000" sets the working buffer to 2GB of ram, and the bigger the better (speed wise), but exceeding 3000 caused crashes as this utility might be 32 bit only.

STEP 3 - open the file.exr with Photoshop

Photoshop opens the .exr format, and is the only image editor able to do it, as far as I found. Adobe has a exr2png ($) conversion utility but with limited options.
Beware, the .exr filter used by PS has changed on the recent versions, and you might find usefully to know that the old filter can be still used instead of the new by simply overwriting the corresponding file. (it seems the new filter has some channel issues some users on the net found undesirable).
Also on the .exr home site you will find a PS filter for opening this format, freely downloadable, although I found it unnecessary.

STEP 4 - hold your horses, step 3 needs an addendum:

I recommend using a x64 version of PS for opening huge .exr files, for obvious memory reasons.
Even so, allocate lots of ram for PS and hdds with lots of free space for temps (in excess of 40GB, beware SSD owners), from options-performance in ps, before opening the .exr.
Au contraire, crashes might occur when exporting.

If using the new ps .exr filter on opening, a dialog will pop asking how to load the alpha channel (even if not existing). I selected to load it as an alpha channel, not transparency. Of course, my render lacked alpha to begin with, so no alpha channel was generated on import.

Convert the image to 8 bit per channel at this time, if you desire. It is now you will be grateful for that -half parameter, as 32 bit per channel images will convert white to 50% gray.

SO, STEP 4 - EXPORT TO WHATEVER: .JPG, .PNG, .TIF, .PSB

For my purposes, a lossless format is preferable, as .PNG or .TIF. Specifically I used PSB (Large Document Format)

DONE.

@cotty said:

@siramods said:

I was aware of the Panoscene plug-in, but this is not the solution and I'll explain why:
First, Panoscene is that DOES NOT generate a complete photosphere, only individual pictures that needs to be stitched lately with Hugin or another software. The stitching process consumes time and manual adjusting, and requires certain amount of detail to be present in every image for the algorithm to detect similarities needed to find control points. Especially when large areas of the photosphere are uniform colors or lack the necessary level of detail, as in the specific rendering I'm looking for, where large areas of sky or ground will remain perfect white, the usage of foto stiching software becomes most cumbersome.

This is not true because you get 6 cube faces and there is no overlapping to search for control points. You know which picture belongs to which cube face so you only have to do the same transformation (e.g. cube 2 equirectangular) in every case without the need for manual adjustment...

After installing Panoscene and SuCH from Renderiza, I had failed to produce any output (pressing create did nothing). But as far the interface of Panoscene goes, it seems obvious that the program rotates horizontally the camera in 22.5 degree increments, 16 of them, and completely ignores zenith and nadir. Having a look at the ruby code confirms this supposition, as I saw no computations along the Z axis, beside setting a fixed elevation. Reading the Panoscene thread, http://sketchucation.com/forums/viewtopic.php?f=323&t=53446, din not help, but confirm that the movement of the camera only occurs in the horizontal, and that the author is not familiarized with what nadir and zenith are.

All in one, would you be so kind to explain how to produce the 6 cube faces you mentioned with Panoscene? Or you could be referring to CubicPanoOut instead?
http://www.smustard.com/script/CubicPanoOut

@cotty said:

This is not true because you get 6 cube faces and there is no overlapping to search for control points. You know which picture belongs to which cube face so you only have to do the same transformation (e.g. cube 2 equirectangular) in every case without the need for manual adjustment...

Well, if that's true, I stand corrected, but I was mislead by the Panoscene description:
"Create panoramic scenes so that you can then export them and use image stitching software to merge them." Anyhow, thanks for pointing that out. Unfortunately, I still want to do that with VRay, even if I'll give Panoscene a try shortly.

The original question remain unanswered. How to configure VRay to mimic a render similar to the onscreen sketchup editor, and speed things up a little too.

I was aware of the Panoscene plug-in, but this is not the solution and I'll explain why:
First, Panoscene is that DOES NOT generate a complete photosphere, only individual pictures that needs to be stitched lately with Hugin or another software. The stitching process consumes time and manual adjusting, and requires certain amount of detail to be present in every image for the algorithm to detect similarities needed to find control points. Especially when large areas of the photosphere are uniform colors or lack the necessary level of detail, as in the specific rendering I'm looking for, where large areas of sky or ground will remain perfect white, the usage of foto stiching software becomes most cumbersome.
Secondly, I'm not looking for a solution outside v-ray. V-ray enables 360 degree rendering in one step of anything you can throw at it. No retouching needed, which is invaluable. I also render 360 degrees panorama of stuff that isn't supposed to look like an on-screen Sketchup render, where realism is required, so, using v-ray its part of my workflow, and I have no desire to change that. In this project I was working now, that contains 3d logo work and needs to look like that (minimal detail), I do need v-ray to render like Sketchup does.

What I DO NEED is:
1st) a configuration for V-ray that saves time and achieves that on-screen look;
2nd) some advice over those big resolutions I was mentioning, what format to save in.
This should not be trivial, because I don't know if PNG or JPG exports in v-ray are able to support such resolutions. Lets consider that a 32768x16384 image needs 1.6 GB of memory, and I saw more than an app unable to cope with such. After all, I've only tried once to render in 16384x8129 and v-ray crashed when trying to save in JPG.

I will make some testing using a blank scene to speed things up, but some feedback will be appreciated.

@krisidious said:

Why don't you just export a jpg from sketchup?

@siramods said:

..to generate a .. spherical panorama

I need to render with a FOV of 360 degrees. The jpg export is bound to the FOV and aspect of the current view of the model.