Unity Timeline stops refreshing Octane Tweet

[EFS]

Hey,

Everything was working fine until yesterday, when (coincidentally?) my entire Octane stopped working because Tier1 ran out for me. I have Tier 2 now (and Xhed said my tier 1 should be fixed now anyway) ... but my timeline that used to update Octane does not anymore. I don't know if this is related or just a when-it-rains-it-pours type of thing.

Selecting the timeline will cause Octane to render _1_ frame (it seems to always be the first, but I'm not positive). After that, it doesn't care if I scrub through. I cannot get it to re-render. I assume this is a bug under the hood with how Timeline triggers a refresh.

The same timeline had been working fine the other day. Granted, I've made changes since then as I've been working on stuff anyway ... but if I did something to break this, I cannot figure out what. I'm starting a new project to see if that solves it, but figured you may want to know about this anyway.

[EFS]

Oi. Sorry for the shier amount of posts I've been making, but I'm just hitting a lot of different things the past two days.

I created a new project to test this in. However, I could not switch to Tier 2 in the new project until closing down the instance of Unity from my real project. It failed after reaching 100% progress with the error "IOException: Sharing violation on path C:\Users\_USERNAME_\AppData\Local\Octane\Unity\2017.1.0f3_1.0.0.963_T2\octane.dll". Quiting the other instance of Unity fixed this.

I tend to have multiple instances of Unity running, since while one project is compiling, I work on another. This is especially true when one instance is rendering. Not to mention trying to fix a problem like this. It would be great if this could be fixed at some point.


[Edit - New project with a new timeline ... still not updating the Octane viewport when I scrub. This was working fine for weeks ... very confused]

Okay, so I can change the lighting and the viewport will refresh, but it uses the 1st frame of the timeline no matter where I scrub.

Hitting undo/redo will also cause a refresh. However, hitting Undo/Redo will cause it to refresh AND use the correct frame in the timeline. Something is definitely going wrong.

[Edit 2 - This is a *really* nasty bug. I cannot export from timeline properly anymore. It just outputs the same image over and over, which is my model in a T-Pose ... not even using the timeline, although it shows the timeline frame advancing in the editor. If we could get this resolved asap I would appreciate it, as I was supposed to be exporting a series of videos]

[EFS]

Well I solved it. It only refreshes when there is an active animation. Please fix this. I have custom timeline stuff that affects blendshapes ... EVERY frame that the timeline changes should refresh the viewport. This should have zero to do with what's in the timeline itself.

[ChrisHekman]

Well I solved it. It only refreshes when there is an active animation. Please fix this. I have custom timeline stuff that affects blendshapes ... EVERY frame that the timeline changes should refresh the viewport. This should have zero to do with what's in the timeline itself.

I have added blendshapes to OctaneUnity. It should be part of the next build.

*The octane renderer is reset depending on if any scene changes have been detected. Blendshapes were not included in this yet. There is no reason to reset the frame when we detect no changes.

[EFS]

Well I solved it. It only refreshes when there is an active animation. Please fix this. I have custom timeline stuff that affects blendshapes ... EVERY frame that the timeline changes should refresh the viewport. This should have zero to do with what's in the timeline itself.

I have added blendshapes to OctaneUnity. It should be part of the next build.

*The octane renderer is reset depending on if any scene changes have been detected. Blendshapes were not included in this yet. There is no reason to reset the frame when we detect no changes.

With all due respect, the above case *already* disproved that mentality. You are making the assumption you will always be able to predict what a user creates for the Unity timeline. What is the harm in providing a checkbox, if nothing else, that renders out every frame? If I specify the Octane timeline to render between frames 1-45, I expect to have 45 renders. Not to have you guys selectively decide which frames you want to render and which frames you don't.

If I am making a video that needs to last 100 frames to sync with other things, I expect 100 renders to put into premiere, or whatever other software *I* decide to use, without having to jump through hoops trying to figure out what you guys decided to actually render out to me. The same goes for selecting a frame in the timeline and having the viewport update.

I spent almost an entire day debugging an issue caused by this mentality. If I cannot go back to my boss and assure him there will *never* be another issue caused by Otoy deciding they don't have to update the viewport or render a frame that has changed through our custom code, then how can I ever recommend using this software in a real production process? This one bug already cost us over a years worth of Tier2 subscriptions, to put it into perspective.

I *love* Octane. I *love* Octane in Unity. I *don't* love Octane in Unity telling me how I am expected to use it.

[Edit -- Please keep in mind that the Unity timeline comes with an API that is meant to be used. A major strength of the timeline is that users can create their own plugins. This is not a one-off use case ... the crux of this issue is can a user expect that Octane will work smoothly with the timeline regardless of the content. Even if you don't want to provide this out-of-the-box, at least provide an API that we can use in a custom timeline track which forces a refresh/render. You're shooting yourselves in the foot otherwise with part of the user-base.

Just going to add that I really want this to become a smooth production process. I'm not griping for the sake of it, but because I see a real issue that has the potential of becoming a reason we cannot count on this integrating into our production process. The ability to leverage Unity's timeline to drive animations in Octane is tremendous (at least for our small company which has a good knowledge of both C# and Unity) and I don't want to see this become another "close but not quite" in the future because of something that doesn't have to be an issue. I don't expect any changes anytime soon ... just please keep this in mind.]

[ChrisHekman]

Well I solved it. It only refreshes when there is an active animation. Please fix this. I have custom timeline stuff that affects blendshapes ... EVERY frame that the timeline changes should refresh the viewport. This should have zero to do with what's in the timeline itself.

I have added blendshapes to OctaneUnity. It should be part of the next build.

*The octane renderer is reset depending on if any scene changes have been detected. Blendshapes were not included in this yet. There is no reason to reset the frame when we detect no changes.

With all due respect, the above case *already* disproved that mentality. You are making the assumption you will always be able to predict what a user creates for the Unity timeline. What is the harm in providing a checkbox, if nothing else, that renders out every frame? If I specify the Octane timeline to render between frames 1-45, I expect to have 45 renders. Not to have you guys selectively decide which frames you want to render and which frames you don't.

If I am making a video that needs to last 100 frames to sync with other things, I expect 100 renders to put into premiere, or whatever other software *I* decide to use, without having to jump through hoops trying to figure out what you guys decided to actually render out to me. The same goes for selecting a frame in the timeline and having the viewport update.

I spent almost an entire day debugging an issue caused by this mentality. If I cannot go back to my boss and assure him there will *never* be another issue caused by Otoy deciding they don't have to update the viewport or render a frame that has changed through our custom code, then how can I ever recommend using this software in a real production process? This one bug already cost us over a years worth of Tier2 subscriptions, to put it into perspective.

I *love* Octane. I *love* Octane in Unity. I *don't* love Octane in Unity telling me how I am expected to use it.

[Edit -- Please keep in mind that the Unity timeline comes with an API that is meant to be used. A major strength of the timeline is that users can create their own plugins. This is not a one-off use case ... the crux of this issue is can a user expect that Octane will work smoothly with the timeline regardless of the content. Even if you don't want to provide this out-of-the-box, at least provide an API that we can use in a custom timeline track which forces a refresh/render. You're shooting yourselves in the foot otherwise with part of the user-base.]

I am sorry you had to spend a long time debugging.

About the reset, let me be more clear.
Changes in unity are detected by OctaneUnity and propagated to Octane. Since blendshapes were not fully supported yet, OctaneUnity did not propagate the blendshape changes to Octane properly.
The reason you were seeing the effects of blendshapes, eventhough it was not supported yet, is because we use unity's BakeMesh function for bone animations. This function also bakes the blendshapes.
This function is prohibitively slow, and generates a new mesh every time it is being called, this mesh then gets sent to Octane, which is also slow. This is why we only call it when we know something has changed.

About the rendering, Am I correct in understanding you were not getting the number of rendered images you specified?
Even if no changes are detected, it should still output the specified number of rendered images. If this is not happening we will have to take a look at it.
(Or are you just getting the same image multiple times because no changes were detected in OctaneUnity?)

[EFS]

About the reset, let me be more clear.
Changes in unity are detected by OctaneUnity and propagated to Octane. Since blendshapes were not fully supported yet, OctaneUnity did not propagate the blendshape changes to Octane properly.
The reason you were seeing the effects of blendshapes, eventhough it was not supported yet, is because we use unity's BakeMesh function for bone animations. This function also bakes the blendshapes.
This function is prohibitively slow, and generates a new mesh every time it is being called, this mesh then gets sent to Octane. Which is why we only call it when we know something has changed.

About the rendering, Am I correct in understanding you were not getting the number of rendered images you specified?
Even if no changes are detected, it should still output the specified number of rendered images. If this is not happening we will have to take a look at it.
(Or are you just getting the same image multiple times because no changes were detected in OctaneUnity?)

No worries about the time lost. Its expected when finding a new production process that things may go wrong. I'm more concerned about future stability.

Sorry, the number of frames rendered was correct, it was just the same frame over and over. My apologies for that.

I am sure you have very good reasons for only refreshing when a change is detected. As it is, without a lot of testing, I have no idea what will work and what won't if I don't have an animation playing. Maybe *every* possible use-case of *anything* changing *in any way* in Unity is now accounted for ... in which case, wonderful! I really want to use this ... it brings a lot to the table. However, if not, I'm strongly suggesting that you provide a way to force a refresh, and allow the user to decide if they need to use it or not. Or, at the very least, document *very explicitly* what will work, and that anything else is at-your-own-risk. The expected behavior is the state of the timeline will be reflected in the render, and if it has the potential to deviate from that, it should really be made very clear before a user begins using it.