Announcement

Collapse
No announcement yet.

UE4 + Nvidia Ansel + 360 Video Capturing

Collapse
X
  • Filter
  • Time
  • Show
Clear All
new posts

    #16
    Originally posted by iBrews View Post

    Is your frame-rate in the sequence the same as your frame-rate in the blueprint? Sounds like this would happen if your sequence framerate is 30 and your blueprint framerate is 60.
    I have the blueprint and sequence set to 30 fps, as well as the constant frame rate set to 30 in the options

    Comment


      #17
      Originally posted by Warrior9VR View Post

      I have the blueprint and sequence set to 30 fps, as well as the constant frame rate set to 30 in the options
      Not sure what's causing this, but a few ideas based on threads like this: (https://forums.unrealengine.com/deve...kipping-frames)
      -- try using a normal camera or a pawn and not a cinematic camera
      -- create an Unreal Engine shortcut on your desktop and launch Unreal Engine with the following options (this assumed 4.18 installed on your C drive) "C:\Program Files\Epic Games\UE_4.18\Engine\Binaries\Win64\UE4Editor.exe" -usefixedtimestep -fps=30 -notexturestreaming
      -- try doing a test export in an empty project to see if there might be something specific to your project settings
      Alex Coulombe
      Creative Director
      Agile Lens: Immersive Design
      New York City
      www.agilelens.com

      Comment


        #18
        Changing it to a pawn for capturing made the difference! So folks, dont use a cinematic camera! Thanks for your assisstance iBrews

        Comment


          #19
          Have been experimenting with the ansel rendering the past few days and now I am running out of video memory...assuming this is caused by the density of the scene I am trying to render. Any tips or work-arounds for this?

          Comment


            #20
            Why does NVidia not expose their UI to us? Relying on AHK is really unwieldy.

            Comment


              #21
              I'm gonna use this setup Click image for larger version

