Page 1 of 2

Calling "Render" from Editor script

PostPosted: Tue Aug 29, 2017 12:29 pm
by Xantiah

Is it possible to call "Render" on PBR Render Target Component from Unity Editor Script?

I'd like to render set of images, using following procedure:

1) Call "Render" method for the current camera view
2) Wait till render is finished, then export current render to disk.
3) Modify scene using Unity editor script, and call "Render" method again.
4) Repeat points 1-3 till all images / choices rendered and exported.

Please let me know if / how it can be done?

Re: Calling "Render" from Editor script

PostPosted: Tue Aug 29, 2017 6:16 pm
by Goldorak
It's technically possible but not officially supported just yet (c# final interface will be based on octane module API in development)

Re: Calling "Render" from Editor script

PostPosted: Wed Aug 30, 2017 9:46 pm
by Xantiah
Thanks. I understand it's not officially supported, but can you at least give me some tips how can I do it?

Re: Calling "Render" from Editor script

PostPosted: Thu Aug 31, 2017 6:07 pm
by jalley
Xantiah wrote:Thanks. I understand it's not officially supported, but can you at least give me some tips how can I do it?

Same issue here, ┬┐is there any tip on how can Unity be forced to wait until Octane has finished rendering one camera frame? Thanks.

Re: Calling "Render" from Editor script

PostPosted: Fri Sep 01, 2017 5:41 pm
by EFS
I also would appreciate this. We want to batch a bunch of a different timelines overnight. Currently there is no way to do this (I think?). If we could start the process and know when it ends, then I could write an editor script that batches them as needed.

Re: Calling "Render" from Editor script

PostPosted: Wed Sep 06, 2017 4:26 pm
by jalley
I am rather new to Unity/Octane but I manage to write down an initial Editor script that dumps Octane renders using Octane.Renderer C# API. The main idea was to keep a Unity CoRoutine launched from Update() waiting for Octane to finish the render in the PBR Viewport for as long as needed to let Octane Renderer finish the render with the desired #spp (samples per pixel).

This idea however comes with an inner drawback, as launching one of this coroutine per frame, causes an overhead in the number of coroutines used, as many are waiting for the same frame to finish, however my understanding is that most of them should return from the yield instruction when a render is ready and do not need to do anything else. I have tried WaitUntil yield construction but results I obtained were somehow unexpected.

So, the proposed solution worked fine, and I have empirically observered that when rendering with Time.captureFramerate of Unity, Octane manages to achieve one third of the desired frames, so e.g. you need to set 90 in order to get 30 fps in Octane. I have tried this even varying the #spp obtaining with the same ratio. This seemed to work fine until ... I had found another problem.

The main problem I still have is that when the scene contains heavy geometry/animations, the Octane PBR Viewport remains with the "Compiling Scene ..." message even if Time.timeScale is set to zero and Unity remains paused in the same state with no changes at all happening in the scene. This is quite frustrating as the script keeps waiting and Unity keeps blocked forever.

My Coroutine Pseudocode:

IEnumerator WaitForOctaneRender()
while ( Octane.Renderer.IsCompiling
|| ! Octane.Renderer.GetLatestRenderStatistics().samplesPerPixel.Equals(m_MaxSamplesPerPixel)
|| ! Octane.Renderer.GetLatestRenderStatistics().state.Equals(Octane.RenderState.RSTATE_FINISHED))
captured = false;
Time.timeScale = 0;
yield return 0;
// Capture frame
if (!captured) { Octane.Renderer.SaveImage(...); Time.timeScale = 1; captured = true; }
yield break;

Any suggestion/help from the Octane Rendering team or anybody else facing similar issues? Thank you.

Re: Calling "Render" from Editor script

PostPosted: Fri Sep 08, 2017 1:10 am
by jalley
Just to share our progress with other users related to this topic. We have recently found a different way - not using coroutines - to actually force Unity to wait until Octane finishes its renderings. The basic idea is to just do an if-else construction based on a condition (more comments to follow on this) where inside we freeze Unity with Time.scaleTime=0 and we restart it setting it back to 1 in the else branch. How to build the condition? For those interested the Octane C# API in Unity provides methods to check if Octane is compiling a scene (Octane.Renderer.isCompiling) and how many samples per pixel is currently targeting (Octane.Renderer.SampleCount) from a progressive sequence towards the maximum specified. Said this, we have built a more elaborated condition test that avoided repeated screenshots to be dumped into disk, by just checking the sample count reported in the previous frame. Hope this helps others.

Re: Calling "Render" from Editor script

PostPosted: Fri Sep 08, 2017 8:23 am
by Xhed
Nice find Jailey :D

Please note that the API you're using is just a mockup and isn't final yet; it is almost certain to change in the future. We want to make a better integration with the main Unity workflow, and provide samples on how to use Octane from other Unity scripts after we have settled on an API.

Re: Calling "Render" from Editor script

PostPosted: Tue Jan 16, 2018 4:51 am
by tcrain
I am looking to do the exact same thing as Xantiah. It seems like it should be a pretty simple script. Is there any update on the C# API yet? Or is there a decent workaround at least?

Re: Calling "Render" from Editor script

PostPosted: Wed Apr 03, 2019 11:08 am
by gagan
I am also trying to automate the system of rendering.
I have achieved some progress in it but unable to start the rendering for the first time.
For the first time i need to click on Render button and it loads and compile the scene after that the PBRViewport is opened and then i can use my code.
So instead of that button click I want my own function in Unity C# to do the working of Render button of PBRRenderTarget.
Please let me know if you got any workaround for this.