LW2019 - Slow deformations

[Marander]

Hi

As I mentioned in another thread, navigation in a high poly scene is faster in LW2019. Overall OpenGL speed is still slower than other apps but well usable in most situations.

But... LW2019 deformations are way slower than in LW2018, at least with the deformers I tested (Bend, Twist for example).

Is this slowdown maybe only applying to some deformers that changed in 2019? I also tested a Genoma Rig with a high poly object where LW2019 seems slower too.

I have reported this bug for 2018 and it was supposed to be fixed. I guess the deformation is not calculated during navigation again but instead deformation speed got much worse in some scenarios.

(LWB-3970) LightWave Layout viewport is slow with high poly objects and active Deformers in Modifier Stack.
--> Improvements in LW2019 have fixed this. Deforming meshes are no longer being rebuilt for OpenGL if the mesh hasn't changed.

I attached an animated test scene (created in LW2019). When loading the scene in 2018 there is a Node Handler plugin missing message but the Bend deformer is active and the deformation works well nevertheless, smoothly in 2018 and stuttering in 2019.

The object is actually not very high poly (375k polys) and the issue is already visible with a 80k poly object.

Note: The slowdown is only visible when playing the animation, viewport navigation when playback is stopped is smooth.

Can someone confirm that's the case so I can (re-) open a bug ticket?

LW_Bend_Test01.zip

Using Win10, LW 2019.0.1, Core i7 12T/6C, 64GB RAM, SSD, GF1080 with latest drivers.

[jwiede]

Can someone confirm that's the case so I can (re-) open a bug ticket?

LW_Bend_Test01.zip

I'll try to confirm in LW2019Mac64 a bit later this evening, barring unforeseen disasters.

[jwiede]

Can someone confirm that's the case so I can (re-) open a bug ticket?

LW_Bend_Test01.zip

Yeah, confirmed here, definitely worth filing as a bug.

