High res QTVR test

Started by bigben, March 05, 2007, 07:43:17 PM

Previous topic - Next topic

bigben

#15
Hi Oshyan... Here are the results of my masking test... it's looking very promising   :)

On reflection there are different situations that will break things in different ways. To deal with each of these, I ended up using all 3 options mentioned in my previous post.


  • A circular image map for near camera objects
  • A wedge-shaped mask projected through a camera pointing down directly above the render camera
  • A "through the lens" mask through a duplicate of the render camera with a slightly increased fov.

[attachthumb=#1]

The first compensates for a low camera position, catching objects behind the camera that may extend into the render. The size of this is arbitrary here but you could easily calculate this.

radius of circle = width of object / tan (fovmask - fovrender)
<edit> I should have calculated it.  For a 10m wide object I could use 300m instead of the 500m I picked at random in this test</edit>

While the last two masks may appear to do the same thing, they do cover certain situations better. The last one may not populate the far side of ridges resulting in serious omissions in gently undulating terrain with a low camera angle, but it will correctly mask a wide angle camera tilted downwards from a high camera altitude.

Attached the TGD and image masks for you to try. Not sure how stable this will be in a render but it does have considerable potential to populate large areas efficiently, and the masks can be easily animated.

There are probably better ways to put these together but I find it easier to use little building blocks so that I can see what I'm doing, and modify things one bit at a time.

Crossing my fingers now...  just started rendering a sequence from my QTVR. With a bit of luck this may work around my problem of the sequence crashing after frame 1. I'll find out in an hour or two....

:( Nope. Grass population was still high (133,000) and it crashed. Changed the scale and spacing of the grass and trying again. 65,000 this time.... still crossing fingers.  Tree populations are only 2,500 though, which is a big improvement for a 20km square... and RAM usage is down to 500-600Mb, nearly half of previous renders!!

;D BINGO!!!  ;D
... well it's started rendering frame 2 anyway. I'll have to work on a good fake grass surface for distances over say 100m. The distant grass objects were certainly increasing render times a lot anyway.  Frame 3 now  :)  Thanks for giving me the extra nudge to extract the idea into a working model.

The other good thing is that it was relatively easy to incorporate it into an existing project. Edit the camera and image map locations and then slot the final shader into the existing node network.

[attachthumb=#3]

With the modular approach that I use, it's also easy to duplicate for use with multiple density shader networks. All you need to do is duplicate the last shader and input the last Add colour into its fractal breakup input.

Frame 4 now  :D

§ardine

bigben,
Just thought and a question :)

I was working on a similar situation using the through camera masking of a population and found that the projected image mask (location bottom left, size 1x1 position 0x0x0) does slightly go beyond the fov of the projection camera. Further experimenting showed that I was able to resize the image shader and "offset" it using a negative position (such as size 1.5x1.5, position -0.25x-0.25x0) giving me an even wider fov. Thus allowing me to eliminate a camera by using the render cam. In your case this would keep you from needing to add and animate you're 3rd camera.  :P

Also I haven't gotten Deep+Animation yet :D but was wondering if you are needing to select "Repopulate every frame" in your populations?

~§ardine

bigben

Well I'm getting closer to getting this to work. There are still some stability issues I have to overcome  (which were not expected to be fixed by the update)  Rendering as a sequence I got the first 8 frames of sky OK but then it crashed.  Restarted (at frame 9) and got the next two frames to render and then it crashed again....

Now that the update is out I'll have a serious play with the CLI over the weekend and try some on-the-fly stitching. It should overcome the remaining sequence render problems I'm having.

If the frames render OK I might even get to increase the fov of my tiles now that the RAM usage has dropped (or make the tiles bigger, and see if I can break it again  ;))

http://www.path.unimelb.edu.au/~bernardk/tgdemo/tetons_pano_v6.mov

bigben

Quote from: §ardine on March 15, 2007, 11:58:06 PM
bigben,
Just thought and a question :)