Name:	Ansel.PNG
Views:	1
Size:	217.5 KB
ID:	1465317 with the camera manager
              Igor, swamper, sole proprietorship

              Comment


                #22
                The thread's been pretty quiet, but has anyone else experimented with automating things so that it's possible to render the next frame when the previous is done, instead of having to set a timer.
                (The timer is the worst, overshoot and you waste a lot of time idling. Undershoot and suddenly you'll have issues with the macro triggering while rendering.)

                The event 'Photography Multi Part Capture Start/End' Triggers on start/end of multi part rendering, aka the 360 rendering process.
                So if there is some kind of way to get unreal to ping an exterior program to activate the auto-hotkey programs, then that would let us render more efficiently, and without fear of suddenly messing things up because the script triggered 1 second before the rendering was finished.

                (Though exactly how, I have no idea.
                It could be possible to just have unreal output a logfile every time a render finished, and have a hotkey program parse that whenever it updated, if any of them have that capability.)

                Edit: Looks like Pulover's Macro Creator can look at a certain region/pixel of the screen for a specificed colour.
                So it's possible to
                Run macro to start up ansel, input settings, take picture.
                Wait for render, while checking if the 'start' button has turned green, once a second.
                Render finishes, Start button becomes green again.
                Macro closes ansel, moves to next frame, restarts again.




                Apart from that, has anyone looked at the performance of capturing from Ansel?
                I noticed that it renders way less parts/tiles the larger the resolution of the play window is, and I was curious if that would make it more efficient.
                In addition to that, there's also a console command: r.Photography.SettleFrames 10
                To render a couple frames to settle temporal effects, which I don't always use.

                Anyhow: to testing: Just taking out a 360 Stereoscopic 8kx8k pic from a scene I have, all from the same view, to see how rendering time changes with various settings.
                Times are with a stopwatch, so not perfectly accurate.
                (And also, I imagine rendering would be a bit faster with a packaged product, instead of running in a standalone window with the editor up. But I'm testing from the editor right now.)

                Render round 1: Settleframes 10,
                Window resolution: 1280x720, 474 tiles, 90sec
                Window resolution: 1920x1080, 214 tiles 47sec.
                Window resolution: 2560x1440, 120 tiles, 35sec.
                Window resolution: 3840x2160, 56 tiles, 28sec.

                Looking at that, there's obviously a huge overhead related to how many tiles you're rendering. You get the exact same render in less than a third of the time going from 720p to 4k.

                Render round 2: Settleframes 0,
                Window resolution: 1280x720, 474 tiles, 12.7Sec.!!
                However, this led to a couple graphical glitches in the render. (Chunks of buildings not being where they're supposed to, etc.Seemed like some parts were skewed.)

                Render round 3: Settleframes 1,
                Window resolution: 1280x720, 474 tiles, 19.4cec. Not really a noticable difference from Render round 1. Though I'm not using any temporal effects, not even TAA.
                Window resolution: 1920x1080, 214 tiles, 13.2sec.
                Window resolution: 2560x1440, 120 tiles, 11sec.
                Window resolution: 3840x2160, 56 tiles. 9.5sec

                Render round 3 doesn't have as big a difference when rendering at higher resolutions, compared to round 1. But it's still a pretty big savings just from having the game window be higher res.
                But obviously, if you want larger savings you should look at how many settle frames you actually need for your render. As it seems to be the majority of the rendertime.

                Still! That's a huge difference in rendertime.
                Going from a 90sec render to a 11 sec render, with no difference in the output. (Again, no temporal effects in the scene, or any other effects that might get anything from settling.)
                And even if you didn't want to touch the amount of Settle frames. (Honestly though, I imagine they have 10 as a default super high quality thing because you're not expected to try to render a video, after all.) Then you'd still be able to go from a 90sec to 35sec render ( nearly 3x as fast!) just by rendering at 2560x1440 instead of 1280x720.

                Rendering at a higher resolution than your screen, with a standalone / windowed process is also possible. I can do a 4k render on my 3440x1440 monitor. Though it means that Ansel's ui goes off screen, but that's a non-issue if you're using an automated script.

                Of course, higher resolution might not be possible for everyone, since it chugs up a lot more VRAM.
                (Thankfully Ansel either uses ram, or just saves out the tiles. It doesn't massively balloon in vram use atleast.)

                Checking Gpu vram usage: (Just from task manager.) (All of this is from the standalone player from editor. Doing this from a sequence in a separate process, or packaged project would be different I imagine.)
                Idling in editor: 3.9-4.1GB.
                in standalone player: 720p: 5.3GB
                in standalone player: 4k : 6.7GB

                That'll of course vary from scene to scene.

                Still, the takeaway is that for faster ansel rendering, at the exact same quality, render out stuff at 4k or something, it's a huge jump from the default window of 1280x720 or 800, when just rendering shots from the editor.
                Last edited by ax448; 05-30-2018, 07:02 AM. Reason: Added info about PMC's ability to look for colours/images in a region onscreen, allowing for more efficient automation of image sequence rendering.

                Comment


                  #23
                  Yup! (Sorry for the double post, but I figured this warranted a new one. )

                  Pulover's Macro Creator can actually just check for an image every so often. Meaning no more setting a generous timer to avoid problems.
                  Right now it works like this.

                  1: Start up process
                  2: Manually open Ansel, and close it again. ( So that the next time it opens, it starts with the 'done' button highlighted. )
                  3: Script runs, sets settings to 360 stereo + desired resolution.
                  4: It starts the render.
                  5: pauses for a second
                  6: starts checking if the 'Snap' button is green again, once a second. (It's greyed out while rendering.)
                  (It does this using the image/pixel search macro function. Allowing it to check a region of the screen for a specific image. like the snap button being green.)
                  7: once the render is complete, and the snap button is green. It waits for a few seconds.
                  8: Then closes ansel, and presses tab, to make time progress by a frame.
                  9: then it loops.

                  The only thing I need to wait for now is step 7, when the render is done and where ansel processes + saves the rendered image.
                  Because if seems to slow down the processing a lot if you're rendering something at the same time (understandable.), and if render 2 is done rendering before render 1 is done processing, it'll just throw out 1. On my pc, reading from and saving to a normal 2.5 ssd, it seems to take approx 4-5sec to save a 360 8x8k jpg. Massively longer for an .exr.
                  While if I render while it's processing, it'll easily take 10-15 seconds, aka long enough for the next render to interrupt it.

                  With 4x4k images I only need to wait around a second before progressing to the next render.

                  Still, that's massively more flexible than the old way where you had to account for how long it might take to render.
                  Now it's just waiting for the render to complete, then waiting a few seconds for the image to process, then on to the next one.
                  (It doesn't matter if the render takes 5 seconds or 500 seconds.)

                  Image: how it's set up.
                  At instruction 50: Space to start rendering.
                  51: wait a couple seconds, since there's no point in checking if it's done rendering at <10 seconds.
                  52: starts checking for the green snap button / the render being done, once every second.
                  53-61: After render, wait for a bit, close ansel window. End of macro, so that it can loop once it's done.
                  Attached Files
                  Last edited by ax448; 05-30-2018, 08:56 AM.

                  Comment


                    #24
                    Originally posted by ax448 View Post
                    Yup! (Sorry for the double post, but I figured this warranted a new one. )

                    Pulover's Macro Creator can actually just check for an image every so often. Meaning no more setting a generous timer to avoid problems.
                    Right now it works like this.

                    1: Start up process
                    2: Manually open Ansel, and close it again. ( So that the next time it opens, it starts with the 'done' button highlighted. )
                    3: Script runs, sets settings to 360 stereo + desired resolution.
                    4: It starts the render.
                    5: pauses for a second
                    6: starts checking if the 'Snap' button is green again, once a second. (It's greyed out while rendering.)
                    (It does this using the image/pixel search macro function. Allowing it to check a region of the screen for a specific image. like the snap button being green.)
                    7: once the render is complete, and the snap button is green. It waits for a few seconds.
                    8: Then closes ansel, and presses tab, to make time progress by a frame.
                    9: then it loops.

                    The only thing I need to wait for now is step 7, when the render is done and where ansel processes + saves the rendered image.
                    Because if seems to slow down the processing a lot if you're rendering something at the same time (understandable.), and if render 2 is done rendering before render 1 is done processing, it'll just throw out 1. On my pc, reading from and saving to a normal 2.5 ssd, it seems to take approx 4-5sec to save a 360 8x8k jpg. Massively longer for an .exr.
                    While if I render while it's processing, it'll easily take 10-15 seconds, aka long enough for the next render to interrupt it.

                    With 4x4k images I only need to wait around a second before progressing to the next render.

                    Still, that's massively more flexible than the old way where you had to account for how long it might take to render.
                    Now it's just waiting for the render to complete, then waiting a few seconds for the image to process, then on to the next one.
                    (It doesn't matter if the render takes 5 seconds or 500 seconds.)

                    Image: how it's set up.
                    At instruction 50: Space to start rendering.
                    51: wait a couple seconds, since there's no point in checking if it's done rendering at <10 seconds.
                    52: starts checking for the green snap button / the render being done, once every second.
                    53-61: After render, wait for a bit, close ansel window. End of macro, so that it can loop once it's done.
                    Can you show how it works in a video?

                    Comment


                      #25
                      How it works in practice / while rendering. Or how the script is?
                      Because scriptwise, the only difference compared to hotkeying it normally is that instead of waiting for a set amount of seconds before playing the 'finished rendering' part of the script.

                      It's not a super interesting video, but here you go.
                      https://youtu.be/QeDDrX-PiWU

                      The only difference between the 4k and 8k scripts is that the 8k one waits 10 seconds before checking if it's one, and waits longer after a successful render.
                      ( To let the image process before the next one.)

                      I guess that can be made flexible as well, but I just don't see the point in it, when the processing+saving is pretty uniform in length. As opposed to renders where it can vary a lot.

                      Comment


                        #26
                        ax448 Thank you.

                        The problem I am having now, is how to use Ansel with a premade animation in the sequencer. So that I could capture a video frame by frame.
                        I found other options and used panoramic captures, just wanted to see how it goes with Ansel. Because it apparently offers better performance and quality.

                        Comment


                          #27
                          Well there's no need to ask me Alex_Cross, just go through the thread. That's already been covered (there's even a gumroad link to a video covering everything you need to know.)
                          The only thing you need to do is to set up the game so that it pauses, you run ansel to render, then progress the gametime by 1 frame. Then render again.

                          Comment


                            #28
                            ax448 Great insights! Indeed, having to account for the render time adds a great deal of uncertainty and unnecessary waiting.

                            Comment


                              #29
                              Now I'm curious if anyone else has had any issues with Ghosting. And or has a solution to it. (Specifically for 360 stereo.)

                              It seems like it's primarily because ansel doesn't handle stitching objects that are close ( <1 meter? <1.5? ) to the camera.
                              But it's really strange because this isn't an issue in the same way if you render out a monoscopic image.

                              Here's an example. (Image shifts a bit to the side when rendering stereoscopic, that's because the camera goes a few cm to the left, takes a pic, then a few cm to the right and takes a pic.)
                              Click image for larger version  Name:	holyghostingbatman.gif Views:	1 Size:	370.6 KB ID:	1487722

                              Apart from the ghosting, the stereo and mono pictures seem more or less identical, though due to the ghosting the stereo one is significantly less clear when it comes to stuff close to the camera.
                              I wonder why this is? Maybe they're just running a lower quality version of the stitching to save time while rendering out stereo ones?
                              In either case, it makes it really tempting to just render 2 monos instead of 1 stereo pic, and just slap them together in post instead.


                              I'm very curious if there is someone who -doesn't- have ghosting of objects close to camera, while doing stereo 360 renders.

                              Edit: Nevermind I guess, there is some correction in the stereoscopic stitching that makes the view behave better. ( Like no flipping when turning 180 degrees around etc. ) Unless there's a way to fix that without too much hassle, rendering in stereo is the only way to get a usable result for stereo viewing.

                              That still leaves the issue of why the stitching/ghosting is so bad in stereo though. The only way I've seen to reduce it is to render at higher resolutions, but it's still visible even doing 16kx16k renders, and those take so long they're useless for video.

                              Edit 2: I guess the issue with stitching is because of how the stereoscopic 360s are captured.
                              ( Mono 360 is captured by spinning a camera around itself and taking pics. While Stereo has both of them spin around a sphere.)
                              But it is still kind of weird that I didn't really notice the ghosting previously, but that might be because I've mostly been working with larger, outdoors-y er scenes, with nothing within the 1-2m area it has issues with.

                              Would still love it if people could tell me if they have the same issues or not.
                              Last edited by ax448; 06-11-2018, 01:36 PM. Reason: Added an edit2.

                              Comment


                                #30
                                Does anyone has this problem when using ansel? When i activate ansel, the entire scene turns into non-photorealistic, or cartoon style. I just click Alt+F2 to activate the ansel screen, nothing else.
                                Click image for larger version

Name:	prob2.jpg
Views:	2
Size:	258.1 KB
ID:	1488405
                                Click image for larger version

Name:	screenshot1.jpg
Views:	2
Size:	234.1 KB
ID:	1488406

                                Comment

                                Working...
                                X