Just thought I would share this with everyone.
I managed to get a pretty reasonable looking 360degree panorama out of TG2 last night.
The way i made this was to set the horizontal FOV to 10.
Then rendering in 5 degree increments, render out 72 thin vertical strips, which I then stitched together, half overlapping in photoshop.
With the overlaps I used a layer mask with a vignette to fade so that each strip fades into the next one.
There is a little visible banding but not too much for my purposes.
Hope someone finds this useful and any suggestions on how to improve this to make it easier to do or to lose the banding would be cool.
Cheers :)
Using 72 little strips might seem like a good idea at first, but then you're making it easy to introduce artefacts like the vignetting you mentioned.
I'd say use the same relative zoom level, but render in 5-8 blocks. Blend them together with a brush on the layer mask instead of a gradient so you control what blurs through and what keeps its detail. That way, it's less obvious where the renders join.
Good luck.
M.
photoshop does have a photomerge fuction which would have helped you make this... eg merging 2 renders together instead of 72
oggyb - I found that when rendering in larger chunks for less renders I started to get problems with perspective and getting the top and the bottom of the strips to line up properly as well as things near and far away. This effect was minimised by using the small strips.
I will do some more trials and see if I can find a more efficient way.
Thanks :)
King_Tiger_666 - Not the first time I have spent ages doing something only to be told there is a button in photoshop that could have done it for me. LOL.
Photoshop just does so much that you could spend a lifetime figuring out everything that it does. Anyhoo, once I finally get a method locked down, I will write an action so it does all the strip combining, laying out, fading and combining automatically.
And that oggyb is the reason why I don't really want to blend the layers with a brush, but would like to do it with an automatic method as I plan on making lots of these for use as environment spheres in other 3D apps.
Thanks for the input though.
Back to the virtual drawing board.
:)
lol :P i just dont know why u did that
Like I said, to use as an environment sphere in other 3D apps.
???
Why is there like a really easy way that I am missing?
Quote from: Doofus on December 23, 2006, 08:52:54 AM
Like I said, to use as an environment sphere in other 3D apps.
???
Why is there like a really easy way that I am missing?
Ah, I see. So quality isn't your highest priority. Well, I guess if you're on a 360-render production line having a button to do the job makes the whole thing more friendly!
One question. . . do they join up at the ends or hadn't you thought of that yet? ;)
Yes. It joins up seamlessly. I cut the first strip in half and put it to the far end of the image then faded it the same as all the other strips.
Quality would be nice, but it does need to be an efficient reusable method too.
You could always render out 6 times in a cubic fashion with your FOV at 90, arrange the images in Photoshop into a Cross format, then use something like HDR Shop to convert the cross format to a longitudinal format. It's what I did when I made skyboxes in Terragen 0.9.
Quote from: MeltingIce on December 23, 2006, 02:15:25 PM
You could always render out 6 times in a cubic fashion with your FOV at 90, arrange the images in Photoshop into a Cross format, then use something like HDR Shop to convert the cross format to a longitudinal format. It's what I did when I made skyboxes in Terragen 0.9.
I think the point about making a 4-face image was that the edges were too difficult to stitch together successfully.
M.
Yes. You end up with obvious seams. i want seamless.
An automated system for this would be excellent..
much better then the 6 flat plates that is usualy used. I am very intersed in this myself. The main thing however is that you need to be able to run this script or action on a the 32bit open EXR image.. or a HDRI. Those types of images do not support layering. at least not in photoshop. One of my main atractions to TG2 is the possability to create HDR spheres from it of ultra realism to light my animations in 3ds Max. Also if it could be provided at a high enough res.. to be the background as well.. In order for that to work .HDR compatabilty is a must for your script. IMHO.
I am working on a system that may be better then the cube technique used thus far.. basicly instead of 4 sides it has 8. One at 0 one at 45,90 etc.. then you do the same thing at a 45degree canted up/down angle as well and a single image for virticle upwards and virticly downwards. However.. I cannot think of any way thus far of compiling these images into a usefull sphere map. AND it IS allot of rendering..
In conclusion..
Devs... Give us a proper sphere capturing camera.... pleeaaasseee :P And dont just have it capturing 6 flat images at 90deg.. as said before that does create seams.. that become painfully obvios in even slightly compressed animations.
Oh and btw I just put your little Sphere into a the 3DS max Panorama exporter viewer.. where you can look around in 3D and see what its like.. Looks very cool! The one issue with your technique for me is the pinching at the top and bottom. If you could get that cracked... Get it automated.. and make it 32bit compatable.. then you are onto a winner:P. I think you defo need to render a shot virticaly up and down to and some how intergrate that into the rest of the image in order to cure the pinching. Still Very promising!
The one I rendered out before does need the sphere cutting off top and bottom in max and then a cylindrical mapping applying to it as it doesn't render through 180 degrees, but I will be changing that. That is to do with the proportions of the image that I rendered from TG2 I believe. I will try again when I get some more time. Bit busy what with Chrimbo and all.
You are right about the HDRI format being necessary, but at the moment I have no way of doing anything like layering the HDRI slices like I can with the normal images. I agree. Once we get a sphere capturing camera this will be amazing and it will probably be my main use for TG2 as most of what I do is done in Max.
Ideally I would render the terrains and skies in TG2, export terrains as 3ds models, use the renders mapped onto a sphere in max and import the terrain to use for shadow receiving and casting from any other objects that I put into the scene in max.
Not much to ask for eh :)
There are quite a lot of applications out there that do very good automated panorama stitching from an arbitrary number of images. I suggest using one of those, except I'm not sure if any support full 32bit/channel HDR images. Some maybe 16bit/channel, but I don't know beyond that. Of course Photoshop CS2 supports 32bit/channel images and has an ok stitching function so perhaps that could be used?
Some of the available tools:
http://stitcher.realviz.com/
http://webuser.hs-furtwangen.de/~dersch/
http://www.d-vw.com/D_Joiner/index.htm
- Oshyan
I feel your pain doofus! I stitched together many renders in my tg0.9 days! Twas hard and I learned alot from it!
(http://img72.imageshack.us/img72/6439/examplein5.th.jpg) (http://img72.imageshack.us/my.php?image=examplein5.jpg)
(http://img174.imageshack.us/img174/186/finalpreviewburningya8.th.jpg) (http://img174.imageshack.us/my.php?image=finalpreviewburningya8.jpg)
These are not 360 degree renders, but i did turn the camera 10 degrees each render and it the camera was set to a pretty extreme viewing angle. One thing suggestion i would give is to distort the images with a transform tool(in photoshop). This will help with lining everything up. AND to use brushes in the mask instead of gradients. Good work on the panorama by the way, i feel your pain with the hardships that come along with those images!
WOW!! They are some amazing images dude.
I know I could get some better results using brushes for the masks and fading more particular areas, but I want to automate this process so that is not really a realistic proposition. Ultimately I would like to be able to create animated spherical panoramas (preferably HDRI) for the ultimate in environment domes in other 3D apps.
Oshyan - Unfortunately I have Photoshop 7, not CS and none of those apps support HDR images either (at the moment). I tried stitcher previously but didn't find it easy to work with, nor was it possible to automate the process as I can with a photoshop action and batch image processing. As long as I am consistent in my naming conventions with TG2 renders, I can do the final stitching part with a single batch command in photoshop and get passable, but not perfect results.
I think there are some improvements that can be made through TG2 settings however to produce more consistent lighting (possibly through reducing the effect of GI) and some more work on image sizes and FOV angles to get better, more efficient image strips to combine that will display less of the banding I mentioned before which at the moment is my main issue.
Quote from: JavaJones on December 23, 2006, 05:34:01 PM
There are quite a lot of applications out there that do very good automated panorama stitching from an arbitrary number of images. I suggest using one of those, except I'm not sure if any support full 32bit/channel HDR images. Some maybe 16bit/channel, but I don't know beyond that. Of course Photoshop CS2 supports 32bit/channel images and has an ok stitching function so perhaps that could be used?
Some of the available tools:
http://stitcher.realviz.com/
http://webuser.hs-furtwangen.de/~dersch/
http://www.d-vw.com/D_Joiner/index.htm
- Oshyan
None of the panorama stitching programs work with OpenEXR or HDR images, AFAIK.
For HDR images stitching, there is cube2cross (free) by Sean O'Malley http://www2.cs.uh.edu/~somalley/hdri.html - works with 90 degree FOV images (which in older Terragen versions can be done automatically with a script).
There are some programs (free and commercial) for working with OpenEXR and (RGBE) HDR images - there is a large list at http://luminance.londonmet.ac.uk/webhdr/software.shtml - I would add to that list HDRIE http://www.acm.uiuc.edu/siggraph/HDRIE/ for Windows (no OpenEXR support - free).
HDR Shop http://gl.ict.usc.edu/HDRShop/ can take a cross mapping and convert to many others (v.1 is free for non commercial use). HDRIE can do the same conversion.
Helen
Many thanks helentr for all the links and help. I will check them out over the Christmas period and hopefully come up with a good reliable way of making HDR panoramas by New Year. :)
Doofus, great idea to get us all thinking. :P
I have had a bit of luck with the HDRI panoramas.
Unfortunately it makes use of 3DS Max which I know puts it out of reach of a lot of people, but there are just not that many apps that work well with HDR Images.
Anyway, I hope some people find this usefull, and I look forward to hearing what you think, what I have done wrong, what I could do better and what I should have done to start with. Especially any suggestions on how to remove the pinching at the poles when the result is wrapped around a spherical environment.
Cheers :)
One thing I think I missed out from the guide is that you will want to turn off the environment light as the GI for each individual frame will cause variations between your strips.
Doof.. got an idea.. Check your PM
OK. A new method. This one works a bit better than the last one.
It requires for a full 360 degree spherical panorama 26 renders, but for my uses I just want sky, so 17 renders.
Full OpenEXR / HDRI Output.
Accurate distortions at the poles.
And it is automatable to a degree.
It still uses 3DS Max for OpenEXR stitching.
I will put together a tut if anyone is interested?
Check the attached image for the results. :)
Quote from: Doofus on December 28, 2006, 08:45:12 AM
OK. A new method. This one works a bit better than the last one.
It requires for a full 360 degree spherical panorama 26 renders, but for my uses I just want sky, so 17 renders.
Full OpenEXR / HDRI Output.
Accurate distortions at the poles.
And it is automatable to a degree.
It still uses 3DS Max for OpenEXR stitching.
I will put together a tut if anyone is interested?
Check the attached image for the results. :)
Hello to all
I am very interested in such tutorial since I will be involved in production which will utilise HDRI as an enviromental lightning source from TG2 in Max9.
cheers
Michal
I think you guys are making this way more complicated that it needs to be. Just use cube2cross and render out 6 times, then use something like HDRShop to convert it to a longitudinal format or light probe format, depending on which you want.
The attached image was taken from the HDR Shop website as an example of the issues I have with the Cube2Cross method. I have highlited a red dotted line running about a third of the way up from the bottom of the image and it shows where the join is between the bottom of the six images in the cross and the four side views. There is an obvious break which while it may be fine for a lightmap, stands out when you use the panoramas as environment spheres.
What I want is to add more subdivisions than the six to reduce the amount of stretching that any one plane has to perform. I admit that my inital attempt with 72 divisions was overdoing it, but I am now down to 26 for a full 360 degree spherical panorama, basically the same system as a cube but working in 45 degree steps instead of 90. This give you three layers of 8 planes each and one plane at the poles.
The sky I uploaded earlier just uses the top half of this as that is all I actually need (17 images), but essentially the distortion is halved compared to the cube2cross method. If you look for the line where the projections change from being the straight up one, to the top row or the horizontal row of planes you won't find it like I have on the Cube2Cross version.
Goodness i really hope that Matt implements render options like Vue 6 infinite has like 360 Spherical Panoramic rendering. Right now i am doing a project for a company that i work for that requires the creation of HDRI Lighting using cubic maps and or light probes but sense i can not afford Vue 6 Infinite nor do i have the time or computing power to render out 6 individual Terragen 2 renders to stitch let alone afford any stitching software i am in quite a bind here.
Sethren - Quite often, if all you need is a lightmap, much smaller, low res renders will suffice. They usually give perfectly acceptable results in other 3D apps. My problem was that I wanted to use them as environment backdrops as well as lightmaps and then you need higher res renders. If you are using video backdrops or something like that to composite onto, a low res cubic panorama like melting ice suggests will work fine and won't take that long to make. But I agree, I hope panoramic rendering is added to TG2 before too long. It is my main use for the software. Clouds and atmospheres that TG2 produces are simply not realistically achievable in more traditional 3D apps, but a panoramic environment map that can act as ligting rocks my virtual world :)
I would be very interested in a Tut! looks like you have cracked it! ;D
True, i can do lower res. Now if i can get the camera to work right but still i need to stitch using free software if any.
Try autostitch (http://www.cs.ubc.ca/~mbrown/autostitch/autostitch.html)
Nifty! Thank You Kindly. ;D
AFAIK Autostitch only works on jpg files which means you will need varying exposures at step values to be able to create a series of panoramas and then join them together into one HDR image. Seems a shame since TG2 already outputs in OpenEXR format.
Sethren - If you are working in 3DS Max anyway, then you already have the tools required as that will open and save OpenEXR image and the mental ray renderer that ships with max works in 32bit floating if you want it to.
I don't have 3dsmax. JPG only? :-[ Varying exposures which i would assume more renders needed?
Not really. With Photoshop you can adjust the exposure and then save it to jpg. Only 1 render nescesarry. There are commercial products available which use autostich and can handle HDR images.
And also if it is Photoshop CS2 that you are using I believe that you can exposure combine the resulting panoramas into a single HDR file.
The method would be to render the different views from terragen and save as OpenEXR images.
Open the OpenEXR stills in Photoshop and save different exposures for each frame as jpgs
Convert each set of exposures into a separate panorama using Autostitch
Recombine the panoramas using Photoshop into one HDR panorama
A fair bit of user input required when all we really need is a spherical camera for TG2 :)
MeltingIce is absulte right - rendering more than six images is useless. Six correctly taken 90° FOV images can be stitched together - always seamless and free of distortion. The result may be converted to a sphere map, and the result will be seamless, too (if the program works correctly). Essentially there is absolut no difference between six 90° FOV images and the image from a spherical camera besides the angular resolution.
Quote from: bib on December 29, 2006, 08:03:55 AM
Six correctly taken 90° FOV images can be stitched together - always seamless and free of distortion.
I have found this not to be true.. I have many times tried to create proper seamless spherical maps using many different programs. For open and blank areas of colour.. like the sky.. its quite easy to see weird seams along the edges - specialy in animations. The only proper seamless way is a proper spherical camera similar to the one Vray has..
Quote from: DeanoD on December 29, 2006, 08:12:20 AM
Quote from: bib on December 29, 2006, 08:03:55 AM
Six correctly taken 90° FOV images can be stitched together - always seamless and free of distortion.
I have found this not to be true.. I have many times tried to create proper seamless spherical maps using many different programs. For open and blank areas of colour.. like the sky.. its quite easy to see weird seams along the edges - specialy in animations. The only proper seamless way is a proper spherical camera similar to the one Vray has..
The seams (from the cross image to some other 3d projection) come from the interpolation in your stitching program. I had this problem when testing the cube2cross and took me a long time to figure out why. The only solution was to stitch at a larger size and use no interpolation whatsoever in HDRShop or any other program that gives you your spherical or latitude/longitude projection. The seams will disappear.
Helen
It is theoretical true. If both - the program rendering the six images and the program converting the images to a sphere map - work correctly the result is seamless.
Using a spherical camera means projecting the scene onto a sphere.
Taking six 90° FOV images means projecting the scene onto a cube.
Both methods capture exactly the same part of the scene - everything visible from the location of the camera in every direction.
The only difference is the angular resolution. For the six 90° FOV images the angular resolution increases from the center of each image towards the edges of the cube, while the angular resolution of a sphere map is constant.
In order to get the sphere map, the only things to do are projecting the cube onto a sphere - that is really easy - and resampling the projected image at a constant angular resolution - that could introduce artefacts if not done proper.
--EDIT--
Helen replyed while writing this post, saying almost the same. But I want to add, that the conversion can't be performed without resampling or interpolation. You have to be aware of the correct processing over image borders.
bib - What program should I use to correctly convert without the seams 6 x OpenEXR images into 1 seamless HDR panorama?
A simple solution is to use POV-Ray. Create a file like
camera
{
spherical
location <0, 0, 0>
}
box
{
<0, 0, 0>, <1, 1, 1>
texture { pigment { image_map { bmp "w4.bmp" } } finish { ambient 1.0 } }
translate <-0.5, -0.5, -1.5> rotate <0, 0, 0>
}
box
{
<0, 0, 0>, <1, 1, 1>
texture { pigment { image_map { bmp "w3.bmp" } } finish { ambient 1.0 } }
translate <-0.5, -0.5, -1.5> rotate <0, 90, 0>
}
box
{
<0, 0, 0>, <1, 1, 1>
texture { pigment { image_map { bmp "w2.bmp" } } finish { ambient 1.0 } }
translate <-0.5, -0.5, -1.5> rotate <0, 180, 0>
}
box
{
<0, 0, 0>, <1, 1, 1>
texture { pigment { image_map { bmp "w1.bmp" } } finish { ambient 1.0 } }
translate <-0.5, -0.5, -1.5> rotate <0, 270, 0>
}
box
{
<0, 0, 0>, <1, 1, 1>
texture { pigment { image_map { bmp "w5.bmp" } } finish { ambient 1.0 } }
translate <-0.5, -0.5, -1.5> rotate < 90, 90, 0>
}
box
{
<0, 0, 0>, <1, 1, 1>
texture { pigment { image_map { bmp "w0.bmp" } } finish { ambient 1.0 } }
translate <-0.5, -0.5, -1.5> rotate <270, 90, 0>
}
The images w1, w2, w3 and w4 are the "normal" views, w5 is the view up and w0 down. It may be that the images must be reordered or the rotation changed, depending on how the images have been generated.
The current beta has HDRI-support, just change the filetype to hdr.
That is basically what I have done but in 3DS max and instead of using a spherical camera I have used Max's built in Panorama exporter which essentially takes the six images and performs its own resampling to convert them into a spherical map. But I have tried it with using six images arranged in box formation with the camera in the centre and I get the same result as the one I highlighted on the HDR Shop website image before. The top and the bottom images are spread over such a large area that it becomes obvious where the joins are especially as DeanoD says during animation.
The difference with what I am doing now is that I am working in increments of 45 degrees so instead of 4 sides my box now has eight meaning the top and bottom images do not have to make up over half of the final image between them. (See the attached image)
Also render time wise it may not be as crazy as it sounds either.
If you use double size renders at 90 degrees than you do at 45 degrees to account for the fact that each image is covering a much larger area of the final panorama then the final difference in amount of rendering is actually quite small.
6 x 1024 x 1024 = 6291456 pixels of rendering
26 x 512 x 512 = 6815744 pixels of rendering
Difference = 524288 = 724 x 724 basically meaning you actuall only render about 3/4 of an image more than with the 6 image method, but the result is way nicer I think.
Also I am only after skies so ...
5 x 1024 x 1024 = 5242880 px
17 x 512 x 512 = 4456448 px
Difference = 786432 px less = 886 x 886 px image less rendering.
The image with the buildings seems to be made of photos (it's not reendered, is it?) and badly stitched - the street doesn't fit at all and is very blury. I don't know why, but I think not because of the conversion to a sphere map.
In general it's somewhat a problem with resolution, distortion and the distance to the objects. At the poles the spatial resolution is much higher than elsewhere assuming all objects have the same distance to the camera. In the image with the buildings this is even worse, because the street is also much closer to the camera. So you need to generate a huge cube map to reduce scaling near the poles, but you will never get rid of it exactly at the poles.
Using more images - 8 at 45° or more - aproximates a cylindrical (or spherical, if you do it also up- and downwards) projection and reduces the difference in the angular resolution. But you should get similar result with simply rendering at a higher resolution.
And it may be a problem with the program you are using the sphere map with - this program should, for example, use a complete line from the image to color a pole.
If you don't care about floor and sky consider using a cylindrical projection.
Can you post six 90° images you want to combine?
I believe the buildings are photos. That image was taken from the HDRShop website as a bad example of what I mean. But the same problem is true for renders too. The reason for the blurryness I think though is that the bottom and the top images from the six that make up the box have to make up a large proportion of the final image and to do that they must either be rendered at really high resolution or spread out a long way. Like you say, you will never get rid of it entirely at the poles, but by using more divisions you can reduce the effect.
Using more subdivisions reduces the required resolution and like I said before it is actually worth doing more renders with at a lower resolution and putting them together than doing fewer larger renders, especially for me as I just want skies.
Also as I said when I began this thread, one of the main things I want is to limit the required amount of user interaction as I want to have lots of frames of this as I eventually want an HDRI animated sky dome. This is not just a one off image for me.
This way I can set terragen to render out all the frames (once I get the animated version), then simply open up the 3DS max file I have created (which will automatically load all the files assuming the correct naming conventions have been stuck to), and click the render to panorama button. Voila - One HDRI Panorama frame of animation. - Rinse and repeat.
"Using more images - 8 at 45° or more - aproximates a cylindrical (or spherical, if you do it also up- and downwards) projection and reduces the difference in the angular resolution. But you should get similar result with simply rendering at a higher resolution."
I am doing it up and down too to make it spherical, and it is more efficient to render more smaller images rather than the fewer larger larger ones.
Here:
http://respam.terratalk.de/ReSPaM-Install.exe
you can find a program which does the job for you, if you just want to build panoramas out of BMPs (that's the only filetype that can be used), not HDRIs.
In your favorite 3D program set up your camera with a FOV of 90° and take six pictures: up, down, back, front, left and right, all exactly 90°.
The program is in german, so for those who don't know:
"Himmel" means sky, "Links" means left, "Rechts" means right, "Vorne" means forward, "Boden" means bottom and "Hinten" means back.
"Neu anfangen" means start from scratch and "Panorama machen" means make panorama.
"...drehen" means turn.
Believe me you won't see any seams. I tried it with the old Terragen-version and it worked perfect.
In the end you will have a large file with a strange ending. Just rename it to xxx.BMP and this will be your pano.
In an app like 3ds Max map this image spherically onto a sphere.
Sorry, map it cylindrically!! :'(
Quote from: MeltingIce on December 23, 2006, 02:15:25 PM
You could always render out 6 times in a cubic fashion with your FOV at 90, arrange the images in Photoshop into a Cross format, then use something like HDR Shop to convert the cross format to a longitudinal format. It's what I did when I made skyboxes in Terragen 0.9.
In what way do i have to put them in the cross format?
Is it like █
█ █ █ █
█
or a different arrangement?
Quote from: U-Type on December 30, 2006, 02:19:10 PM
In what way do i have to put them in the cross format?
Is it like █
█ █ █ █
█
or a different arrangement?
The usual arrangement is:
UP
LEFT FRONT RIGHT
DOWN
BACK (rotated 180 degrees)
Cube2cross does this automatically, if you give the right file names (and the images are square)
Helen
I am now using a wrap around lens shader in mental ray which essentially uses cylindrical mapping to render out the final panorama. This replaces the built in max panorama exporter and gives far superior results both in the reduction of noticeable seams and in the retention of dynamic range data of the original OpenEXR TG2 files.
EDIT: And another thing. Added a spherify modifier to the octagony geometry, set at 100% which basically turns it into a perfect sphere and does all the image map distortion required. The lens effect on the Mental Ray camera just unwraps it and it looks even better.
Getting real close I think to being as good as if you had used a spherical camera right from TG2.
Just my opinion of course. :)
I tried it with POV-Ray - a cube with 1024x1024 pixel textures (24 bpp, generated with TG 0.9) on each face, rendered a sphere map with 4000x4000 pixel and found no seams at all. The only noticable artefacts were introduced because of the strong distortion at the poles - usualy invisible color gradients become visible due to scaling some pixels up by a factor of 10 or so. But of course this vanishes by mapping the image onto a sphere again. A possible work around for hdr images would be scaling them up by a factor as huge as possible (thinking of memory limitations) and rendering the sphere map at the desired resolution. Rescaling the images will soften the gradients and make them less visible in the sphere map. But this works only for hdr images, because 256 values per channel are not enough to smoothen the gradients over larger areas. And for scenes with architectural features scaling may introduce bluriness.
p.s.
And there will be no noticable difference when viewing the image on the screen due to the limitation of the display or video adapter.
Can I get a look at the resulting panorama please bib.
I am happy with the way I am going, but if there is truly an easier way that works then I will take it. I'm not doing this to be obtuse, I genuinely find that the differences in the top and bottom images of a cube and the four side images with regards to how much they need to be distorted to make a panorama always shows up come animated rendering.
Also I have never used POV-Ray. I am going looking for a download now, but if you could send me your POV-Ray file too I would be very grateful. Would save me some time figuring out how to work it properly.
Cheers.
That's not that easy ... I've got only a 56k modem and the file is about 45 MB. Compressing it definitly generates seams at the borders. Just get POV-Ray and use the file I already posted.
And I was able to produce some seams with POV-Ray. I thought about scaling the images a view posts ago. I tried that with POV-Ray - adding "interpolate 2" to each image_map will cause POV-Ray to use bilinear interpolation and introduce seams at each edge. I think I know why this happens in POV-Ray, but I am not sure if this applys to other programs, too. Just try it with and without interpolation. I would like to hear about your result and would like to know, if the seams with interpolation are similar to the seams from other programs.
Hi,
Quote from: Sethren on December 28, 2006, 05:43:58 PM
Goodness i really hope that Matt implements render options like Vue 6 infinite has like 360 Spherical Panoramic rendering. Right now i am doing a project for a company that i work for that requires the creation of HDRI Lighting using cubic maps and or light probes but sense i can not afford Vue 6 Infinite nor do i have the time or computing power to render out 6 individual Terragen 2 renders
I would think that rendering a 360 degree spherical panorama would involve rendering more or less as much as it would to render 6 individual faces of a cube, and therefore take a similar amount of time.
Regards,
Jo
Quote from: jo on January 11, 2007, 06:15:52 PM
I would think that rendering a 360 degree spherical panorama would involve rendering more or less as much as it would to render 6 individual faces of a cube, and therefore take a similar amount of time.
Probably even longer to render a single frame than six, given the way most decent renderers optimise. Think about how it's been commented on the differences in cropped renders and full frame renders. No matter what, 360 degrees of coverage is 360 degrees of coverage, whether you split into six or just one.
Quote from: jo on January 11, 2007, 06:15:52 PM
Hi,
I would think that rendering a 360 degree spherical panorama would involve rendering more or less as much as it would to render 6 individual faces of a cube, and therefore take a similar amount of time.
Regards,
Jo
Sorry to dig up a slightly older thread, but I'm struggling with this at the moment. I'm trying to get Terragen to render faces for an environment cube, and while it's easy enough to set up the camera and get 6 images with 90 degree FOV, they don't actually match correctly. The geometry seems fine, the problem is that the colour doesn't match across the seams of the image. Either some part of the rendering is view dependent, or else there is some tone-mapping or other image adjustment happening behind the scenes. This is clearly visible in output images in both EXR and BMP formats. As I actually want a cube, I really don't want to have to take many more images and play with stitching software - the best possible result should come from directly rendering 6 images. This worked fine with the older Terragen...
Anyone else seen this and/or found a way around it?
Hi _Sin,
I am just guessing due to other threads. This could be a GI-matter. Maybe you should use instead of GI the lighting clips supplied by Oshyan (Shared Files, the Topmost Thread).
Regards,
Volker Harun
Quote from: Volker Harun on February 15, 2007, 08:04:31 AM
Hi _Sin,
I am just guessing due to other threads. This could be a GI-matter. Maybe you should use instead of GI the lighting clips supplied by Oshyan (Shared Files, the Topmost Thread).
Regards,
Volker Harun
Yup, that seems to be the problem! My bad for not checking other threads more thoroughly - my initial search didn't turn anything up, but I see the other postings about this now...
Thanks!
I hadn't seen this thread before.. but there seemed to be a lot of confusion and overcomplication of some of the stitching issues. My background is in photography and creating spherical panoramas, so I've made a few in my time ;). http://www.communitywalk.com/map/109 (http://www.communitywalk.com/map/109)
The simplest method (mentioned by a couple of people already), using completely free software is to use CubeToCross and the free version of HDRShop. Creating 6 cube faces of 90° fov means that there is no overlap of the images so there should be no blending of images set in any application. Blending is only required with overlapping photographs. Even if your rendererd images overlapped there should still be no need for blending.
Here is a test equirectangular (spherical) HDR image I produced in 2004 with TG0.9 using this software: http://www.path.unimelb.edu.au/~bernardk/demo/sunset8c_025.hdr (http://www.path.unimelb.edu.au/~bernardk/demo/sunset8c_025.hdr) (2.6Mb)
I've also used Panorama Tools to stitch animations on the fly for non-HDR images. Here's a small movie from TG0.9 using a cylindrical lens with a 180° fov. http://www.path.unimelb.edu.au/~bernardk/demo/pano_test.avi (http://www.path.unimelb.edu.au/~bernardk/demo/pano_test.avi) (802kb)
The only other potential problem I can see people having is if they rotate the camera in the preview window rather than editing the camera's settings. This will change the position of the camera and cause parallax errors. I haven't created a spherical panorama in TG2 yet, but I certainly will be in the near future.
Sorry if I missed it, but is there a free program I can use to convert a cross-type .exr image into a longitudinal one?
I'm trying to make a short for school/festivals and my budget is toast now, so I can't afford a commercial license even though that's kind of what I need. It'd be really nice to be able to get my tg2 renders into maya to use for a hdr light dome. Note: I'm on windows, and don't know how to do anything in linux
HDRShop v1 is free and does a good job. http://gl.ict.usc.edu/HDRShop/ (http://gl.ict.usc.edu/HDRShop/)... assuming you meet licencing requirements
I am experimenting with using CubeMapGen for stitching my cube faces together. It is a free tool from AMD/ATI. It supports HDR image formats, can flip/rotate cube faces inside the app, and can even do a variety of different types of filtering methods across cube face edges. Only drawback is that it only exports cube maps... not spherical environment maps... but they are essentially the same thing.
http://ati.amd.com/developer/cubemapgen/index.html
Ben,
been reading up on this thread, mainly because TG2 CAN NOT handle heavy model import.
Your approach seems the most logical from everything I've read here and else where.
Just curious if you could throw me any tips you might have on doing this with TG2.
As your website page is based on 9X.
I guess the big question I'd have is this: Say I had Ogre's highway node running and wanted a skybox.
In doing a render like the one here, what scale renderes would you do 1024x1024 for the 6 boxes?
And how far off the ground would you set the camera for that?
Do I have to make tests, to see where the bottom box tucks under?
If I had to make a guess, well I wouldn't. ;) Put a rock before the edge?
Maybe something simple I'm missing about that.. point.
Make a right at the bear that looks like a rock? :) I don't know..
Ok, no chops about the blower, as i just started playing with it, I know the oval has to go.
Seems a bit easier with 9x as there was a script somewhere, ah but that didn't include the cross.
I'm not entirely sure I understand all of the questions.
The process is pretty much the same as for TG 0.9.
If you have the animation version you can set up keyframes for each camera angle, but be sure to set the motion blur to 0. Set the output filetype to exr and render away.
If you're rendering an animation, you'd need 6 separate TGD files, 1 for each cube face so that you could use motion blur.
Not sure what you mean about "what scale renders..." I calculate my render sizes based on a final equirectangular image, which is simply 1/4 of the width of the final image. e.g. for a 4000 x 2000 equirectangular image I'd make cube faces of 1000 x 1000 pixels. The remapping process involves some heavy interpolation so you won't notice much difference with higher resolutions.
How far off the groud? - Well if you're talking about inserting a render of an object into the panorama then you'd need to match the camer positions between renders.
PS. I've been dusting off my pano gear and software...
PTGui Pro supports HDR input and output. A bit pricey for some, but it provides a much simpler workflow and some added flexibility in being able to extract different projections and camera angles.
http://www.ptgui.com/features.html (http://www.ptgui.com/features.html)
I've been using Autopano Pro for jobs. Not cheap, but much cheaper than Stitcher, and handles OpenEXR for both input and output.
http://www.autopano.net/
Thanks Ben. JimB that software looks pretty nice, with its auto features.
Quote from: Mandrake on October 30, 2008, 06:48:47 PM
...
been reading up on this thread, mainly because TG2 CAN NOT handle heavy model import.
...
Really, what do you mean by heavy model import? I'm regularly using models of 100mb, 200mb even 300mb both singularly and in populations. Terragen dose seem to have a habit of crashing when its dealing with multiple reflective surfaces especially if they're interacting with each other but thats not due to the size or complexity of the model but rather the number of reflections of reflections it has to calculate (I think).
Richard
Probably exactly what you think I mean, ;) download the above car at Ashundar and your lucky if you get a couple of grass pops. Of course with the system you list below on 64bit os will have better results, unfortunately I don't have that up and running yet.
Well I got one quick panorama test done with ogres road, what's up with that displacement ogre?
Did the pano and ran it through the hdrishop and projected it to the sphere around the car, and it's light is luminescence from the tg2 render material settings. Seams did not line up and there's some white but I guess it worked somewhat..
Try this: http://forums.planetside.co.uk/index.php?topic=4211.msg44441#msg44441 (http://forums.planetside.co.uk/index.php?topic=4211.msg44441#msg44441)
and source to do it in a UI is pointed to in a message two messages above this one.