PDA

View Full Version : Layout Geometry Handling Capacity



erikals
05-17-2018, 11:56 AM
Layout can now handle massive amounts of geometry
has a Render Engine that can be compared to Arnold
Comes with 1000 render nodes
Finally has a new rewritten Geometry Engine
has a nice upgrade price, and no damn subscription


LightWave lacks stuff, i get it, and i agree, we all agree
but painting the wall all black seems a bit ridiculous...

https://i.imgur.com/KF4CTYY.png

Marander
05-17-2018, 12:00 PM
Layout can now handle massive amounts of geometry

No it can't due to the OpenGL limitation / bottleneck, other apps don't have this issue

I agree on the subscription part tough, that's a no go for me.

Ztreem
05-17-2018, 12:07 PM
Layout can now handle massive amounts of geometry
has a Render Engine that can be compared to Arnold
Comes with 1000 render nodes
Finally has a new rewritten Geometry Engine
has a nice upgrade price, and no damn subscription


LightWave lacks stuff, i get it, and i agree, we all agree
but painting the wall all black seems a bit ridiculous...

https://i.imgur.com/KF4CTYY.png

Lol! Yes, in half the app it can handle more geometry. I donít know if it actually hadles more than any other app.

Chris S. (Fez)
05-17-2018, 02:36 PM
No it can't due to the OpenGL limitation / bottleneck, other apps don't have this issue



I hope this is not the case. Did the geo engine not address this? As discussed previously, it's odd that the 2018 marketing material mentions nothing about improved performance. I hope the power and potential of the new engine is more obvious in the next release.

Layout in 2018 is much faster than Modo on my machine and at least as fast as Max for most reasonably large scenes.

As for Modeler, I wonder if the original rumored vision of Layout ultimately becoming Modeler still applies.

SBowie
05-17-2018, 03:59 PM
I hope this is not the case. Did the geo engine not address this? As discussed previously, it's odd that the 2018 marketing material mentions nothing about improved performance. I hope the power and potential of the new engine is more obvious in the next release.

Layout in 2018 is much faster than Modo on my machine and at least as fast as Max for most reasonably large scenes.

As for Modeler, I wonder if the original rumored vision of Layout ultimately becoming Modeler still applies.I think it might be a kindly gesture to spawn this discussion off into a new thread of its own, hmmm? Thanks.

[Done. You're welcome! :devil:]

Chris S. (Fez)
05-17-2018, 04:15 PM
I think it might be a kindly gesture to spawn this discussion off into a new thread of its own, hmmm? Thanks.

Yup. Apologies.

Marander
05-17-2018, 04:27 PM
I hope this is not the case. Did the geo engine not address this? As discussed previously, it's odd that the 2018 marketing material mentions nothing about improved performance. I hope the power and potential of the new engine is more obvious in the next release.
...

Yes unfortunately thats the case.

Chris, I have noticed this several times before, you're the most neutral and fact based person to me when its about talking of LWs strenghts and weaknesses, somebody like you should be ideally review the application (to be back on topic LOL).

Chuck
05-17-2018, 05:17 PM
No it can't due to the OpenGL limitation / bottleneck, other apps don't have this issue

I agree on the subscription part tough, that's a no go for me.

I have to admit I was away from LightWave in TriCasterland for so long this doesn't ring a bell, though it sounds like you are referring to a long-standing issue. Can you refresh me on this? And is there a case number or report from you I could check into and nudge the developers about?

Chuck
05-17-2018, 05:19 PM
Oh and yep, I copied a bunch of posts to this new thread cuz I wanted to follow-up on the topic. Phenomenal cosmic power at work. ;)

VonBon
05-17-2018, 08:10 PM
Wouldn't it depend on the Hardware setup?

erikals
05-17-2018, 11:53 PM
hi Chuck,

LightWave plugin developer Jay3d knows a bit more about this >
http://forums.newtek.com/showthread.php?156906-Metamorphic-for-LightWave-2018-(AnimatedSculpt-previously)&p=1546010&viewfull=1#post1546010


Wouldn't it depend on the Hardware setup?
not necessarily

Marander
05-18-2018, 12:39 AM
I have to admit I was away from LightWave in TriCasterland for so long this doesn't ring a bell, though it sounds like you are referring to a long-standing issue. Can you refresh me on this? And is there a case number or report from you I could check into and nudge the developers about?

Hello Chuck, thanks for picking this up. I have noticed the OpenGL sub par performance when loading some of my existing high poly scenes and the same thing again using the new Metamorphic plugin. Currently away from computer but I can do some tests later today.

Marander
05-18-2018, 04:11 AM
Wouldn't it depend on the Hardware setup?

