PDA

View Full Version : LW 2015.2 slow



Niko3D
06-05-2015, 04:28 AM
Hi,

I've just installed LW 2015.2 and it's super slow. I've loaded a scene built in 11.6.3 and I had to wait 10/15 mins!!!!!!!!!!!!!!!
In LW 11.6.3...same scene of course...2/3 mins...
And also the VPR...it works fine, but very slow compared to 11.6.3...
Everything is quite weird...everything is very slow! If I open Camera Properties and I click the tabs between Lights, Output, GI, General ect...before to appear the Tab run 1 second minimum.

Are there same strange new setting to do?

Nico

50one
06-05-2015, 04:53 AM
There's nothing else that can be done other than taking look at configs....same ol' same ol' :)
Backup them, delete and see if that's going to help.

Sensei
06-05-2015, 05:19 AM
Check whether mesh evaluation is multi-threaded,
check whether OpenGL acceleration is same (Display Options/GL Options windows) (compare with v11.6.3 settings).
check whether renderer is using all threads (Render Globals/Task Manager).

Niko3D
06-05-2015, 05:41 AM
Check whether mesh evaluation is multi-threaded???

where is it?..sorry I don't understand...

Sensei
06-05-2015, 06:42 AM
Press 'o',
It's nearly on bottom on left.

Ryan Roye
06-05-2015, 06:47 AM
Check your GL options:

In scenes with many transparent textures, setting transparency sorting to "ByObject" rather than "ByPolygon can make a huge difference.

ByObject --> less strict drawing of transparent objects (they will overlap with eachother).

ByPolygon --> Much more accurate, but negatively impacts performance.

Niko3D
06-05-2015, 07:13 AM
Press 'o',
It's nearly on bottom on left.

Yes I know 'o'...of course...but I didn't understand "mesh evaluation multi-threaded"...

- - - Updated - - -


Check your GL options:

In scenes with many transparent textures, setting transparency sorting to "ByObject" rather than "ByPolygon can make a huge difference.

ByObject --> less strict drawing of transparent objects (they will overlap with eachother).

ByPolygon --> Much more accurate, but negatively impacts performance.

Yes ok...It's always on ByObject!

spherical
06-05-2015, 04:50 PM
Is Full Scene Parameter Evaluation on? May not be a problem anymore, but it used to cause major issues.
Could be anti-virus examining files that it should ignore.
Could be firewall.
Could be worse...
Could be raining.

Niko3D
06-06-2015, 05:14 AM
Is Full Scene Parameter Evaluation on? May not be a problem anymore, but it used to cause major issues.
Could be anti-virus examining files that it should ignore.
Could be firewall.
Could be worse...
Could be raining.

Now it's better...I saved the scene in 2015.2 and it's good...thank you.;)

vonpietro
06-08-2015, 12:04 PM
I find that running modeler and lightwave together with the hub can slow things down.
try running lw without modeler.

Sanchon
06-10-2015, 01:13 PM
Do you use network drive ? There is a bug in Lightwave - scene can be loaded even one hour if you change network drive letter or rename directory to another one that was saved before.

Niko3D
06-11-2015, 03:07 AM
Do you use network drive ? There is a bug in Lightwave - scene can be loaded even one hour if you change network drive letter or rename directory to another one that was saved before.

Yes...I work in network because I'm working in a big arch company and we have C: for window stuff, P: for projects, O: for office, M: for marketing, A: for archive ect...so I can't change the drive letters, because I'm not alone...
But to be honest I don't know why...now I saved all my old scenes and my all plugins from 11.6.3 and it works fine...

Sanchon
06-11-2015, 03:12 AM
Yes...I work in network because I'm working in a big arch company and we have C: for window stuff, P: for projects, O: for office, M: for marketing, A: for archive ect...so I can't change the drive letters, because I'm not alone...
But to be honest I don't know why...now I saved all my old scenes and my all plugins from 11.6.3 and it works fine...

It works fine now because you resaved this scene with your new folder paths. But this scene will loads longer again if someone will tried to load it on the computer that has different network paths. It is very annoying if someone working with network drives. I lost many hours to reload my old scenes to my new network configuration.

lardbros
06-11-2015, 05:47 AM
Sanchon, have you reported this as an issue? With steps to reproduce?
I work on a network drive, and haven't noticed this myself... would be interested to try and reproduce this at my place.

Sensei
06-11-2015, 05:53 AM
I have plentiful of scenes that load ages because of this.

Drag'n'drop some external URI LWO,
f.e. \\server\drive\path\file.lwo (open folder in explorer \\server\drive\path\ , copy there some lwo, and d'n'd that file back to LW)
or
\\192.168.0.x\drive\path\file.lwo
to Layout.
Save scene.
Change name of server to something else.
Change IP to something else.
So old one will not be present in network anymore.

And try loading such scene.

