PDA

View Full Version : Modeler 2018 surface preset creation crash, etc.?



jwiede
04-01-2018, 05:35 PM
In Modeler 2018 (Mac64, on 10.13.3), when I open the preset shelf, and then try to create a surface preset (using "Save to Preset Shelf"), Modeler puts up a dialog asking which viewport to use as image. Upon selection, Modeler either creates a preset with an "empty" image, or (>50% of the time) crashes to desktop. When the first attempt creates an (empty-image) preset, the second attempt reliably crashes to desktop.

Can anyone else replicate this behavior?

rsfd
04-02-2018, 08:17 AM
Cannot replicate the crashing issue here (2018.0.3 / 10.11.6), but I can confirm that sometimes a "generic" preset icon is created.

Other than that, this command seems to have a problem with creating the preview image from the correct viewport: left/right, up/down is mostly being mistaken (at least here in "Quad", "Double Vertical" and "2 Left, 1 Right" - the Layouts that I've quickly tested).

jwiede
04-04-2018, 01:07 AM
Interesting. What OpenGL "shading type" are you using in 2018 (multitexture, GLSL, or PBRGLSL), and streaming or VBO? Also, what type of gfx hw?

I'm running LW(64) on 10.13.3, and regardless of shading type (multitexture, GLSL or PBRGLSL) or streaming/VBO, I'm getting reliable crashes. I'm running an Nvidia 980Ti.

LW appears to be attempting a read back from a GL buffer either not set for or improperly set for read back, based on what's going on in OpenGL/sys asm at crash, but still trying to pin down specifics.

Unfortunately, it's also likely this won't affect 10.11.x quite the same way, because 10.11.x handled OpenGL draw buffers a bit differently from 10.12.x and later. Can anyone reading this, and running LW on 10.12.x or 10.13.x, check whether the crash occurs for them?

Here's the precise steps I use:

1. Launch Modeler 2018.0.3
2. Create arbitrary-sized 3D ball.
3. Open Surface Editor
4. (optional) Change ball's Defauilt PBSDF material color to arbitrary color
5. (optional) Rename ball's surface from Default to arbitrary name
6. Select "Save to Preset Shelf" from Preset drop-down menu, select any viewport in subsequent dialog

After selecting viewport, I get crash to desktop around 80-90% of the time. Rarely will create an "empty"-image preset, when it does repeating steps 3-6 LW 100% reliably (thus far anyway) causes subsequent crash to desktop.

rsfd
04-04-2018, 03:32 AM
Hello jwiede,

I'm using PBRGLSLShaders in Buffered (VBO) mode.
Hardware is a simple GTX650Ti-2GB (unflashed PC-GPU) with Nvidia Web Drivers (346.03.15f12) in a MP3,1.
(Former installed CUDA Driver removed from system meanwhile).

Based on your statements, I've quickly changed into "Streaming" mode and realized the "Viewport Turbulences" were gone.
Better then that: going back to VBO and Modeler still does it correct now… thanks for that one ;)

Hope you get it sorted and others will give you valuable input here.

jwiede
04-04-2018, 08:29 PM
Hope you get it sorted and others will give you valuable input here.

I'm probably just going to go ahead and file the bug, it's fairly obvious from the stack trace, register state, OGL/driver state, etc. what's occurring. Unfortunately, "fixing" it will cause a serious performance hit for LW viewports OpenGL performance -- marking buffers as read-back-capable means they must be coherency-tracked, synchronized, etc. which is very perf. costly.

No clue why they chose to read-back from OpenGL draw buffer for preset generation, but it'd be HIGHLY beneficial if they found some other way of generating a preset image.

rsfd
04-07-2018, 04:33 AM
oh, would that mean that viewports would be slowed down constantly, or just while preset generation?
(Other than you, I don't have a programming background)

If a fix would result in a OGL performance drop for all users: would you probably consider to use the Surface Preview in Layout for Material Preset generation? ;)
(I never used Modeler for final surfacing, but I can truly recommend Surface Preview in Layout for that task. As it uses VPR, the Preview images -to me at last- are much more meaningful anyway).

nic98
04-08-2018, 07:18 AM
Interesting. What OpenGL "shading type" are you using in 2018 (multitexture, GLSL, or PBRGLSL), and streaming or VBO? Also, what type of gfx hw?

I'm running LW(64) on 10.13.3, and regardless of shading type (multitexture, GLSL or PBRGLSL) or streaming/VBO, I'm getting reliable crashes. I'm running an Nvidia 980Ti.

LW appears to be attempting a read back from a GL buffer either not set for or improperly set for read back, based on what's going on in OpenGL/sys asm at crash, but still trying to pin down specifics.

Unfortunately, it's also likely this won't affect 10.11.x quite the same way, because 10.11.x handled OpenGL draw buffers a bit differently from 10.12.x and later. Can anyone reading this, and running LW on 10.12.x or 10.13.x, check whether the crash occurs for them?

Here's the precise steps I use:

1. Launch Modeler 2018.0.3
2. Create arbitrary-sized 3D ball.
3. Open Surface Editor
4. (optional) Change ball's Defauilt PBSDF material color to arbitrary color
5. (optional) Rename ball's surface from Default to arbitrary name
6. Select "Save to Preset Shelf" from Preset drop-down menu, select any viewport in subsequent dialog

After selecting viewport, I get crash to desktop around 80-90% of the time. Rarely will create an "empty"-image preset, when it does repeating steps 3-6 LW 100% reliably (thus far anyway) causes subsequent crash to desktop.

I don't have this problem at all on a mac mini 2014 2.6ghz.
I'm using 10.12.6. I did not rename the default.

jwiede
04-11-2018, 07:31 PM
I don't have this problem at all on a mac mini 2014 2.6ghz.
I'm using 10.12.6. I did not rename the default.

Interesting, what kind of graphics do you have, and how much VRAM (if any) is present?

rsfd
04-12-2018, 02:20 AM
the actual Mac mini 2014 (Macmini7,1 / 2,6 GHz) uses a Intel Iris 5100 onboard graphic with a maximum of 1,5 GB shared memory.
Default RAM is 8 GB, maximum BTO option is 16 GB.

jwiede
04-12-2018, 09:24 AM
the actual Mac mini 2014 (Macmini7,1 / 2,6 GHz) uses a Intel Iris 5100 onboard graphic with a maximum of 1,5 GB shared memory.
Default RAM is 8 GB, maximum BTO option is 16 GB.

Ah, yeah, that explains it: Your gfx uses a "shared memory"/"UMA" architecture w.r.t. VRAM. Because VRAM is same as CPU-accessible memory in a shared-memory/UMA architecture, you can't really replicate the same situation where something can be in VRAM that isn't mapped/accessible to the CPU. In your architecture, all memory whether used as "VRAM" or not, always remains accessible to the CPU.

jwiede
04-12-2018, 09:48 AM
oh, would that mean that viewports would be slowed down constantly, or just while preset generation?
(Other than you, I don't have a programming background)

Difficult to say, depends on how LW "assembles" OpenGL internally. Worst-case, viewports would need to always be kept in read-back-capable VRAM, which hurts perf. because requires extra access synchronization. OTOH, best-case, if the preset process could someone just change the viewport OpenGL to only mark its buffer as read-back-capable when presets are being created, the perf. hit could theoretically be minimal. I'm guessing based on what we're seeing that reality is closer to worst-case than best-case.


If a fix would result in a OGL performance drop for all users: would you probably consider to use the Surface Preview in Layout for Material Preset generation? ;)
(I never used Modeler for final surfacing, but I can truly recommend Surface Preview in Layout for that task. As it uses VPR, the Preview images -to me at last- are much more meaningful anyway).

The problem is that there are surfacing-related workflows in Modeler which benefit from being able to see a preview of the final surface (think UV editing, and other texture projection changes, for example). Having surfacing be something where previews can only be done in Layout is, as multiple here have mentioned, a workflow problem. Not everyone surfaced solely in Layout previously, just telling everyone they must do so now will alienate more customers.

Further, anything which forces additional Modeler<->Layout round-trips is generally negative for Lightwave users, exacerbating a specific workflow problem that exists for Lightwave but not for other apps. There's been serious ongoing efforts to REDUCE the number of Modeler<->Layout round-trips users must endure to minimize negative impact on users, adding more is counter-productive to that effort (worsening the issue).

rsfd
04-12-2018, 03:43 PM
Ah, yeah, that explains it: Your gfx uses…
It's not mine, it's from nic98. It just happened that I came across this thread again and thought I can quickly post these infos so that you eventually don't have to wait too long…


Difficult to say, depends on how LW "assembles" OpenGL internally. …
ok, I see. Well let's see what the LW-Dev Team comes up with to fix this issue.


The problem is that there are surfacing-related workflows in Modeler which benefit from being able to see a preview of the final surface …
I thought that, as long as one is at least able to see a good representation of a Surface, UV aso. in OGL all would be fine. Of course, saving a Preset must be possible without crashes, but I thought that it would disturb you not to get a Preset Icon/Image while saving. (Because of their size, I never found the Preset Icons/Images in the Browser very meaningful).

But I'm not that affected by all this because I had switched very quickly to Modo for all "Mesh operations", because I found Modeler at the 9.5/9.6 beta times to be a pretty bad performing application and even I do like Layout 2018 a lot, I doubt again that I will ever use Modeler for modeling/UVing aso, as it still seems quite ponderous to me and I'm of course much more related to the use of Modo (and also do prefer to work in single perspective view which doesn't exactly seem the way Modeler is made for). If I quit with Modo because of the Subscription model that Foundry introduced, it even might be that I'll try to add Blender to my workflow instead of wrangling with Modeler. (Next Blender release is hopefully a bit easier to use for those who aren't raised with Blender's somewhat "unique" workflow and UI).