Not when OpenGL runs smooth in other apps with similar or more enhanced viewport settings.

My hardware setups are 8-12 core systems with 64GB RAM, GF1080 and Dual GF970GTX, so that should be sufficient.

Asticles
05-18-2018, 04:29 AM
To me is working better than Modo and Blender.

VonBon
05-18-2018, 08:11 AM
Trying to get a better understanding of what you Brainiacs are talkn bout.
https://www.youtube.com/watch?v=4gyP94hsC14

So if there is a bottleneck would it most likely come from the process of
converting the 3d data to pixels?

VonBon
05-18-2018, 09:04 AM
For those like myself.
https://www.youtube.com/watch?v=5W7JLgFCkwI

Chuck
05-18-2018, 11:11 AM
hi Chuck,

LightWave plugin developer Jay3d knows a bit more about this >
http://forums.newtek.com/showthread.php?156906-Metamorphic-for-LightWave-2018-(AnimatedSculpt-previously)&p=1546010&viewfull=1#post1546010


not necessarily

Thanks for the pointer, erikals!

Chuck
05-18-2018, 11:51 AM
Not when OpenGL runs smooth in other apps with similar or more enhanced viewport settings.

My hardware setups are 8-12 core systems with 64GB RAM, GF1080 and Dual GF970GTX, so that should be sufficient.

Relaying a comment I received from the developers: viewport performance can be affected by a number of factors other than strictly the OpenGL itself, and with a proper bug report and content they can profile the issue, determine the causes and tune for cases to improve performance. It is very useful if you have issues where performance in LightWave does not seem to match performance in a comparable application given the same OpenGL mode and settings (apples to apples) to report the issue, provide the content you are testing with and fully describe the results in each application tested. Don't forget to include version information for the compared application and your system configuration.

I think videos of the comparative performance issues could be helpful as well, and with YouTube at least, it is possible to post a video but set it to be not listed, so it does not show up for the public, but you can include the link in your bug report and the developers could review it.

I'd like for this discussion to develop an accurate picture of where LightWave stacks up with respect to viewport performance with large datasets, with the result of a comprehensive set of reports covering all issues discovered that our developers can work with to resolve those issues. Seem reasonable?

Marander
05-18-2018, 12:53 PM
Seem reasonable?

Yes indeed very reasonable, thank you very much for your investigations and answer Chuck. I will do the tests and provide feedback the way you suggested.

SBowie
05-18-2018, 01:55 PM
BTW, Chuck, love the new avatar ... nice kittie. :)

erikals
05-19-2018, 07:07 AM
...and nice seastar SBowie  :)

Marander
05-19-2018, 03:45 PM
I have done a couple of tests with LW and another application to compare geometry handling / performance.

First, I have to apologize that I think I was wrong with my statement about geometry performance in LW.

It seems, LW2018 (Layout) is very well capable of handling large amounts of polygons.

However, here's what I think is the problem and what made my scenes very slow in the viewport:

LightWave is very slow as soon as Modifiers are used (Bones, Deformers etc.). Other applications don't show any significant slowdown, while LW gets so slow that it's almost not possible to navigate in the viewport.

Because I have sometimes several characters with bone deformations in the scene, it gets very slow.

To see that LW has no problem with large geometries, I have created a quick scene where I baked down the same character multiple times, no problem in LW (not slower that in the other app).

(I don't know if it's possible to display FPS in the LW viewport, but the camera movement is very smooth.)

141770

141771

141763

141764

141765

(on a side note, the scene takes about 4x the RAM in LW compared to the other app.)

The same scene with only one character but with all joints / skeletons gets significantly slower in LW.

Here's a single model I created and subdivided into an insane amount of polys.

141772

141773

While it runs very smooth in the LW viewport, as soon as I add for example a bend deformer, it gets extremely slow.

141768

141769

(I have to admit I have no idea how to use the Bend deformer in LW properly)

In the other app it runs with up to 300fps.

141774

141767

As a disclaimer I have to say that in the scenes above I extra created an insane amount of polygons where instancing and using Subd would be better in real scenes of course.

So now I think I understand why the viewport gets slow, maybe somebody can confirm.

Chris S. (Fez)
05-19-2018, 04:28 PM
Great overview. Will test and submit bug reports with scenes this week.

Marander
05-19-2018, 05:35 PM
Great overview. Will test and submit bug reports with scenes this week.

Thanks Chris!

Just did another test, I noticed there are new Nodal Deformers in 2018.

the problem is basically that it seems the Deformers are computed also during viewport navigation (even if there is no animation running). As soon as the Deformer is disabled, the navigation is fast again.

