PDA

View Full Version : LW 2018 .0.5 transparency not visible in viewport



genesis1
07-11-2018, 08:14 AM
Probably missing something but when I turn on a transparency for something like clear pipe or glass, in the viewport it vanishes completely. Normal in previous versions I still see it semi transparent. Transparancy is ticked in preferences for GL.

MonroePoteet
07-11-2018, 09:53 AM
This seems to work correctly for me in LW 2018.0.5:

142188

The red sphere is a Principled BSDF material with 90% Transparency and the blue sphere is a Standard material, 50% Transparent.

mTp

P.S. It also works fine for me in Modeler:

142189

genesis1
07-11-2018, 10:13 AM
This seems to work correctly for me in LW 2018.0.5:

142188

The red sphere is a Principled BSDF material with 90% Transparency and the blue sphere is a Standard material, 50% Transparent.

mTp

P.S. It also works fine for me in Modeler:

142189

Something weird not working. I loaded my cyber head into modeler. Looks fine so send it over to layout and it looks fine. Then soon as I move round in perspective view the pipes vanish and the chin vanishes and can no longer be viewed in viewport but can be seen in vpr.

genesis1
07-11-2018, 10:23 AM
142191142190

This is what happens when first sent from modeler. Soon as you move around the object in viewport the pipe's and chin vanish. If I change subpatch level then it reapers until I move view again. Never had a problem like this in previous versions of LW.

Ma3rk
07-11-2018, 11:04 AM
It's not some quirk with the Display Preferences Fixed Near Clip Distance is it? I had to turn that off but don't think I had Sub-D items.

genesis1
07-11-2018, 11:12 AM
It's not some quirk with the Display Preferences Fixed Near Clip Distance is it? I had to turn that off but don't think I had Sub-D items.

Nope that's off. Just updated my graphics driver and still no change. No idea what's going on. Only thing I can think off is this was created in LW 11.6.3 and 2018 converted it. So maybe it's a problem linked to that.

MonroePoteet
07-11-2018, 11:21 AM
Yes, definitely a bug in viewport rendering in LW2018.0.5. Attached is a reproducer scene.

Interestingly enough, if ALL surfaces are somewhat transparent, they all show up. If ANY surface has a 0.0% Transparency, then surfaces with non-zero transparency disappear.

In the sample scene, all three surfaces have non-zero Transparency, and the Perspective viewport can be rotated with all surfaces visible. Changing any of the surfaces to have 0.0% Transparency causes the non-zero transparency surfaces to vanish in the viewport.

The easy way to recover their visibility (temporarily) is to use the Modeler Tools=>Toggle Subpatch button, which refreshes the viewport with all surfaces showing. The problem persists whether subpatches are on or off.

Setting the 0.0% Transparency surface back to non-zero, refreshing with Toggle Subpatch causes them all to appear again even after the viewport is updated. Here's the sequence, using ALT-right-mouse-drag in the viewport to rotate it for each test:

142192 All Surfaces non-zero Transparency, even after rotating viewport
142193 Set BluePatch to 0.0% Transparency, before rotating viewport
142194 After rotating viewport
142195 After pressing Toggle Subpatch
142197 Set BluePatch back to 50.0%, before Toggle Subpatch
142198 All Surfaces non-zero again, after Toggle Subpatch and rotating viewport

Do you want to submit a Bug Report, or shall I?

mTp

Axis3d
07-11-2018, 11:22 AM
Nope that's off. Just updated my graphics driver and still no change. No idea what's going on. Only thing I can think off is this was created in LW 11.6.3 and 2018 converted it. So maybe it's a problem linked to that.

Was your object originally a .OBJ? I have come across an issue in the past when an .OBJ is brought into LW, the default surface is not named correctly. In Modeler, hit 'q' and just give it a new default surface and then save it. See if it now works in Layout.

MonroePoteet
07-11-2018, 11:23 AM
Axis3D and I cross posted - it's a bug. See my prior post:

https://forums.newtek.com/showthread.php?157564-LW-2018-0-5-transparency-not-visible-in-viewport&p=1550551&viewfull=1#post1550551

The object used in the test was created from scratch in LW2018.0.5 Modeler and surfaced natively.

