LW2020 + Plugins

[Thomas Leitner]

The rig works, because I've used RH2 rigged character in 2020, but to edit, you're going to have to go back to 2019, until the code is patched. Then it's a matter of time before it breaks again, but hopefully by then Rhiggit 3, written in Python, will be available...

I can dream, can't I?

Hi,
did I miss something?
LScript is still included with LW 2020. Why shouldn't Rhiggit be working anymore?
They will remove it in a future release:

First, while the LScript language will continue to be included with LightWave, its code will no longer receive updates or bug fixes; and second, the LScript system will be removed from LightWave in a later, to-be-determined release.

ciao
Thomas

 

[Kryslin]

Rhiggit2 isn't working right now not because of LScript being removed from LW, but because they changed the data template for the LW_ItemShape plugin, which Rhiggit uses to add item shapes automatically to all the nulls.

And because RH has been under the weather of late, who knows when a fix is coming... As has been said elsewhere, if you need to set up and/or edit a rig, you'll need to do it in 2019.1.5 or lower.

 

[Thomas Leitner]

New Build 1460 of TurbulenceFD adds support for LW2020.

I tested in LW2020.0.1. The lights seem to illuminate the smoke correct now.

ciao
Thomas

 

[mch]

New Build 1460 of TurbulenceFD adds support for LW2020.

I tested in LW2020.0.1. The lights seem to illuminate the smoke correct now.

ciao
Thomas

Hi Thomas !

I also tested TFD build 1460 which solves the crashes with VPR, F9 and F10 renderings.

LW 2020.0.0 und LW 2020.0.1 on Win Pro 10.

Still some problems remain as LW freezes when using Abort Render.
Also some scenes render only every second frame like Jaschas simple explosion sample scene.
Numbering 002, 004, 006 … 130 (instead of 001, 002, 003…).
Rendering only 65 of 130 frames stating 50% sequence and freezing LW.
Some images are missing smoke and have different brightness.

Regards

Marcus

 

[jwiede]

Hi Thomas !

I also tested TFD build 1460 which solves the crashes with VPR, F9 and F10 renderings.

LW 2020.0.0 und LW 2020.0.1 on Win Pro 10.

Still some problems remain as LW freezes when using Abort Render.
Also some scenes render only every second frame like Jaschas simple explosion sample scene.
Numbering 002, 004, 006 … 130 (instead of 001, 002, 003…).
Rendering only 65 of 130 frames stating 50% sequence and freezing LW.
Some images are missing smoke and have different brightness.

That sounds basically unusable. Are you using TFD in GPU mode, or CPU mode? Does using the other mode mitigate any of those issues?

 

[Markc]

New Build 1460 of TurbulenceFD adds support for LW2020.

I tested in LW2020.0.1. The lights seem to illuminate the smoke correct now.

ciao
Thomas

As usual this is only for Windows.

 

[jwiede]

As usual this is only for Windows.

Doesn't sound so great for them either.

 

[mch]

That sounds basically unusable. Are you using TFD in GPU mode, or CPU mode? Does using the other mode mitigate any of those issues?

TFD simulation was done in GPU mode with nVidia GTX 1080 and studio drivers in my tests.
The simulation has the full 130 frames of the sample scene.

I did try CPU mode now. The cache has also 130 frames.
Rendering makes no difference. Skipping frames numbered 002, 004, 006...

Rendering with LW2020 native renderer (CPU).

Shouldn't it be the the same for the rendering if the sim was GPU or CPU ?
Using the existing cache for each image ?

I can do F9 renders for each frame left out in the F10 renders.

Regards
Marcus

 

[jwiede]

TFD simulation was done in GPU mode with nVidia GTX 1080 and studio drivers in my tests.
The simulation has the full 130 frames of the sample scene.

I did try CPU mode now. The cache has also 130 frames.
Rendering makes no difference. Skipping frames numbered 002, 004, 006...