The active deformation animation with very high poly objects (5 Mio for example) is also slow in other apps but when not animating those and just dollying / moving round in the viewport runs fast.

jwiede
05-19-2018, 07:30 PM
Seems like a combination of two issues:

Lightwave is continually recomputing the deformations frame-by-frame, instead of pre-computing and caching deformations only updating the cached values when changed.


Lightwave is recomputing the deformations even when animation isn't running/active.
Fixing the latter will improve viewport navigation slowdowns when animation isn't active, but fixing the former is the more general solution (because it also fixes the latter issue*, and improves performance even when animation is active).

*: Nothing is changing to invalidate cached deformations in the latter case, so it wouldn't trigger recomputing the deformations.

Marander
05-20-2018, 02:42 AM
Bug report submitted

ianr
05-20-2018, 08:35 AM
Seems like a combination of two issues:

Lightwave is continually recomputing the deformations frame-by-frame, instead of pre-computing and caching deformations only updating the cached values when changed.


Lightwave is recomputing the deformations even when animation isn't running/active.
Fixing the latter will improve viewport navigation slowdowns when animation isn't active, but fixing the former is the more general solution (because it also fixes the latter issue*, and improves performance even when animation is active).

*: Nothing is changing to invalidate cached deformations in the latter case, so it wouldn't trigger recomputing the deformations.


Nice Observations JW.

Chuck, may I suggest devs could eval a 'look ahead cache'

& the camera frame driven mode (in Clarrisse)

roboman
05-20-2018, 08:41 AM
I've got a project I'm working on right now with 238,000 polygons and things seem to be fine, bouncing back and forth between layout and modeler. That's on an i7 3.4 ghz with 16 gb and a GeForce gt 620. I'm only running it at 1080 right now, so that might be helping. VPR is slow, but it's rendering out a scene with the cpu. NVIDIA Iray GPU Rendering is fast and nice, but I'm assuming hardware rendering is coming and I'll get another card or two at that point. I'm still fighting with the node texturing, but am liking the render engine.

erikals
05-20-2018, 10:06 AM
238,000 polygons
that is no match though, LW should be able to drive millions.
LW11 can drive 3mill (static) without fuzz
https://www.youtube.com/watch?v=880TOLoJ1SM

i can't say, don't have 2018, but it would be nice to see more video examples

Marander
05-20-2018, 12:33 PM
Nice Observations JW.

Chuck, may I suggest devs could eval a 'look ahead cache'

& the camera frame driven mode (in Clarrisse)

Yes thanks JW, in fact I haven't tought of caching (that other applications allow) but mentioned in the bug report thanks to your input.

madno
05-21-2018, 01:56 AM
Can you update us on the feedback from the devs regarding your report (if allowed by Newtek)?
Following the forum during the last months there seems to be more constructive technical evaluation and a little less pure citisism.
I would be happy to get information about what happens with those bug reports and feature requests.

SBowie
05-21-2018, 08:39 AM
Can you update us on the feedback from the devs regarding your report (if allowed by Newtek)?I don't speak for LW3DG, but generally there is no problem discussing bug status as long as we're discussing release versions (as opposed to beta).

Marander
05-21-2018, 08:55 AM
I don't speak for LW3DG, but generally, there is no problem discussing bug status as long as we're discussing release versions, as opposed to beta.

Ok good, I will post the results.

Chuck
05-21-2018, 02:28 PM
Looks like some much-needed reports are getting in - many thanks to Marander, Chris and all of you for getting this started!

Chuck
06-26-2018, 04:10 PM
Folks, I want to encourage the team to look into the cases that came from this thread - please let me know any case numbers! You can PM me if you prefer.

OFF
06-27-2018, 02:10 AM
The LW18 works pretty well with static objects. But if there are many instances, even static ones - the performance drops sharply. Including if these instances are not displayed in the viewport (perhaps this is Bug, since if you set the panel to the off status, the performance again increases).
But if you work with medium-high-polygon characters, the performance is very low and not very different from the one in LW15.

Here is an example - a model of about 16000 polygons plus hair - 3000 polygons and pants - 7000 polygons - in the total about 26000 polygons. Which is quite small by today's standarts. In any mode (Texture, Shade, Wire, Vertex or even Bounding box), the refresh rate of the Layout is no more than 2 fps. It is critically low.

142031

You can forget about trying to work on the character's speeches and other facial expressions in the same scene - you have to make separate scenes and work in them exclusively with the character's face.
Lino argued that the performance of OGL in LW18 is one and a half to two times higher than in LW15. But in my opinion this is clearly not enough - it should be much higher. 5-6 times so that we can feel comfortable when working with characters. What is needed both in the advertising industry, and for the cinema and game industry.

