PDA

View Full Version : Visual surface differences between 2015 and 2018?



jbrookes
01-27-2018, 10:32 PM
Has anyone noticed a fairly radical difference in the appearance of object surfaces between LW 2015 and LW 2018?

In my case, I have both apps running side-by-side with the exact same basic scene.

In the scene there's a 1m diameter sphere with all default surface settings with the exception of:

Color = R 81, G 95, B 163
Specular = 37.5%
Glossiness = 40%
Reflection = 84%
Smoothing = Enabled

The sphere in 2015 shows up with a slightly muted hot spot.

The sphere in 2018 shows up with a very bright white hot spot.

You don't even need to render it to see it. The difference is visible in Layout's default of Textured Shaded Solid.

gar26lw
01-27-2018, 10:54 PM
can u post a pic?

jbrookes
01-28-2018, 03:20 AM
can u post a pic?

Here's a comparison of the two outputs using the LightWave benchmark scene (part of LW 2015 content).

The image on the left is LightWave 2015 and the one on the right is LW 2018:

139808139809

MichaelT
01-28-2018, 07:56 AM
I'm assuming you let LW2018 convert that scene? Which only tries to make sure the scene works in the new version. You still need to go in there and tweak settings, materials etc.. so it matches what you had before. LW2015 & LW2018 are not compatible.. they are different renderers.

RebelHill
01-28-2018, 08:19 AM
https://www.youtube.com/watch?v=TGgyYrhQZF4

MichaelT
01-28-2018, 08:29 AM
yup.. just tested the same scene myself. Got the same image you just posted C. So I don't know what he did there. That scene works just fine.

rustythe1
01-28-2018, 09:44 AM
ive noticed that if you have certain images and textures that for some reason 2018 sometimes plugs these into the luminosity channel inside the node editor on conversion, it almost looks like that's whats happening there

jwiede
01-28-2018, 05:19 PM
ive noticed that if you have certain images and textures that for some reason 2018 sometimes plugs these into the luminosity channel inside the node editor on conversion, it almost looks like that's whats happening there

Yeah, I caught the scene converter doing odd conversions of surfaces on a couple occasions, but it wasn't really consistent enough in behavior to figure out precisely why most scenes were handled one way and a few handled in quite different, unexpected manners.

For mechanisms like that I really wish they'd give users a precise pseudocode recipe for what the converter does, so we can identify in advance whether scenes are likely to convert properly (or perhaps provide a summary of intended changes prior to actually doing them, for approval/rejection). Otherwise, when it does odd things, there's no real way to know whether the behavior is a bug, or just a scene that's too complex for the mechanism to definitively understand and convert.

JamesCurtis
01-29-2018, 08:07 AM
The original poster said he ran 2015 and 2018 side by side. I thought this was NOT recommended due to the different version's configuration files causing issues with each other. He didn't say whether he had closed one and then did the other. I wonder if this is the case? I've played with both myself and a basic sphrere looks fairly the same. Granted, the new lights in 2018 are a little different and behave differently.

mummyman
01-29-2018, 09:43 AM
https://www.youtube.com/watch?v=TGgyYrhQZF4

So is there an explanation why in 2015, the color space settings are different? Meaning if you pick the SRGB tab, picked colors and lights stay at SRGB. In 2018, they change to linear when picking SRGB tab. I thought I had this working and understood it. Maybe not so much.

jbrookes
01-29-2018, 11:51 AM
The original poster said he ran 2015 and 2018 side by side. I thought this was NOT recommended due to the different version's configuration files causing issues with each other. He didn't say whether he had closed one and then did the other. I wonder if this is the case? I've played with both myself and a basic sphrere looks fairly the same. Granted, the new lights in 2018 are a little different and behave differently.

From what I can tell, each version of LightWave has its own discrete folder with config files, license files, etc.... In theory there shouldn't be any 'cross-talk'. However, if you have evidence to the contrary, please let us know since that's certainly of interest.

JamesCurtis
01-30-2018, 09:58 PM
There has been talk in several threads regarding issues where the Hub, Layout, and Modeler configs would get corrupted somehow. In many, the Hub was suspected. I can't point to specific threads though.

The other day I was trying to get DStorm's Trailer plugin working in LW2018.01. It was working fine in the original LW2018.0 release. I'm not sure what happened, but even though the plugin was showing up in the plugins list, it could be seen but not selectable at all in Object Properties > Displacement. Other plug-ins were selectable and working.

Something had happened. The only thing I can think of is that I had closed LW2018.01 and accidentaly forgot to close the Hub, and then had started LW 2015.3 to check on something just before the problem occurred in 2018.01. After reinstalling LW2018.01, the plugin was working fine again.