Niko3D
06-11-2015, 06:36 AM
It works fine now because you resaved this scene with your new folder paths. But this scene will loads longer again if someone will tried to load it on the computer that has different network paths. It is very annoying if someone working with network drives. I lost many hours to reload my old scenes to my new network configuration.

I didn't know!Thank you very much for the explanation!

Sanchon
06-11-2015, 09:51 AM
Sanchon, have you reported this as an issue? With steps to reproduce?.

Yes, report LWB-1359.

"We're considering making that "autosearch" an option - it used to not do this- and folks complained about it "not finding the images by itself" -- now, we get the other way that it takes too long to find when the user doesn't keep it organized"
"We are not able to extend control over users through our system - if you choose to change paths, then it's up to you to fix them. I'm sorry, but we have to adhere to a 'standard' for our paths for the system to locate - and if you as a user break from that - the 'long load times' is the system searching for those. That's by design. IF you keep the content straight, you won't have that time for the search."

So it is made by design - bad design in my opinion - if you using different network paths and configurations. There should be option to set different customizable paths for images, objects etc- like it is in Max.

lardbros
06-11-2015, 11:08 AM
Oh right...
If rather it threw up an error. Don't need autosearching by default, I keep my content directories in order! :)

jwiede
06-11-2015, 01:07 PM
"We're considering making that "autosearch" an option - it used to not do this- and folks complained about it "not finding the images by itself" -- now, we get the other way that it takes too long to find when the user doesn't keep it organized"

It shouldn't have been implemented in the first place without ability to disable. Further, even when enabled, there should be a user-configurable run time limit. Anything remotely search-like, when applied to networks, always introduces potential for unbounded runs. The need for user-/IT-configurable disable and time limit options is 100% foreseeable in such features.

LW3DG almost seem scared of giving LW users preferences in these situations, and it hurts LW as a result. These kind of behavioral issues keeps coming up, and they really shouldn't, they should be left to users to decide. If LW3DG doesn't want to clutter the existing prefs, then offer an "advanced prefs" INI file or moral equivalent that users or administrators with advanced needs can modify. Any situation where LW is potentially accessing/consuming shared resources needs to be highly user-configurable in behavior. This kind of approach becomes even more important in business/corporate environments where inability to configure LW to fit within local IT policies/expectations is likely to factor strongly into their buying decision.

Sensei
06-11-2015, 01:10 PM
LW3DG almost seem scared of giving LW users preferences in these situations, and it hurts LW as a result.

It's not scare. It's time spend by programmer.
The majority of time is spend on making GUI, loading and saving it, than on making functionality..

jwiede
06-11-2015, 06:25 PM
It's not scare. It's time spend by programmer.
The majority of time is spend on making GUI, loading and saving it, than on making functionality..

Creating an "advanced settings" plain-text INI file or like, loading at start, perhaps saving at exit maybe, hardly requires substantial additional programming.

Sensei
06-12-2015, 02:53 AM
LW doesn't write/load INI file, but their own through LWLOAD_ and LWSAVE_
Did your plugin ever implemented Load/Save in handler plugin?

One guy who worked for international company told me that "adding 3 lines of code" in their big app takes couple weeks.
He needs to consult everything with senior programmer manager, have a few meetings, learn and understand everything.

It's easy to write your own code from scratch. You know what every line is doing.
But if code is written by 20+ people during 20+ years,
even understanding of what some line of code that somebody wrote 20 years ago is poor.
Not to mention to modifying it, and adding something new to it.
There could be large dependency on what you're just modifying in completely other part of package.
It can quickly become instable after change.

You remember there is field userdata at instancefuncs->priv?
It's used to pass argument to our own instance.
One NT programmer used this field for her own purpose, and trashed it..
It's visible only when there is asked smaller handler version than current LW. And only in some handlers.
Major reason for why many old plugins don't work on the latest version. If they use instancefuncs->priv for passing some data to call-backs.
Programmer didn't even understand that it's plugin userdata, not LW userdata!
And it's going, and going, issue...

Understanding large app by people who didn't wrote it originally is pretty poor.
And they don't want to waste entire life to try understand old code.

jwiede
06-12-2015, 03:05 PM
If I hadn't proven that I have a deep understanding of the complexities of working with huge, established legacy code bases, nor ability to successfully manage change risks against necessary improvement, I wouldn't be allowed to do the work I do, nor hold the senior engineering position at Microsoft I hold.

They were already modifying legacy code's behavior, adding a disable does not introduce substantially more risk. In fact, failing to implement a disable after changing established behavior actually leaves substantial risk unaddressed. Ignoring that risk because "addressing it would take more work" is not an acceptable justification. Such work may be more difficult with legacy code, but the risk arises because it is legacy code -- mitigating that risk is no less necessary than the original modification. If they couldn't afford to do so, they shouldn't have begun modifying the behavior in the first place.

jeric_synergy
06-12-2015, 03:53 PM
On the plus side, with Rob's "studio-centric" attitude, this is JUST the kind of bug he likes to get quashed ASAP.

So get those bug reports in, boys and girl.