mTp

genesis1
07-11-2018, 11:28 AM
Yes, definitely a bug in viewport rendering in LW2018.0.5. Attached is a reproducer scene.

Interestingly enough, if ALL surfaces are somewhat transparent, they all show up. If ANY surface has a 0.0% Transparency, then surfaces with non-zero transparency disappear.

In the sample scene, all three surfaces have non-zero Transparency, and the Perspective viewport can be rotated with all surfaces visible. Changing any of the surfaces to have 0.0% Transparency causes the non-zero transparency surfaces to vanish in the viewport.

The easy way to recover their visibility (temporarily) is to use the Modeler Tools=>Toggle Subpatch button, which refreshes the viewport with all surfaces showing. The problem persists whether subpatches are on or off.

Setting the 0.0% Transparency surface back to non-zero, refreshing with Toggle Subpatch causes them all to appear again even after the viewport is updated. Here's the sequence, using ALT-right-mouse-drag in the viewport to rotate it for each test:

142192 All Surfaces non-zero Transparency, even after rotating viewport
142193 Set BluePatch to 0.0% Transparency, before rotating viewport
142194 After rotating viewport
142195 After pressing Toggle Subpatch
142197 Set BluePatch back to 50.0%, before Toggle Subpatch
142198 All Surfaces non-zero again, after Toggle Subpatch and rotating viewport

Do you want to submit a Bug Report, or shall I?

mTp

I'll let you send the bug report. Glad I'm not the only one. Thought I was going crazy! ��

Axis3d
07-11-2018, 11:37 AM
I'll let you send the bug report. Glad I'm not the only one. Thought I was going crazy! ��

Definitely related to sub-patching. Not crazy.

MonroePoteet
07-11-2018, 11:53 AM
Bug report submitted.

mTp

genesis1
07-11-2018, 12:08 PM
Thanks. Yes you are right. I can reproduce exactly the same result.

MonroePoteet
07-11-2018, 12:49 PM
Here's the response from LWDG, which does indeed resolve the issue on the sample scene.

142200

mTp

------------------------------------------------------------------------------------------

From: Deuce
Date: July 11, 2018, 10:59 a.m.
This is where the "complexity of the scene" can't be totally handled by Buffered Geometry Acceleration.

If you change to "streaming" - all works as you'd expect.

Thank you for your report.
--
LightWave 3D Group Support

[email protected]

genesis1
07-11-2018, 01:25 PM
Here's the response from LWDG, which does indeed resolve the issue on the sample scene.

142200

mTp


------------------------------------------------------------------------------------------

From: Deuce
Date: July 11, 2018, 10:59 a.m.
This is where the "complexity of the scene" can't be totally handled by Buffered Geometry Acceleration.

If you change to "streaming" - all works as you'd expect.

Thank you for your report.
--
LightWave 3D Group Support

[email protected]

Thanks for posting. Will change to streaming. However ,your example scene isn't complex so don't know why LW2018 can't handle it when 11.6.3 can manage it. Tbh I'm not finding anything benefiting me in 2018 yet except a more stable fiber fx. 😞

jwiede
07-11-2018, 10:05 PM
That answer doesn't make sense. Whether the geometry is transferred within VBOs (via DMA), or streamed via sending primitives down the pipe (typically PIO), is orthogonal to how the surfaces (shaders) applied to the geometry sets are handled.

It also fails to acknowledge that VBO-hosted geometry offers major performance benefits over streaming geometry in modern graphics hardware. Being forced to use streaming geometry transfers for cases when multiple transparency states are present has a significant impact when dealing with large, complex geometry data sets.

I've attached a (private) link to a video of Layout 2018.0.5 manipulating a 3M-poly object using both VBO and streamed geometry modes, and the difference is fairly stark. Though the video may not show it clearly, using VBO-hosted geometry the model rotates smooth as silk (unsurprisingly), but using streamed geometry it's a slideshow (and not a particularly fast slideshow, either).

Forcing us to use streamed geometry with multi-transparency surfacing cases is a significant issue that needs to be fixed. There's no intrinsic OpenGL reason VBOs can't deal with surfacing like that any different from streamed geometry, the shaders don't really care how the geometry data gets into VRAM. The current limitation just makes working in LW even less pleasant for folks working with large/complex geometry data sets.