I know this has gotten a bit off track from the original topic, but I wanted to point out that this could happen and thus the reason for my thoughts and warning.

jbrookes
01-30-2018, 10:06 PM
Hmmm.... Interesting.

The hub. I hadn't thought of that. I usually have it disabled.

It would be nice to have some way of mapping every file that each version of LW is linked to. So far, every file of note that I can see exists in its own folder. In my case, there's a separate content directory for each version and a separate folder for the usual group of folders (configs, docs, layouts, licenses, etc...) for each version of LightWave. As for the inner workings of the hub... that's a bit of a mystery to me.

I'll have to watch for that when I'm testing these two apps.

jbrookes
01-31-2018, 02:24 AM
So, I'm only able to locate files in the following three places:

C:\Users\Username\.NewTek\LightWave\2018.0.1 <-- License file, docs, configs, and content

C:\Program Files\NewTek\LightWave_2018.0.1 <-- plugins and LScripts are here.

C:\Users\Username\AppData\Local\Temp <-- a file in here called HubViewportview.Arc, a folder called LWScratch, and another called lwhub (so maybe this has something to do with it?)

If anyone knows any other default locations where more LightWave stuff is stored, please feel free to post here.

VermilionCat
01-31-2018, 07:27 AM
So is there an explanation why in 2015, the color space settings are different? Meaning if you pick the SRGB tab, picked colors and lights stay at SRGB. In 2018, they change to linear when picking SRGB tab. I thought I had this working and understood it. Maybe not so much.

I'm also confused about this. Which one is right?

JamesCurtis
01-31-2018, 10:25 AM
Hmmm.... Interesting.

The hub. I hadn't thought of that. I usually have it disabled.

It would be nice to have some way of mapping every file that each version of LW is linked to. So far, every file of note that I can see exists in its own folder. In my case, there's a separate content directory for each version and a separate folder for the usual group of folders (configs, docs, layouts, licenses, etc...) for each version of LightWave. As for the inner workings of the hub... that's a bit of a mystery to me.

I'll have to watch for that when I'm testing these two apps.

The problem is that in order to do that, I think there would have to be a new extension for each LW object type [LWO1, LWO2, LWO3, and the same method for scenes]. Or possibly in descriptions/comments in filenames.

The reason the Hub can get confused is because it is HTTP based, I believe, and its non discriminate.

jbrookes
02-01-2018, 12:47 AM
More tests.... I noted the following as an example of the differences between the look of the LW2015 render engine and the LW2018 engine:

After turning off Global Illumination and unchecking Backdrop Gradient in LW2018, I noted quite a difference in surface settings for achieving the same (or as close as possible) look to an object's specular hotspot:

LightWave 2015.3
Diffuse 75%
Specular 35%
Glossiness 42%

LightWave 2018.0.1
Diffuse 100%
Specular 8%
Glossiness 20%

With a differential like that, there are a lot of objects that are going to require a serious surfacing overhaul to look anything like they did in pre-2018 versions of LightWave. Unfortunately, I expect to see lots of ultra-shiny renders from people who switch off GI for the sake of speed and just hit the render button in LW2018.

DogBoy
02-01-2018, 02:43 AM
jbrookes, look Standard is just an attempt to give some backwards compatibility for older assets: it's at best an approximation of the old system. In all honesty, I think it's there so you can see where things connected, so you can try and rebuild them in the new system. I would avoid it's use where possible.

mummyman
02-01-2018, 07:47 AM
I'm also confused about this. Which one is right?

Me too. My workflow is Lightwave to AE. My AE comps are set to 16bit / sRGB working space. I thought I had .exr's working... but maybe not!

joseba
02-08-2018, 04:08 AM
So is there an explanation why in 2015, the color space settings are different? Meaning if you pick the SRGB tab, picked colors and lights stay at SRGB. In 2018, they change to linear when picking SRGB tab. I thought I had this working and understood it. Maybe not so much.

That is a very good question.
¿anyone..?

jbrookes
02-09-2018, 01:42 PM
That is a very good question.
¿anyone..?

That sounds a lot like a bug to me.

Probably a good candidate for

[email protected] dot com

gar26lw
02-09-2018, 05:13 PM
That sounds a lot like a bug to me.

Probably a good candidate for

[email protected] dot com

i reported this already, via the feedback agent. from my recollection, i think it was changed intentionally because someone thought that you’d want to pick colours in linear but of course, we want srgb as we tend to work and reference everything in an srgb space. pick colours from screen or reference images for example. i think the bug is getting looked at.