LW2018.0.7 plays scene smoothly here, where LW2019(.0) (trial) plays with a distinct stutter (frames are just uniformly taking longer versus LW2018.0.7, it's quite obvious). Just freshly installed and tried LW2019.0.1 (trial), and it plays with same stutter as LW2019(.0), perhaps even a teeny bit worse. All runs with MacUB64 versions of LW, hardware and OS per sig.

NOTES: Enabling "Play at Exact Rate" actually worsens stutter slightly, but even with it off, the stutter is visible compared to the smooth playback of LW2018.0.7. Enabling "Play at Exact Rate" on LW2018 keeps the smooth playback, minimal visible difference here.

[Marander]

Yeah, confirmed here, definitely worth filing as a bug.

LW2018.0.7 plays scene smoothly here, where LW2019(.0) (trial) plays with a distinct stutter (frames are just uniformly taking longer versus LW2018.0.7, it's quite obvious). Just freshly installed and tried LW2019.0.1 (trial), and it plays with same stutter as LW2019(.0), perhaps even a teeny bit worse. All runs with MacUB64 versions of LW, hardware and OS per sig.

NOTES: Enabling "Play at Exact Rate" actually worsens stutter slightly, but even with it off, the stutter is visible compared to the smooth playback of LW2018.0.7. Enabling "Play at Exact Rate" on LW2018 keeps the smooth playback, minimal visible difference here.

Thanks John for your tests. I wonder how this can slip quality control or beta tests. I will open another bug report.

[Marander]

Reported (Case LWB-4774) LW2019 deformation playback stutter (including additional information from John's tests).

[jwiede]

I wonder how this can slip quality control or beta tests.

Well, it would really help if LW provided better in the way of in-built visual or logged perf stats* on playback performance (some other pkgs provide it, and it's surprisingly useful). Without that, it's difficult to construct automated regression tests (ARTs) that can easily catch performance regressions.

It seems like there may be something broken/off w.r.t. LW2019 caching deformations, as well. I don't see any significant playback perf delta allowing the playback to loop multiple times. If deformation caching were working as expected, I'd expect subsequent loops through the same frames to play back significantly faster, but instead playback perf seems to remain consistent no matter how many times you let it loop.

@Jarno: Can you clarify how deformation caching is supposed to work in LW?

You'd mentioned LW now does some level of deformation caching, but if working, I'd expect behavior different from what I'm seeing. If you do a similar playback in other pkgs with deformation caching, the first time through a sequence is slow(er), but playback perf rises significantly (very perceivably) on subsequent loops over the same frames because its running directly from the pre-computed deformation cache.

*: Having a facility to capture per-frame times for various aspects of playback turns out to be very useful for ART purposes as well as user tuning/optimization of rig/deformation setups. The main trick is to stuff the per-frame perf data to memory during playback, then dump to log after, so that log access (typically slow) doesn't corrupt the perf timing.

- - - Updated - - -

Reported (Case LWB-4774) LW2019 deformation playback stutter (including additional information from John's tests).

Thanks!

[Marander]

Tested a rigged and mocap animated (rather low poly) character now and the result is the same. Smooth playback in 2018, extreme stuttering in 2019, even with subdivision disabled.

[Jarno]

Can you clarify how deformation caching is supposed to work in LW?

I don't think I ever said it does that kind of caching. What has changed is when the OpenGL mesh for a deforming object is regenerated. Previously it would regenerate on every redraw of the viewports (like having the GL Geometry Acceleration preference set to Streaming). Now it only regenerates when the deformation changes (which typically includes changing the current time).

As for the deformations being slower, I can't think of anything that has changed in the deformation system that would make it slower. Check your preferences to make sure they are the same in 2018 and 2019 for Display and GL.

My current guess is that something was changed in the viewport drawing that is causing the drawing to be interrupted and discarded earlier than previous. At various stages in the drawing code there are checks to see if the user is changing something (e.g. moving an object around, or changing the current time), and if so it stops drawing and resets with the changes incorporated. This keeps interaction reasonably immediate with minimal lag or inputs being dropped, but at the expense of visual feedback (because you don't see the partially completed frames).

---JvdL---

[next_n00b]

There is the difference, 2018 using all four cores on my iMac, while 2019 using only two. And 2018 is twice as fast.

[vipvip242]

There is the difference, 2018 using all four cores on my iMac, while 2019 using only two. And 2018 is twice as fast.

yes, i noticed it too with animated characters : 2019 much more slow than 2018 (win10-64)...

[next_n00b]

On my win7 16core the difference is even greater, exactly 1:6. LW 2018 is six times faster.

[jboudreau]

Hi

As I mentioned in another thread, navigation in a high poly scene is faster in LW2019. Overall OpenGL speed is still slower than other apps but well usable in most situations.

But... LW2019 deformations are way slower than in LW2018, at least with the deformers I tested (Bend, Twist for example).

Can someone confirm that's the case so I can (re-) open a bug ticket?

Hi I tested your scene and yes it is slower in 2019 vs 2018. Now the funny thing though is if you change your viewport to wireframe then the deformation go at the exact same speed in both LW2018 & LW2019

So it's definitely something in the OpenGL shaded performance causing this

I also noticed under prefercences / GL Tab if you change your Geometry Acceleration to Streaming instead of Buffered VBO then the deformation speed is now the same as LW2018 no more stuttering or slowness

Thanks,
Jason

[jboudreau]

I don't think I ever said it does that kind of caching. What has changed is when the OpenGL mesh for a deforming object is regenerated. Previously it would regenerate on every redraw of the viewports (like having the GL Geometry Acceleration preference set to Streaming). Now it only regenerates when the deformation changes (which typically includes changing the current time).

As for the deformations being slower, I can't think of anything that has changed in the deformation system that would make it slower. Check your preferences to make sure they are the same in 2018 and 2019 for Display and GL.

My current guess is that something was changed in the viewport drawing that is causing the drawing to be interrupted and discarded earlier than previous. At various stages in the drawing code there are checks to see if the user is changing something (e.g. moving an object around, or changing the current time), and if so it stops drawing and resets with the changes incorporated. This keeps interaction reasonably immediate with minimal lag or inputs being dropped, but at the expense of visual feedback (because you don't see the partially completed frames).

---JvdL---

Check out my post, It has something to do with the Geometry Acceleration Buffered VBO. If you set it to streaming instead of VBO then the stuttering and slowness is gone and it now plays back as fast as Lightwave 2018. Also if you set the viewport to wireframe and leave the Geometry Acceleration at it's default Buffered VBO it will play back at the same speed as LW2018

Hope this helps get to the bottom of this bug

Thanks,
Jason

[Marander]

Check out my post, It has something to do with the Geometry Acceleration Buffered VBO. If you set it to streaming instead of VBO then the stuttering and slowness is gone and it now plays back as fast as Lightwave 2018. Also if you set the viewport to wireframe and leave the Geometry Acceleration at it's default Buffered VBO it will play back at the same speed as LW2018

Hope this helps get to the bottom of this bug

Thanks,
Jason

Thanks, these are interesting findings and help isolating (and in the mean time mitigating) the issue!

I will let you know what the outcome of the bug report is.

[OFF]

Run with FRAPS:
lw2018, VSync on = 12 fps; VSync off = 15 fps
lw2019, VSync on = 3 fps (!!!), VSync off = 12 fps