https://vimeo.com/279596795/b0ac2467f2

genesis1
07-12-2018, 01:32 AM
That answer doesn't make sense. Whether the geometry is transferred within VBOs (via DMA), or streamed via sending primitives down the pipe (typically PIO), is orthogonal to how the surfaces (shaders) applied to the geometry sets are handled.

It also fails to acknowledge that VBO-hosted geometry offers major performance benefits over streaming geometry in modern graphics hardware. Being forced to use streaming geometry transfers for cases when multiple transparency states are present has a significant impact when dealing with large, complex geometry data sets.

I've attached a (private) link to a video of Layout 2018.0.5 manipulating a 3M-poly object using both VBO and streamed geometry modes, and the difference is fairly stark. Though the video may not show it clearly, using VBO-hosted geometry the model rotates smooth as silk (unsurprisingly), but using streamed geometry it's a slideshow (and not a particularly fast slideshow, either).

Forcing us to use streamed geometry with multi-transparency surfacing cases is a significant issue that needs to be fixed. There's no intrinsic OpenGL reason VBOs can't deal with surfacing like that any different from streamed geometry, the shaders don't really care how the geometry data gets into VRAM. The current limitation just makes working in LW even less pleasant for folks working with large/complex geometry data sets.

https://vimeo.com/279596795/b0ac2467f2

Yes I have to agree. I noticed a considerable impact on viewport performance for streaming. VBO is faster and smoother. Also the explenation of this only happening on a poly heavy scene is not true.
In the example given above of a simple subpatched sphere this still occurs.
This is a major bug that needs fixing. Switching to streaming maybe a temporary fix for now but not a satisfactory one long term.
All in all at the moment this new Lightwave is proving to be a slower version than before. Takes longer to set up shaders, takes longer to render and vpr takes longer.
The model I am using at present renders in about 3 seconds in vpr in LW 11.6.3 but takes around a minute in LW2018. I'm also having to fiddle with node shaders a lot to get rid of unwanted speckles in LW2018.
I know I have to get used to this new lighting and shading system but at present I'm not seeing much benefit. I finding I'm jumping back to 11.6.3 for getting things done quicker at the moment which is a bit dissapointing.
Maybe as I learn more about LW2018 this will change, hopefully.

MonroePoteet
07-12-2018, 08:16 AM
Yes, this is a regression and should be addressed. I re-created the reproducer object in LW11.6.3 and Layout does NOT demonstrate the flaw. Load the scene in LW2015, the flaw is not present.

I added the information to the Case and requested that it be re-opened as a regression, indicating that VBO acceleration is essential in complex models so the regression should be addressed.

mTp

P.S. the case has been re-opened and will be "assigned to the proper developer for assessment".

genesis1
07-12-2018, 11:25 AM
Yes, this is a regression and should be addressed. I re-created the reproducer object in LW11.6.3 and Layout does NOT demonstrate the flaw. Load the scene in LW2015, the flaw is not present.

I added the information to the Case and requested that it be re-opened as a regression, indicating that VBO acceleration is essential in complex models so the regression should be addressed.

mTp

P.S. the case has been re-opened and will be "assigned to the proper developer for assessment".

Glad to hear this is being looked at again. VBO is essential in viewport as you say and have to agree this is a regression.
Lightwave is always advertised as a product for getting things done quickly and this is only adding to the thought that it is getting slower in its production. 8~

jwiede
07-12-2018, 12:56 PM
P.S. the case has been re-opened and will be "assigned to the proper developer for assessment".

I just hope that hasn't become the Newtek equivalent of "Real Soon Now".

On the plus side, it shouldn't be that difficult to reconfigure the code that assembles the viewport OGL to handle either VBO-hosted or streamed geometry equally well. I'd be more than happy to help them reconfigure the code, as needed.

It'd be even better if we could get back the ability to use CgFX shaders again as well (perhaps as custom OpenGL Material?).

genesis1
07-27-2018, 03:26 PM
Has there been anymore word on resolving this by Newtek?