I've been doing a bunch of 360 panorama shots for a skydome in UDK. But all I'm getting is this:
(http://img535.imageshack.us/img535/7892/smallxz.jpg)
As you can tell. The process is fine, explained below, but the rendering is not. What's up with the lighting changing on a 90 degree angle switch? Please don't tell me Terragen simulates the light reflecting off of the virtual camera lens....
Either way. this is something that's been discussed before, but after hours of searching for solutions, I got nothing. So please, I need help with this, it's a time urgent kind of thing.
And yes. I've tried switching GI off. That's with it on. But the effect is exactly the same, except everything turned green. But that's just atmospherics and lighting, I can deal with that.
So I'm basically using the 6 shot/slap onto cube/bake to sphere/save image method to make a 360 degree panorama. Each angle change is 90 degrees, and the FOV is 90.
For those a little confused. I'm using this tutorial here as a base: http://lightfeather.de/lf/documentation/skydometutorial/Skydome.html
But because the actual method is faulty, I eventually figured out that reflecting the normals of the outer sphere fixes the problem of the render not baking anything.
So far, this is the only process that works to get a panoramic 360 image fit for a skydome in UDK. Image stitching just ends up with the stitching program crapping itself and wondering what it's doing. And manually doing all the points still leads to the image program crapping itself. I've tried Photoshop CS5.1, PTGUI, and Hugin. All of them couldn't figure out who to do with the pictures, mostly because there's two images for the floor and ceiling shots I think.
And before you mention it, yes, the images for the stitching programs were shot using 110 degrees for the Horizontal FOV.
Bla bla. Long story short. I've only got one method that works, if anyone could tell me another way, I'd be happy to hear it.
Although the process I'm using right now works quite nicely, once I figured out how it works...
Have you checked this tutorial? http://forums.planetside.co.uk/index.php?topic=11608.0 It's usually a good idea to render overlapping images to address this issue
Please let us know how this goes. I'm always on the verge of trying this and never quite get around to it. But, your images look brilliant and this could be a great time to learn, if you will keep us in your loop of discovery.
@Freelancah: Yup. That was the first one I tried. PTGui runs and hides in a corner somewhere on the computer. I just get this screwed up mishmash. It can barely connect the dots, and doesn't actually work when I do it manually. And I tested with a set of images that had very easy to spot and use marking points. Both manual and automatic.
It just doesn't work.
And yes, overlapping images were used.
@Calico: Will do! I'll be doing an updated tutorial once I get the kinks worked out. I've spent the last week or so with a coupla days of intensive rendering and problem solving just getting this far. It takes a while to do these things.
Hmm that is strange indeed. I've rendered tens of skyboxes with similar method and have had no issues yet
Well. If you can get it to work, let me know and how I can fix it:
I've uploaded the files here:
http://www.mediafire.com/?vxltuejl1li519w
Obviously I rendered in exr, but they're rather large. So these are jpgs.
They're also pretty much the renders terragen spits out.
I'm using FloatingPoint's camera rig, so...
I've had exactly the same. The lower the sun the greater the disparity, I've found, probably due to the huge differences in light levels from one side to the other. Overlap your tiles (I usually go 110 degrees FOV) and increase resolution appropriately. Try increasing GI Prepass Padding even up to 1 if you can afford the render times, maybe test it out at low rez. You could also increase GI quality/sampling settings if you haven't already. As a safeguard (and possibly unnecessary), I always switch off 'Soft clip' and 'Compensate soft clip', which IIRC only affects LDR, but at least you can preview more accurately what the HDR render will look like - the differences in atmospheric glow effects can be quite astounding. Don't forget PTGUI lets you tweak the exposure levels for each tile, which can at least help some of these issues, and clicking on the Auto-exposure doesn't have the same result each click, so you can keep clicking until you're getting closer to an even balance.
Already done most of what you've said. Applied renders with or without GI. My machine can turn things up a bit.
As I said in my first post. I've already used overlapping tiles. The uploaded zip has overlapping tiles. I'll try some of the others.
PTGUI doesn't recognise the links between the renders at all. Or barely. See for yourself.
Can you change the file to the EXR ones?
*Sigh.* Fine.
.exr upload. Enjoy.
http://www.mediafire.com/?wzz27rj322hucee
@JimB. tried your suggestions, didn't work. Seemed to have lessened some of it, but not enough to stop the obvious lines, or allow Hugin (Very much like PTGUI) to do it's job properly.
Quote from: Draigr on November 03, 2011, 10:16:06 AM
PTGUI doesn't recognise the links between the renders at all. Or barely. See for yourself.
Don't bother with auto-tiling, just input the camera setting for each tile - enter them manually. To be honest, the sooner TG2 has a panoramic camera for rendering with, the better.
Could you not cheat a little more , Draigr ?
Instead of only 4 side renders use more to have a smooth dissolve from the sun.
And the renders do not have to be so big horizontally. You can use more renders-steps with narrow renders too make render time faster .
Kind of an animation render...In fact it is an animation sequence of course like the one you use but with more frames.
Stitching would be easier too for the panorama softwares with more similar frames to use .
I tried a little bit with Microsoft Ice and it looked good.
You can use videos too as you know for this probably.
It is the same principle. But i haven't used this feature yet .
How you will get the last step of the upper and lower part i am not sure.
On paper it looks doable but if it is any use to you i don't know.
A basic test with 41 frames. Curious if this would work with your scene .
Edit: You could then maybe use the resulting image by cropping it to 4 side views in post and then try to comp it with the upper and lower side.
But yes it would be good if this was automatic in TG2 :)
If it's not GI, then I wonder if it is the Acceleration Cache in the cloud layer(s). Try setting those to 'None'.
I've recently had to render out 30 skyboxes (6 sides each). Really I had no time to figure out the GI problem at the seams, so I created a fill light setup that looked great for the scene. If you ask me this is the way to go until maybe one day TG2 can solve that problem for you. Until then, no GI for skyboxes, use fill lights instead. Granted, it takes some time and test renders to find the ideal fill lights, but it's much faster than trying to solve this GI problem.
This remark just because you mentioned switching off GI earlier: when you decide to switch off GI, then you need to replace it with something else, otherwise all shadows will be black. Use a fill light setup. You'll find one in the file sharing sections or through search.
Regards,
Frank
@Matt: Cloud's acceleration is already at none. There were those weird blocking issues when I was working on the scene ages ago. So the clouds have always had no acceleration.
@FrankB: I'm giving your suggestion a go. It's making a scene not nearly as spectacular as I'm after, because of all the lighting fudging I'm having to do. But it does seem to be working. The fill lights don't alleviate the contrast issues straight off the bat, but they do seem to be helping me fiddle with lighting now that GI is off.
@Kadri: It's a sound idea, but it ruins my method of doing a spherical imagemap. The stitching programs get hitched up on the ceiling and floor images, which I need to properly finish off the skydome. A straight panorama stitch of the horizontal shots works fine. Although the contrast/HDR issues are still abundant.
@General:
I've perfected the blender process. At most, all I need to do right now is reimport images that have been rendered over by Terragen and hit bake on the sphere. Which means that doesn't take long to find out how the panorama rendered out. Now it's just fixing the Terragen issues. The wierd contrast still appears whenever there's any sort of significant interaction with the sun. There's a little bit of a line between each image even at a 90 degree sun angle and very low intensity, like below 1. The effect starts to become much more noticeable as the sun arcs down. What's worse is that it's only on one or two shots, the rest render out fine with each other.
I might be able to alleviate the issue by having the two opposing sun lamps (already tested with one, seems to exacerbate things sometimes) angled to hit the camera side on rather than directly. But that's for another day. It's almost 4:30 AM and I still haven't solved it to my satisfaction.
I'd like to figure out what's causing this. If you're still having edge discrepancies when there is no GI and cloud acceleration caches are all set to None, could you please send us a TGD so we can investigate? You can email support at planetside.co.uk
Matt
Is it possible it's partially a problem in the stitch process? Have you compared the original image edges in a supported image editor that can handle EXRs? The actual tone curve - not just GI or lighting in general - looks different to me in some of the areas of the examples you posted. I don't know what your final output format is, but if there is any tone mapping from HDR to LDR going on, it could be treating each image differently. I imagine you've thought of that, but just in case...
- Oshyan
@Matt: Thanks for the interest. I've sent the file off. So support should get it soon.
@Oshyan: I'm current rendering to BMP for precisely that reason. And because I can't preview images in .exr. All the programs I'm using at the moment treat the .exr files differently, which is a headache I don't really want to have to solve at the moment in addition to solving the issues with Terragen's lighting and rendering system.
I've been getting closer and farther away all the time.
Hey Frank, how'd you go about setting up the lighting so that it eliminated the seams without ruining your scene?
This one is about as close to seamless as I can get:
(http://img254.imageshack.us/img254/9681/test3l.jpg)
Some recent fiddling got me this which I'm not entirely sure about, but I do like how the clouds are turning out.
(http://img854.imageshack.us/img854/3061/test4b.jpg)
Quote from: Draigr on November 07, 2011, 09:46:24 AM
I've been getting closer and farther away all the time.
Hey Frank, how'd you go about setting up the lighting so that it eliminated the seams without ruining your scene?
I have no seams. I don't render any overlap. I render with a 90° horizontal FOV and turn the camera in 90° increments. This, so far, didn't get me any seams. Also, just to be sure, I put all GI values to 0, even though I have already deleted the enviro light node.
I don't know if that helps you, but I hope it does :)
Cheers,
Frank
Thanks Frank. Already using 90 degree angles since this is a cubemap to sphere projection of sorts process.
Back again. Tried everything suggested so far. The following image was rendered using 6 90 degree shots, with a field of view of 90 degrees and no GI, the environment light was deleted. There is one sunlight at an elevation of 15 degrees, with a heading of 215, which is where I calculated the corner of the camera would be. (consider FOV and turning increments.)
Each of the fill lights are at 45 degrees in elevation and at the 45, 125 and 315 positions respectively.
The cloud optimisation is set to none. There is only one enabled cloud in the scene.
This is what I get:
(http://img832.imageshack.us/img832/9359/test5yd.jpg)
Can't you post a file? Without it I think we can't be of any help.
Cheers,
Martin
Sure. Here you go.
Thanks, will have a look at it once I'm back home from work...
I'm rendering this and am a bit surprised about how slow it is, as well as the weird rendersettings of detail 0.19 and AA1 with ray traced rendered atmosphere.
So I think we're dealing here with a lack of detail issue here rather than something mysterious.
To be continued...
edit: strange circular artefacts are gone after some simple adjustments...still a bit of seams though, but already solved that partially...to be continued... ;)
Render setting are low to speed up iterations. If I did a full render at 4 AA and .65 detail I'd literally be there all night. I think it takes about 12 hours, most likely more now. That's for 1024 by 1024. Clouds aren't affected by detail settings and the ground/water isn't important in the scene.
Spherical artefacts are caused by the spherical mapping.
Looking forward to seeing what you come up with.
Quote from: Draigr on November 08, 2011, 06:52:18 PM
Render setting are low to speed up iterations. If I did a full render at 4 AA and .65 detail I'd literally be there all night. I think it takes about 12 hours, most likely more now. That's for 1024 by 1024. Clouds aren't affected by detail settings and the ground/water isn't important in the scene.
Spherical artefacts are caused by the spherical mapping.
Looking forward to seeing what you come up with.
Spherical mapping of what?
I opened your file, got rid of the population, all the terrain and shaders, since you only see water.
Despite the water not being important, visually, it's definitely a source of the seams/artefacts you're seeing.
To fix this I increased the detail from 0.19, which is absolutely too low to expect any kind of correlation between the 6 sides of the cube, to 0.6.
I then increased AA from 1 to 4. AA1 is really really really too low. Even if you render with RTA and have tons of samples in your clouds. It just won't work for the aforementioned reason that the quality eventually is so low that you can't expect any correlation between the 6 sides of your cube.
To speed up rendertimes I reduced the cloud quality from 1 to 0.5.
A 400x400 frame takes roughly 4 minutes for me.
Despite these improvements there's still a visibile seam at the top and bottom of the image which I wasn't able to completely remove yet.
I used ray detail region padding up to 2 to make adjacent cube-faces account for shadows as well, helped a little, but not enough.
All in all I think the difficulty here lies in A)the dark atmosphere and bright lighting B) the dense and really thick clouds.
Even without GI there's too much difference in lighting conditions between each cube face.
A work-around would be to use more sensible settings for everything.
You have huge thick clouds which take very long to render, but you could also make smaller clouds which are less thick and blend them less out in the distance.
They will visually appear at the same position, but will render much faster.
If you don't touch things too much it shouldn't be too hard to do, as FrankB already pointed out.
Eventually you could post-work the skybox to get what you like.
All the problems with these skyboxes I've seen so far is with files where its settings have strongly deviated from the sensible default settings.
Another workaround is a previously made suggestion to change the FOV and render a lot more faces (with overlap). I believe it was Kadri who's suggesting that.
This way you should eventually be able to cover for the big differences in lighting everywhere.
Well, I hope things are a bit more clear now.
Cheers,
Martin
I'm making the skydome image by projecting a cube with the rendered images mapped to it onto a reflective sphere.
Ok. Thanks for all that Martin. I do have a few questions though. You refer to things I know very little about:
1. What do you mean by "blend them less out in the distance."? In terms of terragen, I have no idea what that means or how to implement it.
2. If I like how clouds are turning out, changing something like the cloud depth/cloud density will completely change the strata. Unlike you, I still don't know a lot about hand building my own clouds in Terragen. I simply having had the time or years to learn all of that. Which means I'm stuck with procedural techniques which take days before I achieve something I'm after. Even if I am quite good at manipulating them in the direction I'm after.
3. You talk about settings outside the norm. What exactly is the norm?
I'm testing your suggestions out now. We'll see what happens. I've scaled everything right back, which means I don't like the clouds as much anymore, but it looks promising.
Quote from: Draigr on November 09, 2011, 08:02:48 AM
3. You talk about settings outside the norm. What exactly is the norm?
see:http://forums.planetside.co.uk/index.php?topic=6442.0
Quote from: Draigr on November 09, 2011, 08:02:48 AM
I'm making the skydome image by projecting a cube with the rendered images mapped to it onto a reflective sphere.
Ok. Thanks for all that Martin. I do have a few questions though. You refer to things I know very little about:
1. What do you mean by "blend them less out in the distance."? In terms of terragen, I have no idea what that means or how to implement it.
2. If I like how clouds are turning out, changing something like the cloud depth/cloud density will completely change the strata. Unlike you, I still don't know a lot about hand building my own clouds in Terragen. I simply having had the time or years to learn all of that. Which means I'm stuck with procedural techniques which take days before I achieve something I'm after. Even if I am quite good at manipulating them in the direction I'm after.
3. You talk about settings outside the norm. What exactly is the norm?
I'm testing your suggestions out now. We'll see what happens. I've scaled everything right back, which means I don't like the clouds as much anymore, but it looks promising.
Hi, I will try to answer/explain:
1) The cumulus layer you have is blended with a distance shader. What I meant to say is to make less thicker and smaller clouds and make them appear closer to the camera. To do this you must tweak that distance shader.
Currently it is set to first 3000m from camera no clouds (nearest colour = black, distance = 3000m) nothing, then from 3000 to 10000m they slowly fade in.
So if you change 3000 to 600 and 10000 to 2000 you'll have a similar falloff, but much closer to the camera.
Thick clouds would obscure the camera, but with thinner clouds at a bit higher altitude will create the same look and a lot cheaper to render.
2) I realize that. It's the difficulty with TG2. You need to start off in the right direction, because if you need to change something quite drastically (like changes cloud depth in this case) the result itself will drastically change as well.
To circumvent these kind of troubles you actually need to think ahead a little and know what problems you might run into and keep that in mind while creating the scene. This is mostly an experience thing, but also a forum-lurking thing. I barely create skyboxes myself, but have read so much (troubles) about it here that I know what to do and especially what NOT to do whenever I would need to make them.
Believe me, I'm not good at hand building clouds at all. I know which strings to pull a bit to get certain clouds, but most of the work is planning and knowledge/experience of the settings and/or the renderer. All to make it as easy as possible and without having to render for too long.
Not an answer which will really help you, but just to show that there really isn't much magic that I'm or others are doing.
3) What I meant to say is that it takes quite some big adjustments to get from the default atmosphere/clouds to the actual result we're seeing now.
By default the atmosphere and clouds don't contain so much contrast because of dense colours (atmo) or thick/dense clouds.
Naturally there isn't so much dynamics anyway, which isn't a real argument, but definitely is a reason why it is so difficult for TG2 to render these skyboxes.
I just saw Kevin posted a link to the render settings recommendations thread which definitely is a must-read.
Also this thread is obligatory for everyone touching TG2:
http://forums.planetside.co.uk/index.php?topic=8300.0 (http://forums.planetside.co.uk/index.php?topic=8300.0)
I'd like to encourage you to continue, but perhaps take a step back with something simpler in terms of lighting and atmosphere dynamics.
Get that to work with the aforementioned tips/tricks everybody suggested and develop further from there. We're to help if necessary.
Cheers,
Martin
Thanks a lot for that Martin. I appreciate the time and trouble.
I've already been through that thread, I use it regularly in most of my renders, although this one got a bit out of hand, admittedly. Once this term is finished I'm definitely looking into doing a full tutorial. There's not a lot out there, and Terragen seems to go out of its way to make our lives hard. No offense Matt! This program is amazing! But it really, really, has it's flaws sometimes :-[.
Anyways, delving into things again...
Ladies and gentlemen! I am proud to present a nearly postwork ready 4K skybox! Booyah!
(http://img443.imageshack.us/img443/1389/4kskybox.jpg)
Now, obviously there are two tiny seams on the top and the bottom, most likely due to the process I used to create the skybox, but that's fine, they're easy to fix in photoshop. It also obviously not done yet, and while I'm still a noob at Terragen, I know my stuff with photoshop. This will be a purttty baby when I done with it.
So how'd I do it?
got rid of the scene, restarted in another one I made a while ago. Tweaked lighting and atmospherics, set up the camera and started rendering. There's a bit more to it then that, but that's essentially it. I just got sick of the old scene and how badly it was responding to my tweaks, so I quit and restarted. I don't stick with stuff that clearly is not working. Still, the other file makes a good case study of what not to do and the incremental saves are all there. I'll be going back to them later for the tutorial.
I'll put together a tutorial once my current university term is over. I've got a game project to finish, and that's gonna take precedence before I take a crack at what will be the largest and most thorough skybox creation tutorial on the web. Plus, I'll have to make a scene I can walk readers through and so I can duplicate my success reliably, of course. I hate tutorials that take you through it, but fail ultimately to actually create a working product.
Enjoy. Thanks for being so helpful guys, I couldn't have done it without you.
I think you done the right thing here, Draigr. I had been looking at your scene too to try and troubleshoot the problems you were finding, I couldn't work out what was wrong with your file at all, it shouldn't have been giving you so many problems. I think TU probably hit the nail on the head with the lack of detail idea but, even then, it really shouldn't have been anywhere near so hard for you to get a pretty basic skybox render done.
I've made quite a few panoramas with TG and I never experienced any trouble at all with the Terragen side of things, worked perfectly every time with no seams or any required overlap, just set up a 90 degree fov and render away. The main problem I had was finding a decent panorama stitching program, which I did in the end. Pano2VR is really great and simple to use.
Glad you got things sorted in the end. :)
I hope we can see a spherical camera in TG soon though. Everyone else has one.
That looks really good, Draigr. And I'm looking forward to your tutorial.
ps. Funny things happen when you set the camera to really wide angle, like 180 degrees. Until 150 degrees you're safe.
Detail settings shouldn't be a problem. Contrast in the lighting is also fine - there's no reason why that alone should cause differences between adjacent tiles.
I've taken a quick look at the file you posted, Idyl Lake Shot_0005.tgd, and I see something which might be the culprit. You are using a Distance Shader, which is camera dependent. Normally this would be OK if the camera position remains the same (which it does), but the mode has been changed to "Z Depth (Planar)", which means it gives different results as the camera rotates. You could fix this by changing it back to the default mode of "Distance (Spherical)".
Matt
Quote from: Matt on November 11, 2011, 09:45:20 PM
Detail settings shouldn't be a problem. Contrast in the lighting is also fine - there's no reason why that alone should cause differences between adjacent tiles.
I've taken a quick look at the file you posted, Idyl Lake Shot_0005.tgd, and I see something which might be the culprit. You are using a Distance Shader, which is camera dependent. Normally this would be OK if the camera position remains the same (which it does), but the mode has been changed to "Z Depth (Planar)", which means it gives different results as the camera rotates. You could fix this by changing it back to the default mode of "Distance (Spherical)".
Matt
Ah of course, I completely missed that :)
I do wonder though why many of these skybox threads show the same problems between tiles, mostly related to contrast in lighting. Why does it often work better when the lighting has less contrast? Also why would detail not be a problem with 0.19 detail setting?
There should be an "ideal" way to render these things, which logically would be a spherical cam or skybox function, but without it there must be some kind of general approach which should point one into the right direction?
Cheers,
Martin
Quote from: Tangled-Universe on November 12, 2011, 02:52:44 AM
I do wonder though why many of these skybox threads show the same problems between tiles, mostly related to contrast in lighting. Why does it often work better when the lighting has less contrast?
In those cases I think it's either GI or Acceleration Cache. Those are still the only problems I'm aware of.
Quote
Also why would detail not be a problem with 0.19 detail setting?
Detail doesn't affect clouds at all if Ray Trace Atmosphere is on and there is no GI and cloud acceleration caches are disabled. It would affect detail on the terrain and water, but only the detail. Not overall contrast or general lighting. Detail is supposed to be scalable, so there is nothing "wrong" with using a detail of 0.19.
Quote
There should be an "ideal" way to render these things, which logically would be a spherical cam or skybox function, but without it there must be some kind of general approach which should point one into the right direction?
There are many threads on the subject, and the same recommendations come up, but some official documentation on it would be useful.
Matt