Rendering with LW2020 native renderer (CPU).

Ah, okay, that's unfortunate, was hoping issue was maybe confined to one engine path or the other.

Shouldn't it be the the same for the rendering if the sim was GPU or CPU ?
Using the existing cache for each image ?

Depends on precisely how TFD interacts with LW during rendering, and how events are handled -- GPU and CPU should be same for efficiency reasons in that regard, but not impossible they were different (though appears not). Sounds like TFD might be dropping/ignoring every other "frame change event" or such, but difficult to say without real debugging.

When you say it "skips" the frames, do they not render at all, render without TFD elements, or...?

I can do F9 renders for each frame left out in the F10 renders.

Sure, but that's not really efficient/workable for any significant scale of animation. Hopefully Jascha fixes it soon!

 

[mch]

When you say it "skips" the frames, do they not render at all, render without TFD elements, or...?

The frames are left out on F10 renders.
Numbering is 002, 004, 006 . . . . 130, but only 65 of 130 frames rendered.
Every second frame.

 

[Thomas Leitner]

When you say it "skips" the frames, do they not render at all, render without TFD elements, or...?

The frames are left out on F10 renders.
Numbering is 002, 004, 006 . . . . 130, but only 65 of 130 frames rendered.
Every second frame.

Hi,
I did a quick test with Jaschas simple explosion sample scene, too.
It behaves very strange.

I did other scenes with TFD and it work as expected. I do not know if it is a TurbulenceFD or a Lightwave 2020 thing.

ciao
Thomas

 

[Markc]

The frames are left out on F10 renders.
Numbering is 002, 004, 006 . . . . 130, but only 65 of 130 frames rendered.
Every second frame.

Reference to my post #57, I had this in an earlier build with the Simple explosion.
Try the Flamethrower scene, that rendered all frames for me.

 

[Thomas Leitner]

The frames are left out on F10 renders.
Numbering is 002, 004, 006 . . . . 130, but only 65 of 130 frames rendered.
Every second frame.

Hi,
I looked into it again.
The problem disapears when you disable "Simulate while rendering scene" in the Fluid Container properties.
I rendered the whole sequence whitout any error.

ciao
Thomas

 

[mch]

Hi,
I looked into it again.
The problem disapears when you disable "Simulate while rendering scene" in the Fluid Container properties.
I rendered the whole sequence whitout any error.

ciao
Thomas

Hi Thomas !

Thanks for testing this !

I can confirm.
Unchecking "Simulate while rendering scene" in the Fluid Container solves the sequence rendering issue.
Now rendering is complete without any frame skipping.
No more LW freezing.

Regards
Marcus


P.S.: BTW - Nice VFX work !

 

[Marander]

.

 

[Markc]

Mac users FYI:
TFD 1443 seems to work in Mojave, didn't activate it, but menu branches all loaded.
I found adding this version in HS no menu branches would load.

Upgraded to Mojave and latest Mac build (1443) of TFD works.

 

[next_n00b]

I have sent this bug report to jawset yesterday;
"In the last LW TFD bild 1460 (on Windows 7) I have noticed that the “Fluid Container - Smoke Mapping” window freezes the whole Layout when editing curves with VPR enabled. LW TFD 1439 seems to work OK in the same situation."

 

[Markc]

This sounds similar to the Mac version, where it only works on newer OS.
1460 for Windows probably needs win 8.

 

[Markc]

New issues with StarPro 2.3 in 2020.0.2.
I can render stars in a blank scene, but if there is something in the scene and I add StarPro, I just get lines.
Even tried adding stars, then load items from scene into it, same result......

 

[scallahan1]

Weird,

Running StarPro 2.3 here and 2020.0.2. Just whanged together a quickie test. Added StarPro first, then added 3 silly objects and hit render. Perhaps it's doing this only on Macs?

View attachment 149133

Steve

PS> And of course I turned off the default "backdrop" with the gradient.