Spherical camera glitch workaround

[bigben]

Hi All

Haven't searched too hard if anyone else has found this but I may have found a way to avoid the small triangular gaps at the zenith and/or nadir when using the spherical camera. In the render bucket controls, adjust the width of the max bucket size to the same or larger than the image and reduce the height so that the area is reduced. I also unchecked allow auto reduction.

From watching TG render with a spherical camera it appears that the scene is rendered in vertical strips of 45° longitude.  The gaps appear to be failures at the top or bottom of one or more of these strips (small rectangular block of lat/long which looks like a small triangle when viewed in a spherical viewer), which seemed odd for this projection. I went looking for some setting that would force TG to calculate all the way across the image and this setting seemed to be the only one that might be suitable (although I could be completely wrong). Right or wrong it appears to work. 

This leaves me with a few questions. What is the relationship between bucket size and render speed? Can I calculate what the optimum area of the bucket should be for my PC specs? Impacts on rendering time?

Default scene with a couple of cloud layers, rendered at 2000x1000
[attach=1]

[Oshyan]

This is an interesting workaround and will hopefully help inform the fix we're working on for the root problem. That being said be careful with really large buckets, it will likely increase memory use a good deal.

Optimal bucket size is around the default size for average scenes. You can get some improvements adjusting either up or slightly down, depending on scene and number of CPU cores you have (number of render threads), but in general the defaults are set that way for optimal performance.

- Oshyan

[bigben]

My first test was a wimpy 1000x500 render using a 1024x512 bucket.  Went OK but I wasn't expecting that to scale well so I went back to keeping the default area (256x256=65,536) but changing the proportions. Testing scalability at the moment with a simple scene, 16,000x8,000 render, 16,384x4 bucket. That'll take a while but after that I'll do a performance comparison with a smaller render/more complex scene to satisfy my own curiosity.

Takes me back to the ortho renders in TG0.9, watching the image appear line by line 

[bigben]

16,000 pixel render finally finished  (need.... more.... RAM)  I was testing a couple of things at the same time so it's nothing pretty to look at and the camera's not level. Got my hands on a 20m DEM of the Grampians (AU). No holes in the zenith or nadir. Render speed was pretty much as expected so I don't think changing the proportions of the bucket was a bad thing in that respect.

http://www.bigben.id.au/demo/tgpano16k.mov (10mb)

[bigben]

Quick performance comparison.
Default scene, camera straightened, render size 2000x1000, TG restarted between renders

• 256x256 bucket: 5m 29s, max RAM usage 1.979Gb (1 nadir error)
• 2048x32 bucket (allow auto reduction): 5m 33s, max RAM usage 2.012Gb (same nadir error)
• 2048x32 bucket (uncheck allow auto reduction): 6m 17s, max RAM usage 2.652Gb (0 errors)

[Kadri]

Ben i think the problem is still there just not distinctive.
İt looks like it is lowered to 1-2 pixels .It is more visible if you offset the image in an image editor.
Some Pixel filters produces problems on the sides too even.

But this is still a good solution as the problem is practically nearly not visible .
Depends on the image but cutting 1-2 pixels from the image could maybe get rid of this problem further.

[bigben]

Thanks Kadri.

Yes you're right. Found a wee glitch in the 16k render when I looked really close, and I can see the edge errors as well although it's only a pixel or 2. Cutting a pixel or 2 off the image might remove the error but the image proportions should really be exactly 1:2 for image viewers. As the image at the zenith/nadir is very stretched horizontally, cloning an adjacent area of image should produce a very tidy patch up.

[edit] Checked the 2k render and there is variation in the colour of the bottom pixel (technically should be the same all the way across), but this could be due to rendering the image in vertical strips. The small glitch in the corner is also visible but I think this is a separate issue. It looks like an edge error that is remapped across the chunk of image being rendered rather than a rectangular block of missing render.  This will be more visible if you offset the image because you are seeing both corner errors together but this is negligible if you are viewing the image in a panorama viewer. [/edit]

[Kadri]

Ben did you look at the "Render subdiv settings" that is in the internal network of the "Render" node?
Changing the upper settings makes me think if the real problem lies here or not.

[bigben]

Had a look at these. The default recommended settings for animation will change some of these and this will exacerbate whatever is happening in the corners. I think that's something to do with jittering, is a very small effect and for images viewed in a panorama viewer (remapping the image back onto a sphere) it's pretty negligible.  None of those setting affect the missing chunks.

[bigben]

After reading this thread http://www.planetside.co.uk/forums/index.php/topic,17307.msg168100.html#msg168100 it was looking like "Defer atmosphere" might be a better fix.  It worked on the default scene but when I tried it on one of my older projects (Monument Valley terrain set) I still had a glitch.  Tried a couple of things to no avail. I wondered if there was another setting that was throwing things off. It may have been possible since the old project was made in TG2.  I exported the render node from a TG3 default scene as a clip and then inserted it in my old project and this rendered without a glitch. I'm off to work now and will look at this later but here are clips of the two render nodes. Something in here may provide a clue.

[Matt]

Hi Ben,

There is a flaw in the renderer, but we are going to fix it for the next release. I just hope you are aware of that with all of the experimenting you're doing to find workarounds!

Matt

[bigben]

Curiosity and all....  but I have a paper to finish editing by Friday so I guess that's it for me now. 
A full width bucket AND deferred atmosphere seems to work the best for stills.

[Matt]

Just making sure The info will be probably useful to others anyway.