...In your case this would keep you from needing to add and animate you're 3rd camera.  :P

I'll have a play but I'm not sure. I haven't used a through the camera mask before. My main concern was does the mask cover the entire surface within the cameras view... specifically does it cover backfaces? This is critical for this particular use but I haven't tested this yet.

Anything that simplifies it further is worth a try.

Quote from: §ardine on March 15, 2007, 11:58:06 PM

Also I haven't gotten Deep+Animation yet :D but was wondering if you are needing to select "Repopulate every frame" in your populations?

~§ardine

I had tried repopulating every frame but it made no difference, but the issue was definitely related to the object populator.
http://forums.planetside.co.uk/index.php?topic=954.0

§ardine

Well i decided to do a little experimenting since I was on the subject...

It does appear that the through camera masking will allow populating on the backfaces of the terrain. I set up a camera looking at some very tall displacement. Added a population covering the whole aria with through camera masking. After populating, I brought the preview camera up and was able to confirm the coverage was on the backfaces of the terrain. A render using a different camera at the new location confirmed it as well.

Also regarding the question of repopulating every frame: I'm afraid I was asking a question totally unrelated to your crashes and caused some confusion by not explaining the reason for the question ;D...
I was wondering if you needed to repopulate in order that, as your camera rotates (and so also your masks), the population will  follow your view. I'm not sure how populations work with an animation (as I said I haven't purchased anything yet), but am wondering if the population will stay the same in an animation unless you use the repopulate option. Thus causing it to recalculate the new mask position.

anyway...  :P

-§ardine

bigben

Quote from: §ardine on March 16, 2007, 12:44:49 AM
It does appear that the through camera masking will allow populating on the backfaces of the terrain. I set up a camera looking at some very tall displacement. Added a population covering the whole aria with through camera masking. After populating, I brought the preview camera up and was able to confirm the coverage was on the backfaces of the terrain. A render using a different camera at the new location confirmed it as well.

Thanks, that's encouraging... the other potential issue I forgot to mention was terrain out of frame below the camera's line of sight. If this is included as well then I can probably remove the upper camera altogether... I'll check that later if you don't get a chance...

Quote from: §ardine on March 16, 2007, 12:44:49 AM
...but am wondering if the population will stay the same in an animation unless you use the repopulate option. Thus causing it to recalculate the new mask position.

Doing single renders, TG usually picks up when the distribution has changed (even if the effective result is an identical mask) and repopulates anyway. If this behaviour persists for animations then it may not be necessary, but it would probably be safest to repopulate in this instance... Rendering frame by frame via CLI will effectively be doing this anyway.

§ardine

Quote from: bigben on March 16, 2007, 01:00:04 AM
the other potential issue I forgot to mention was terrain out of frame below the camera's line of sight. If this is included as well then I can probably remove the upper camera altogether...

Checked on this, and as far as I can tell, you will need to keep that upper camera. I tried doing a image size of Y=100 with a offset of -99 to get the angle down as far as possible. Even then objects directly below and in front of the camera at about a 5 degree angle don't populate.

I did find out that the image shader at size 1x1 is projected as a square out of the camera using the largest angle in your aspect ratio. Thus if you're rendering at 800x600 your image shader will be 800x800 and extend up beyond the top of the render. In this case it will be populating more than necessary outside the picture. :-\ This is different than I had expected as I would have thought that the image mask would have been stretched to fit the aspect ratio of the render. This doesn't change a whole lot but might be something to keep in mind when setting these up.

~§ardine

bigben

#22
Thanks for checking these out, it's very helpful.

My sequence renders were still crashing anywhere between 2-20 frames. But the crashes aren't as bad as the previous version, as I'm now getting a notification that TG has stopped responding.

My database is half setup now, with rendering and stitching sorted out. I've started rendering with the CLI as a result, and no crashes so far  ;D ;D ;D. Judging by the timestamps, there is no increase in render times with restarting TG and loading the TGD, image maps and objects for every frame, and it's a lot easier checking the progress on my work computer via VNC ;).