Marander
06-27-2018, 11:57 AM
Folks, I want to encourage the team to look into the cases that came from this thread - please let me know any case numbers! You can PM me if you prefer.

Thank you Chuck for your inquiries and feedback, much appreciated! Cheers

jwiede
06-27-2018, 06:04 PM
Lino argued that the performance of OGL in LW18 is one and a half to two times higher than in LW15.

Take statements like that with a HUGE grain of salt -- without knowing the precise testing/profiling case used, and config/situation, independent confirmation isn't possible (critically relevant in the realm of perf claims). There's also no way to confirm whether the claimed performance improvement test case has any "real-world relevancy" or not.

rustythe1
06-28-2018, 09:51 AM
so did something break between this,
https://blog.lightwave3d.com/2016/03/upcoming-lightwave-performances/
and now?

hypersuperduper
06-28-2018, 02:24 PM
The LW18 works pretty well with static objects. But if there are many instances, even static ones - the performance drops sharply. Including if these instances are not displayed in the viewport (perhaps this is Bug, since if you set the panel to the off status, the performance again increases).
But if you work with medium-high-polygon characters, the performance is very low and not very different from the one in LW15.

Here is an example - a model of about 16000 polygons plus hair - 3000 polygons and pants - 7000 polygons - in the total about 26000 polygons. Which is quite small by today's standarts. In any mode (Texture, Shade, Wire, Vertex or even Bounding box), the refresh rate of the Layout is no more than 2 fps. It is critically low.

142031

You can forget about trying to work on the character's speeches and other facial expressions in the same scene - you have to make separate scenes and work in them exclusively with the character's face.
Lino argued that the performance of OGL in LW18 is one and a half to two times higher than in LW15. But in my opinion this is clearly not enough - it should be much higher. 5-6 times so that we can feel comfortable when working with characters. What is needed both in the advertising industry, and for the cinema and game industry.

This seems like very poor performance and doesn’t reflect my experience. I have been working with characters a lot recently and i find the performance quite good. Definitely nothing like 2fps. I have notice however that some things can REALLY affect frame rate, like if I use the Bone info node for example. Have you tried troubleshooting to see if you can isolate what is affecting performance?

jwiede
06-28-2018, 05:10 PM
so did something break between this,
https://blog.lightwave3d.com/2016/03/upcoming-lightwave-performances/
and now?

Perhaps, or perhaps the test case used in those tests turned out to be "less representative" of real-world use cases than expected. Or perhaps those tests were done using a incomplete development GL environment, and once all missing-but-required elements were also properly "wired up" in the display pipeline, the full pipeline's performance wound up being significantly lower than originally estimated. The presented numbers could also have been erroneously computed. It's quite possible we may never know -- those estimates and the test cases used to derive them were never fully documented and conveyed to users.

Chris S. (Fez)
06-28-2018, 06:52 PM
This does not reflect my experience. 2018 is definitely faster on my system. Was working on some test scenes but "life" interfered. I'll try to get everything organized and submit next week.

OFF
06-28-2018, 07:17 PM
a very strange situation - in one of my projects when I animating a low poly character I get 2 fps. Yesterday I started a new project with models from Daz3d for 50-80 thousand polygons each and get 20-25 fps. I do not know what can slow down some scenes, considering that there is nothing except a low-poly character. I'll try to remove extra maps of weights, morphing and uv.

Kryslin
06-29-2018, 07:43 AM
LW2018, on my workstation, is definitely faster than 2015.3. I have a single scene, containing 2 RHiggit2 rigged characters ( approx. 4100 objects each, 26K polygons, FiberFx applied to each, 5 layers each character), one static mesh of about 1K polygons. At subd level 2, it comes to 300k polygons, with deformations and morphs. IF FFX is disabled, I average 6 - 10 fps scrubbing the timeline, or manipulationg various objects. IF FFX is turned on, forget interactivity, as the frame rate drops to 2 frames per minute, or worse ( this is normal for FiberFX, btw, with multiple layers of fur/hair).

There are ways to kill your frame rate: include some lwcad 5.5 primitives in your model is one sure fire way to reduce it to frames per hour. Having you subd levels set way too high, especially catmull-clark, can send polygon counts through the roof. And so on.

There is always room for improvement. Using a tesselation shader on the gpu for opengl display of subd surfaces is one. There are probably a few places in bone deformations and morphs that could be improved as well.

I do not envy the LW Devs their jobs; between the people who would like some of the older problems fixed, and those who say "We need feature X, otherwise LW isn't relevant anymore!" I can see why they don't come around these forums...

