Hey juan
OK so i gota a character rigged (genoma) and animated,
All looks just fine in open gl, nothings sliding out of place during motions and deformations or off centered.
Each frame verified in wireframe mode. no errors in geometry position.
Theirs also no issues with weight mapping, for the head region.
But upon rendering, with the use of motion blur, the characters eyes are rendered coming out of position, often preceding the motion of the parent.
Theirs no geometry dynamics like Bullet applied to the object either. just simple bones parenting and ik rig.
My facial morphs *do not* shift the head out of position especially the eye sockets.
seen something like this before?
Animated object update glitch.. LW 2020 OCt 2020.1.2.0
Moderator: juanjgon
Are the eyes LW cloned objects? Perhaps you could try to disable the "Instance LW Clones" option in the render target root node options panel. Also, you could try to render the scene in "full scene reload" mode to check if it helps.
If nothing works, can you please send me the scene to take a look at it here?
Thanks,
-Juanjo
If nothing works, can you please send me the scene to take a look at it here?
Thanks,
-Juanjo
-
xevious2501
- Posts: 31
- Joined: Mon Sep 02, 2013 4:23 am
The eyes are a duplicate, not an instance clone.
And yes i just tried full scene reload which worked with at least the test render.
so im now rendering the entire scene. HOPEFULLY this works for all frames.
Im not sure if this is a LW issue or octane, but ultimate octane is only rendering what information its given, so i would guess somehow LW.
(which unfortunately isnt at all unusual)
Ive always thought of LW's internal programming as a crank and churn system. meaning unlike applications like maya and even C4d which at least to my thinking, has an independent live system governing operater that keeps all of the applications features settings and functions in an active live state. While lightwave only keeps parts of its render buffer live in memory and everything else is basically written to a status file, and only gets updated when the frame is refreshed. This which i imagine is how LW was designed to operate from its inception on the Amiga. Because its not like the Amiga had so much internal memory to store such information in an active buffer. This would also explain why LW was so prone to crashing, forcing all its feature and plugins to update and make loads of calculations upon that refresh, even toggling from frame to frame, I believe that was the outstanding problem even when its code was ported over to the PC. It really needed to be re-written from the ground up. At least this is what i was assuming was happening under the hood, And it would also explain such 'glitches' today.
Anyways ill let you know the end results of the render.
Im also finding that scenes ive created in 2015.3 and then bring over to 2020 goes from scrollable fast, to bottle neck slow. All features the same but something is causing the scenes in Layout to completely bottleneck in speed.
And LW 2020 is suppose to be blistering fast no matter what. very interesting stuff.
And yes i just tried full scene reload which worked with at least the test render.
so im now rendering the entire scene. HOPEFULLY this works for all frames.
Im not sure if this is a LW issue or octane, but ultimate octane is only rendering what information its given, so i would guess somehow LW.
(which unfortunately isnt at all unusual)
Ive always thought of LW's internal programming as a crank and churn system. meaning unlike applications like maya and even C4d which at least to my thinking, has an independent live system governing operater that keeps all of the applications features settings and functions in an active live state. While lightwave only keeps parts of its render buffer live in memory and everything else is basically written to a status file, and only gets updated when the frame is refreshed. This which i imagine is how LW was designed to operate from its inception on the Amiga. Because its not like the Amiga had so much internal memory to store such information in an active buffer. This would also explain why LW was so prone to crashing, forcing all its feature and plugins to update and make loads of calculations upon that refresh, even toggling from frame to frame, I believe that was the outstanding problem even when its code was ported over to the PC. It really needed to be re-written from the ground up. At least this is what i was assuming was happening under the hood, And it would also explain such 'glitches' today.
Anyways ill let you know the end results of the render.
Im also finding that scenes ive created in 2015.3 and then bring over to 2020 goes from scrollable fast, to bottle neck slow. All features the same but something is causing the scenes in Layout to completely bottleneck in speed.
And LW 2020 is suppose to be blistering fast no matter what. very interesting stuff.