I'll setup the on the fly QTVR converson on Monday for whatever frames are remaining... not for any real practical reason other than to show it can be done.

bigben

#23
Quote from: bigben on March 17, 2007, 12:00:32 PM
I'll setup the on the fly QTVR converson on Monday for whatever frames are remaining... not for any real practical reason other than to show it can be done.

This process is now running. I've re-ordered the rendering sequence to do row by row (top down) instead of columns, so there won't be too much change for the next 12 frames or so. I've also put the log file online so you can check the progress before donwloading it again.

Commandline processes:

  • render frame
  • generate script file for PTStitcher
  • combine rendered frame with stitched panorama of completed frames
  • convert to QTVR
  • copy to local web directory (mapped network drive) [View QTVR]
  • log frame number to file to help track progress in the database [View Log file]

Here's a sample of the code for frame 139. One of the reasons I use a database to generate this stuff ;)

%TERRAGEN_PATH%\tgdcli -p C:\TGD\Tetons\Project1\tetons_2049_v6.tgd -hide -exit -r -f 139
echo p w3600 h1800 f2 v360 u0 n"TIFF" > C:\TG2QTVR\hi-res_v6\stitch.txt
echo m g1 i0 >> C:\TG2QTVR\hi-res_v6\stitch.txt
echo i n"pano.tif" >> C:\TG2QTVR\hi-res_v6\stitch.txt
echo o f4 y0 r0 p0 v360 a0 b0 c0 d0 e0 g0 t0 >> C:\TG2QTVR\hi-res_v6\stitch.txt
echo i n"pano0139.bmp" >> C:\TG2QTVR\hi-res_v6\stitch.txt
echo o f0 y350 r0 p80 v10 a0 b0 c0 d0 e0 g0 t0 >> C:\TG2QTVR\hi-res_v6\stitch.txt
C:\TG2QTVR\PTStitcher.exe C:\TG2QTVR\hi-res_v6\stitch.txt -o C:\TG2QTVR\hi-res_v6\pano2.tif
REM precautionary clean up of temp files if left behind
del _ptstitcher_tmp*.*
move C:\TG2QTVR\hi-res_v6\pano2.tif C:\TG2QTVR\hi-res_v6\pano.tif
C:\TG2QTVR\PanoCUBE.exe pano.tif
REM local copy
move pano.mov tetons_v6.mov
REM online copy
copy tetons_v6.mov t:
echo 139,1 >> t:render.log


bigben

#24
Speeding up the render today to get the sky out of the way. With GI turned off I really don't need the populations enabled. This will save TG from populating 6 billion triangles per frame  :o   The render log came in handy as it was easy to eliminate the frames that were rendered in the last batch. Once I hit the horizon I'll reverse the render order and render from the bottom up as those frames are quicker to render.

I'm using an explorer window to track the render progress. Viewed as a film strip with the stitched image selected I get a large preview that updates each frame :)
[attachimg=#1]

nvseal

Looking great bigben, I'm looking forward to seeing the final QTVR.

bigben

Neither can I... although... I've finished the quick renders of the sky (saved heaps of time there (13min down to 3min per frame)) and I've started the bottom up rendering with objects. 

The additional masking of objects has cut the render times for these tiles down to 13 - 45 minutes per tile (down from a previous maximum of 4hrs). Taking an average of say 30min per tile that leaves around 5 days left to go if I stick to just one machine... so I can stop blogging on this post for a while  ;) 

DiscoBall

Heh bigbeg, is the grass that cut_lawn grass you uploaded last time? I am using that at the moment, looks good, however yours looks a bit more..'detailed'...

bigben

Same surface, different object. This one has long, thin blades.

http://forums.planetside.co.uk/index.php?topic=1032.msg11152#msg11152

A lawn mower in a forest wouldn't look right ;)

DiscoBall

Oh thanks!
However..there doesn't seem to be a tgo I can use..neh, I'm fine with your cut lawn grass :p It's perfect...for now :P