jwiede
06-29-2018, 07:40 PM
Just for note, I believe the scenario OFF mentioned above involved the presence of instances in the scene -- I'm only bringing up because I'm noticing subsequent posters aren't mentioning instances in their counter-examples.

OFF
06-30-2018, 02:03 AM
No, no, there are no instances. In fact of the matter is that the scene is very simple - a character and two layers of hair. This model was taken from a scene that was once sent to me by one client - the scene was made for Maya, I transferred it to LW.
Perhaps the reason is that the character model contains a very large number of morphs - about 80 (!!). I'll try to do a test by deleting all these morphs to see how the speed changes.

P.S. Yes, I can confirm - after removing a third of the morphs (most were just variants of the same emotions), the speed has appreciably grown.

erikals
06-30-2018, 04:56 AM
P.S. Yes, I can confirm - after removing a third of the morphs (most were just variants of the same emotions), the speed has appreciably grown.
thanks, good info! might be valuable to report...

https://i.imgur.com/5jEi2Ve.png

jwiede
06-30-2018, 05:26 PM
P.S. Yes, I can confirm - after removing a third of the morphs (most were just variants of the same emotions), the speed has appreciably grown.

Okay, that's less surprising. Due to how OpenGL-based visualization pipelines work, stuff that requires CPU-based application of vertex-/poly-level transforms is inherently slow, and I'm pretty sure that's how LW handles morphs currently. They could look into building geometry "shaders" to handle morphs etc. on GPU (if they haven't or aren't already), but I suspect the age of LW's infrastructure design (as it is in many other cases) means it isn't really suitable for handling morphs in that manner. Hopefully LW2018's modifier stack changes may help in that regard, we'll see.

In any case, I don't consider the slowdown you're experiencing with high numbers of morphs present particularly surprising. It's clearly an area where improvement would be valuable, but significantly improving it may require some fairly complex infrastructure work.

I'd be very interested to hear more about the areas where they're focusing dev efforts, specifically in terms of what they consider performance optimization priorities, and whether cases like this are among them. Morphs are heavily-used functionality in LW, so significantly improving performance there at least appears to offer decent RoI at first glance. For whatever reason, though, NewTek just doesn't seem interested in having those kinds of discussions with customers.

The problem with that, of course, is that means they don't necessarily get timely and reliable feedback on whether their internal priorities really are reflective of their customers' priorities, which can lead to a harmful divergence. It appears something similar may have occurred w.r.t. Modeler priorities. Perhaps the Modeler survey is a sign that NewTek's begun to recognize that potential for divergence and address it, or perhaps not.

jeric_synergy
06-30-2018, 05:44 PM
Not sure how MAYA stores morphs, and how simple-minded a conversion might be, BUT:

if the morphs maps include the entirety of the model, but only a SMALL %age of the points are changing positions, LW users might be able to retain all the maps by clearing the maps of redundant/unchanged points.

I have zero idea how one would automate that, but it seems like it definitely should be possible.

That would be a good utility to have: "CULL MAPS". Unless there's a reason to retain point positions that do not change from the base position..... hmmm....

EDIT: perhaps OFF can confirm/invalidate the idea that the morph maps are the entirety of the model?

Kryslin
06-30-2018, 06:33 PM
Maps -> General -> More, you'll find Cull Maps. It's native. It selects/deselects points below a certain threshold value, and can clear them from the map, if the correct option is chosen.

jeric_synergy
06-30-2018, 07:26 PM
I Did Not Know That.

Actually, I knew "CULL MAPS" existed, but I didn't know about the threshold parameter. :thumbsup:

erikals
07-01-2018, 05:54 PM
Perhaps the Modeler survey is a sign that NewTek's begun to recognize that potential for divergence and address it, or perhaps not.
assume Modeler is the next update. in the year 2022.
iow, who cares. we're beyond the point of caring / complaining i think.

so, jump or drive

i got grey beard now!  https://i.imgur.com/3obeUDW.gif

jwiede
07-01-2018, 07:15 PM
assume Modeler is the next update. in the year 2022.
iow, who cares. we're beyond the point of caring / complaining i think.

Speak for yourself. I do still care, and do not believe this whole "all complaints are just pointless negativity" mantra helps LW or NewTek in the least.

erikals
07-02-2018, 12:09 AM
my reply might have come across as a bit harsh.

i wish there was a dedicated list for >
"most crucial Modeler / Layout fixes"

i made one here for Modeler, but it's a bit all over...
and does not include many tricks/features from other apps
http://forums.newtek.com/archive/index.php/t-139159