PDA

View Full Version : Big Bad 2018 / 2015 Global Illumination shootout



Exception
01-16-2018, 04:57 PM
Hi folks,

A new year, and a brand new LW. For those that remember from when we were young uns, I used to spend most of my free time testing and making manuals for LW's GI.
As many of us are still in Arch Viz and use LW in practice on massive projects, LW's GI is still critical to our daily work.

I invite everyone to help test and improve Lw's new engine.

I have provided a test scene in both LW 2015.3 and LW 2018.0.1 versions to download at the end of the post.
Please improve and/or provide your own?

Scene description
This is a radiosity nightmare, on purpose. It's an enclosed space, with an open ceiling edge, and two small windows. All transparent materials are dielectric, metal is conductor, floor and walls are standard. Light is a single distant light and a gradient backdrop. There's a small spherical red light in the corner, like the annoying child.

My conclusions thus far:
Given the same identical settings (as far as possible), LW2015 will be much faster than 2018. But LW2018 will look a lot better.

So, to compare them, you need to change settings to get into the same ballpark. I have done so mainly in these preliminary tests by dropping the 'rays per evaluation' setting in 2018. There may be better ways.
My conclusion is that 2018 is faster, when you do this, and still gives you higher quality. In addition, you get more 'real world' calculations that require less settings due to the better integration of PBR.

Demo
Here's a demonstration. 2018 has Rays per Evaluation set to half of those of 2015. These were dumped from VPR exaclt at the 1 minute mark. This wasn't right before the 'update' for either of them.
Note that they don't look exactly the same as 2018 handles light settings differently, and thus the red light is a bit stronger. I kep it like that on purpose, so it;s easier to spot which one is which. It should not affect render times or overall quality.

2018.0.1:
http://forums.newtek.com/attachment.php?attachmentid=139492&d=1516146700

2015.3:
http://forums.newtek.com/attachment.php?attachmentid=139493&d=1516146707

Downloads
Scene package 2018:
139494

Scene package 2015:
139495

Exception
01-16-2018, 05:17 PM
Here is the exact same scene, but 2 minutes into VPR munching:

If there's anyoen that can tell me how to attach images full size directly in IMG tags instead of ATTACH tags and having to go though the song and dance of attaching, posting, copying links, and entering direct image details, please tell me.

2018
http://forums.newtek.com/attachment.php?attachmentid=139499&d=1516148172

2015
http://forums.newtek.com/attachment.php?attachmentid=139500&d=1516148178

Ztreem
01-16-2018, 05:31 PM
Fun to see you back here, I thought you stopped using LW many years ago. :)

tyrot
01-16-2018, 05:41 PM
exceptional NEWs .. exception is here ! welcome back master archvizer!

Exception
01-16-2018, 06:21 PM
Heh.. thanks guys. I was never gone, just behind the scenes ;)
did miss you. Tyrot, how've you been?

Nicolas Jordan
01-16-2018, 09:29 PM
Yes, great to see you back on the forums! I was actually using some of your free GI demo scenes for testing 2018. It's good to hear your review of 2018 GI so far.

I have been pretty disappointed at the longer render times in 2018 but I'm hoping it will at least improve a bit with some new builds. Since 2015 and 2018 both had the same settings I didn't think there was much difference between them with GI but apparently there are some differences and maybe the trade off is worth it in some cases and maybe not in other cases. Maybe I will have to get a Threadripper to deal with longer render times.

Thanks for the test scenes. :)

JamesCurtis
01-16-2018, 10:32 PM
Thanks for the comparison scenes. I'll be checking them out in the next day or so.

I plan on actually purchasing 2018 this week, but have been using the trial fight now. I have two 2015.3 licenses, and will be upgrading just one for now due to budgeting reasons.

I like the comparison images you posted, and will be curious to see what my render times will be with your scenes.

omichon
01-17-2018, 02:14 AM
Thanks a lot for this test content, Exception. I hope it will help me since I can't get nice and clean corners in one of my scenes and I haven't been able to fix the issue for a couples of days now.
I see you pushed the Interpolation Softness to its maximum, but I was reluctant to do so since it looks like loosing details in some of my early tests, but it seems to behave better now.
Let's hope all this will become more obvious to setup one day...

3dworks
01-17-2018, 02:47 AM
welcome back exception, and thanks for the test scenes! :-)

Asticles
01-17-2018, 03:05 AM
Welcome Exception, to me the lw2018 is much better. Lw2015 was a nightmare with all those artifacts and splotches on contact surfaces.

BeeVee
01-17-2018, 03:20 AM
Part of the deal with PBR is using the new materials, so I converted all the surfaces to PBSDF using the RMB converter in the Surface Editor. For the surfaces already using materials, I manually changed them over to PBSDF mimicing their settings from Dielectric, Conductor and CarPaint (lost the flecks). I had some interesting results.

This first image is using the "Convert to PBSDF":

139516

The second is me wanting to find out how fast the scene is as supplied:

139517

The third is me saying to myself, "Hmm, using 'Convert to...' just adds a nodal version of the Surface Editor Texture Editor, that's got to be slower than piping in a nodal Image node, right?", so I converted the nodes to proper nodes IYSWIM. The result was:

139518

Yes, even slower. But it is true that for me, the PBSDF images look better.

I have attached all three versions.

B

MarcusM
01-17-2018, 05:17 AM
Glass spheres and turned off caustic?

rsfd
01-17-2018, 08:47 AM
… just a side note to Mac-Users:
you will most likely need a 3rd party decompression tool for the .7z file.

BeeVee, thanks for clearing this up, it was the first thing that came to my mind too:
there isn't much sense in using PBR without using the Principled Shader exclusively for all materials.

don't have time to work with these files, but from first sight:
using Portals should also improve quality in that scene in comparison to 2015.

MichaelT
01-17-2018, 09:35 AM
2018.0.1 with caustics on. 11 minutes, but not because of the caustics. It's because I increased light samples. The caustics appear in lower samples too.

http://forums.newtek.com/attachment.php?attachmentid=139534

This is with much lower light samples (4m 19s):

http://forums.newtek.com/attachment.php?attachmentid=139535

jwiede
01-17-2018, 09:48 AM
Here is the exact same scene, but 2 minutes into VPR munching:

2018
http://forums.newtek.com/attachment.php?attachmentid=139499&d=1516148172

Something odd's going on in the 2018 version between the closely-spaced horizontal shelves themselves (and between them and the ceiling to a lesser extent). There's a light close nearby at just the right location to cast light between the shelves, so having such dark shadows in there just looks wrong. The shadows in the 2015 version look much more "believable" given that specific geometry of lighting, compared to the 2018 result.

As noted elsewhere, those shelf shadows, as well as the shadows on the inside right ceiling edge close to the frustum, also seem overly "splotchy" w/out obvious justification.

jboudreau
01-17-2018, 10:07 AM
Hi folks,

A new year, and a brand new LW. For those that remember from when we were young uns, I used to spend most of my free time testing and making manuals for LW's GI.
As many of us are still in Arch Viz and use LW in practice on massive projects, LW's GI is still critical to our daily work.

I invite everyone to help test and improve Lw's new engine....


Hi,

Just wanted to let you know that your spherical light in 2015 is not the same as your spherical light in 2018.


You have 9.28lx for your spherical light in 2018 and 62.8% for your spherical light in 2015

If you go by the rules in the manual for a spherical light 6.28lx would be equivalent to a 100% light, So if you have 9.28lx then your spherical light should be around 150% since 12.57lx would be around 200% so 6.28lx + 3.14lx = 9.42lx which would give you around 150%

You can test this for youself, Load the 2015 scene into 2018 and you will see your 62.8% light will be converted to around 3.9438 lx

This is why your 2015 render is much lighter and there is less red light bouncing around in the scene compared to your 2018 render.

Light Rules (From the manual)

Loading a scene from a previous version of LightWave will automatically convert scene lights to the correct values, but if you need to manually convert a 100 % light from the old percentage scale to Lux you can do so according to the following rules:

Area * 3.14
Distant * 3.14
Dome * 1.57 (converted to Distant light with the appropriate angle)
Linear * 3.14
NGon * 3.14
Photometric no changes, but see note
Point * 3.14
Spherical * 6.28
Spotlight * 3.14
3rd party lights * 3.14

Thanks,
Jason

jwiede
01-17-2018, 10:14 AM
Part of the deal with PBR is using the new materials, so I converted all the surfaces to PBSDF using the RMB converter in the Surface Editor. For the surfaces already using materials, I manually changed them over to PBSDF mimicing their settings from Dielectric, Conductor and CarPaint (lost the flecks). I had some interesting results.

This first image is using the "Convert to PBSDF":

139516

The second is me wanting to find out how fast the scene is as supplied:

139517

The third is me saying to myself, "Hmm, using 'Convert to...' just adds a nodal version of the Surface Editor Texture Editor, that's got to be slower than piping in a nodal Image node, right?", so I converted the nodes to proper nodes IYSWIM. The result was:

139518

Yes, even slower. But it is true that for me, the PBSDF images look better.

Now the shadows between those horizontal shelves (and with ceiling above) look completely borked. They're even darker, and now it's as if the light in the corner isn't contributing hardly anything at all (contrary to what the highlights surrounding the fixture on its wall suggest). There also appears to be a missing reflection caustic effect from the shelves (wrong, but it's been reported elsewhere, so "expected") compared to Exception's 2018 image -- that may explain why they're "even darker" than before.

These shots now also have something odd going on in the bottom and upper left corner of the wall with the windows (same wall as square fixture). Compare the relative darkness of the shadows in those corners to the ones in the upper right corner directly by the active light fixture (?!), and between the shelves. It makes absolutely no sense for the area between the shelves right by the fixture to be so dark, yet those opposite corners (both bottom and top left) to be relatively lighter, particularly given the corners should be in shadow from the window portal's contribution as well.

Additional possible indicators of the reflection caustic issue are the rather bright, sharp reflections on the floor from the window portals, yet the lack of any corresponding reflected bright spots on the left wall. Hmm...inadequate reflection bounces could also potentially explain that, what was the setting used?

It's difficult to pin down precisely what's happening with the shadows, and why some almost randomly appear so much darker than others, while others seem "okay" (if not perhaps too light). Also, while I'd always expect some amount of "splotches" in shadows due to sampling, these still feel a bit overly pronounced in that regard. It's difficult to tell whether the additional relative darkness in such cases is just accentuating the splotches in some way.

BeeVee, do the levels of relative contrast between darkness and light in the image look correct/"expected" to you?

If not, are you aware of any "known, significant, unfixed" GI or shadow issues which might explain the issues in these renders?

jwiede
01-17-2018, 10:35 AM
Also, BeeVee, if I sound frustrated, please understand I'm just having a difficult time pinning down a clear pattern with what's occurring with shadows / light transport in the images. Any perceived frustration isn't with you or directed at you.

RPSchmidt
01-17-2018, 11:16 AM
Something odd's going on in the 2018 version between the closely-spaced horizontal shelves themselves (and between them and the ceiling to a lesser extent). There's a light close nearby at just the right location to cast light between the shelves, so having such dark shadows in there just looks wrong. The shadows in the 2015 version look much more "believable" given that specific geometry of lighting, compared to the 2018 result.

As noted elsewhere, those shelf shadows, as well as the shadows on the inside right ceiling edge close to the frustum, also seem overly "splotchy" w/out obvious justification.

I would turn off the tinted light on the opposite wall and see if the shadows below the shelves stay dark or become lighter. I feel like the tinted lighting is adding tone to the shadows below the shelves, i.e., the shadows aren't necessarily darker... they simply aren't shadows on a white wall, they are shadows on a rose colored wall. If you look at the viewer's left edge of the shadows under the shelves, you can see that the light is pentrating and the shadows there are lighter, until the white light meets the tinted light. Then you start to get a gradient shadow effect that slowly goes from white/off-white to the rose color that the tinted light is making the walls on the viewer's right of the shelves.

Even changing the tinted light to white may make the difference.

I think the only way to truly track down percieved issues here is to render the scene using each light source by itself so that you can see what overall effect each light source is having on the scene, then start adding back each light source until you identify where the issue lies.

rsfd
01-17-2018, 11:27 AM
Something odd's going on in the 2018 version between the closely-spaced horizontal shelves themselves (and between them and the ceiling to a lesser extent). There's a light close nearby at just the right location to cast light between the shelves, so having such dark shadows in there just looks wrong. The shadows in the 2015 version look much more "believable" given that specific geometry of lighting, compared to the 2018 result.
In this case, I would contradict you: the 2018 result (to me) seems _more_ believable. The main light comes from the ceiling, which by itself would result in deep shadows between the shelves. The openings in the wall don't do much to brighten these shadows (too low). Only the "Glowbox" does. But from its position (height and distances to the walls and to the shelves) and its intensity, it also cannot brighten the shadows up. The light can only "crawl" between those shelves at the part opposite to the camera, but then it is getting more and more blocked by the shelves, as the light travels trough the boards. (The Glowbox does light from a very flat angle onto the right wall: there isn't much light energy falling on that wall by this light).

MichaelT
01-17-2018, 11:34 AM
It has a little to do with samples, caustics etc.. too. (as can be seen in my post (http://forums.newtek.com/showthread.php?155730-Big-Bad-2018-2015-Global-Illumination-shootout&p=1533782&viewfull=1#post1533782) earlier, where it isn't as dark)

Exception
01-17-2018, 11:36 AM
Great discussion so far.
I agree with the problems. We have a long way to go to get the radiosity engine back into the ballpark of an industry standard. Virtually every modern render engine runs circles around LW both in terms of GI speed and quality.

2015, in this scene, has an added handicap of severe light leaks in the bottom edge.

I tried this scene with brute force Mc, but the results are consistently too grainy to be usable, even after an hour at low res.

MichaelT
01-17-2018, 11:46 AM
Great discussion so far.
I agree with the problems. We have a long way to go to get the radiosity engine back into the ballpark of an industry standard. Virtually every modern render engine runs circles around LW both in terms of GI speed and quality.

2015, in this scene, has an added handicap of severe light leaks in the bottom edge.

I tried this scene with brute force Mc, but the results are consistently too grainy to be usable, even after an hour at low res.

Then you are probably not using the rendering buffers to your advantage :)

But to get an idea what you're thinking of.. which areas in particular is annoying you? (In the image I mean)

jwiede
01-17-2018, 11:49 AM
In this case, I would contradict you: the 2018 result (to me) seems _more_ believable. The main light comes from the ceiling, which by itself would result in deep shadows between the shelves. The openings in the wall don't do much to brighten these shadows (too low). Only the "Glowbox" does. But from its position (height and distances to the walls and to the shelves) and its intensity, it also cannot brighten the shadows up.

If that's the case, then the shelves' shadow should continue much more prominently "down the wall", but it very clearly doesn't. The deep, dark shadow only occurs between the shelves, but neither above or below at anywhere near the same strength. The shapes and depths of the shelves' shadows also change (becoming less detailed/distinct) in BeeVee's examples compared to Exception's examples, without any clear justification -- I could understand levels changing a little, but the rather obvious loss of shadow detail between the shelves is difficult to justify in BeeVee's examples.

Further, in the scenario you're suggesting, there should also be stronger, darker shadows from the (opaque!) mirror ball both on the side opposite the portals, as well as directly under the mirror ball (given top lighting). However, those shadows aren't nearly as "deep" as the ones between the shelves (except in an unexpectedly small radius directly where the sphere touches the floor). The mirror ball should also have three visibly-distinct shadows (with a couple quite strong), yet clearly does not.

jboudreau
01-17-2018, 11:52 AM
Great discussion so far.
I agree with the problems. We have a long way to go to get the radiosity engine back into the ballpark of an industry standard. Virtually every modern render engine runs circles around LW both in terms of GI speed and quality.

2015, in this scene, has an added handicap of severe light leaks in the bottom edge.

I tried this scene with brute force Mc, but the results are consistently too grainy to be usable, even after an hour at low res.

Yes I ran into these problems too. severe light leak and noisy renders.

Thanks,
Jason

jwiede
01-17-2018, 12:32 PM
While LW2015 had plenty of flaws, when it came to consistent, reasonably accurate radiosity solutions for cast light and shadows, it did an adequately decent job (for stills, anyway). The first comparison Exception did showed quite clearly that not only do LW2018's results vary from LW2015's in light levels for shadows, and their edge sharpness, the results even vary regarding the shadows' basic shapes (note the missing triangular "notches" in the shelves' shadows towards the portal wall side compared to LW2015 result).

Given the example results shown for each version, as well as the already-reported issues where LW2018 isn't properly managing light beams' directions, I'm much more inclined to believe LW2015's results over LW2018's results. LW2015's results more closely match what I'd expect in real-world optics, while (IMO) LW2018's results appear to have issues.

If I can find time (perhaps this weekend), I might try to put a similar example together and see what Vray, MODO, and Maxwell (and if I have more time, Thea and the Krays) produce in an optically-similar situation.

rsfd
01-17-2018, 04:43 PM
If that's the case, then the shelves' shadow should continue much more prominently "down the wall", but it very clearly doesn't.
No, the shadow below the shelves is brightened by the „windows” light, to a certain extend by the direct „red” light and the overall GI bounces.


The deep, dark shadow only occurs between the shelves, but neither above or below at anywhere near the same strength.
Yes, and that’s what to expect: above the shelves, we have brightening by the Glowbox-light (with bounces from the over-hanging top wall part and bounces from the top light onto the top board (with additional bounces again from the over-hanging wall part).


The shapes and depths of the shelves' shadows also change (becoming less detailed/distinct) in BeeVee's examples compared to Exception's examples, without any clear justification
As we have multiple lights in the scene, we also get shadows accordingly. As the lights come from various directions, we get overlapping shadows.
How pronounced these appear in an image is effectively down to the overall relationship of the lights direction, quality (more diffuse or more direct/hard) and intensity.
We would see completely different results, if we would begin to „play” solely with the various lights intensities. And of course, we would get completely different shadows.


-- I could understand levels changing a little, but the rather obvious loss of shadow detail between the shelves is difficult to justify in BeeVee's examples.
The shadows here are a result of the mixture of lights from various origins, various quality and different falloffs.


Further, in the scenario you're suggesting, there should also be stronger, darker shadows from the (opaque!) mirror ball both on the side opposite the portals, as well as directly under the mirror ball (given top lighting). However, those shadows aren't nearly as "deep" as the ones between the shelves (except in an unexpectedly small radius directly where the sphere touches the floor).
Not quite sure, which side you refer to as opposite to the portals, but I hope I was getting it right:
The side towards the camera is pretty much pure (material’s) reflection: it just shows the brightness level of the room. There is no shadowing to expect from any light source.
The shadow directly beneath the mirror ball is -as you noticed yourself- more pronounced. It’s because the ball itself is hiding the floor from nearly every GI.
The wall with the shelves does not get pronounced shadowing from the ball, because the ball is placed within an area of no direct light from the „windows”, which results in a very soft and diffused light with no pronounced shadows. The direct light from outside does not hit the mirror-ball with any direct rays (even the first couple of bounced rays would have wrong direction to hit the mirror-ball.
The wall additionally is -to a certain extend- illuminated by the Glowbox, the rest is done by the red light.


The mirror ball should also have three visibly-distinct shadows (with a couple quite strong), yet clearly does not.
Shadows from where? You mean one each by the „windows”, the Glowbox and the top-light?
These are all „eaten up” by the GI and by the mirror-ball „self-brightening” its sourrounding by GI-reflection. Also: the floor material has a high reflection proportion (more specular reflection than diffuse reflection). The shelves btw. share the mirror-ball material. The mirror-ball does not get any direct light (except from the Glowbox (but that one also has some Roughness setting, which should result in a more diffuse light), thus no pronounced shadow(s).

The two areas between the shelves are literally the only places within the scene, that aren’t that highly illuminated by the GI, thus the only places with shadows.

(As a side-note and as a professional photographer: to me, the 2018 result is more believable, has a better „real-world / real photography” look).

Exception
01-17-2018, 05:54 PM
Then you are probably not using the rendering buffers to your advantage :)

But to get an idea what you're thinking of.. which areas in particular is annoying you? (In the image I mean)

Why would the render buffers matter here?
As for the light leaks, make a render (not vpr) in 2015 and you'll see. Light leaks all over the bottom edge, unusable results.

MichaelT
01-17-2018, 06:19 PM
Why would the render buffers matter here?
As for the light leaks, make a render (not vpr) in 2015 and you'll see. Light leaks all over the bottom edge, unusable results.

What I mean is that activating them, and using their different settings can really help getting rid of noise. I use VPR, and looking at the buffers directly to find what I can tweak quite often now. It really helps.

Bottom edge? where? There are leaks, but there are also spaces here, and there in the model where there would be "leaks" (like the bottom part of the shelves which don't fully touch the wall for instance) I don't really follow you I'm afraid.

jboudreau
01-17-2018, 08:00 PM
What I mean is that activating them, and using their different settings can really help getting rid of noise. I use VPR, and looking at the buffers directly to find what I can tweak quite often now. It really helps.

Bottom edge? where? There are leaks, but there are also spaces here, and there in the model where there would be "leaks" (like the bottom part of the shelves which don't fully touch the wall for instance) I don't really follow you I'm afraid.

I looked at his model and there are no spaces around the base of the floor, but there are light leaks like he said. Here is what he is talking about regarding the light leaks

139549

Thanks,
Jason

Asticles
01-17-2018, 11:55 PM
Something odd's going on in the 2018 version between the closely-spaced horizontal shelves themselves (and between them and the ceiling to a lesser extent). There's a light close nearby at just the right location to cast light between the shelves, so having such dark shadows in there just looks wrong. The shadows in the 2015 version look much more "believable" given that specific geometry of lighting, compared to the 2018 result.

As noted elsewhere, those shelf shadows, as well as the shadows on the inside right ceiling edge close to the frustum, also seem overly "splotchy" w/out obvious justification.

This could be because something I has noticed, LW interpolated is much more brighter than brute force. Can you make the test with brute force only? Maybe this happens only in 2018.0.1

Regards

MichaelT
01-18-2018, 12:17 AM
I looked at his model and there are no spaces around the base of the floor, but there are light leaks like he said. Here is what he is talking about regarding the light leaks

139549

Thanks,
Jason

First off.. thats LW2015 :) Secondly, that's because he has a few 2 point lines around the floor. But that is an easy enough mistake, easily missed.
Just remove them, and it will be better.

139550
139551

Exception
01-18-2018, 12:23 AM
What I mean is that activating them, and using their different settings can really help getting rid of noise. I use VPR, and looking at the buffers directly to find what I can tweak quite often now. It really helps.

Myeah I don't think you're getting the degree of noise we're talking about :) . Check out our for yourself, perhaps?




Bottom edge? where? There are leaks, but there are also spaces here, and there in the model where there would be "leaks" (like the bottom part of the shelves which don't fully touch the wall for instance) I don't really follow you I'm afraid.

You have to make a render in 2015 to see them, as suggested, then it'll be obvious to you. Apparently they're because of some 2 point poly's, an easy fix (it still shouldn't do that).

- - - Updated - - -


This could be because something I has noticed, LW interpolated is much more brighter than brute force. Can you make the test with brute force only? Maybe this happens only in 2018.0.1

Regards

Yes I also noticed a brightness difference between MC and interpolated.

kolby
01-18-2018, 01:12 AM
Hi, I read this in online docs:

Rays - Brute Force Global Illumination Rays (BFGI). Sets how many GI samples are used per pixel. These are used with Sample Corners in Interpolated mode and MinPS. When MinPS doesn't have enough samples for a detected corner, it will be sampled directly using Brute Force rather than interpolated rays.

I'm playing with number of BF samples in interpolated mode, different MinPS and it seem it does nothing. Could anyone explain how that works ? Examples ?

omichon
01-18-2018, 01:18 AM
Hi, I read this in online docs:

Rays - Brute Force Global Illumination Rays (BFGI). Sets how many GI samples are used per pixel. These are used with Sample Corners in Interpolated mode and MinPS. When MinPS doesn't have enough samples for a detected corner, it will be sampled directly using Brute Force rather than interpolated rays.

I'm playing with number of BF samples in interpolated mode, different MinPS and it seem it does nothing. Could anyone explain how that works ? Examples ?

This part of the documentation needs an update, I think ;D

Exception
01-18-2018, 01:36 AM
FYI the level of noise with pure MC after a few minutes:

139552

Not sure how any use of buffers will help with this :D

Exception
01-18-2018, 01:51 AM
Hi, I read this in online docs:

Rays - Brute Force Global Illumination Rays (BFGI). Sets how many GI samples are used per pixel. These are used with Sample Corners in Interpolated mode and MinPS. When MinPS doesn't have enough samples for a detected corner, it will be sampled directly using Brute Force rather than interpolated rays.

I'm playing with number of BF samples in interpolated mode, different MinPS and it seem it does nothing. Could anyone explain how that works ? Examples ?

Hi Kolby,

so if I understand the new functioning correctly, the BFGI setting doesn't matter much for interpolated mode except for missing samples (which can be a frequent condition in very high detail scenes I think but not normally). Sample Corners has been removed.
It's also possible that the first render pass uses BFGI to do a brute force sample pass, and then it's interpolated... that's how Final Gather used to work, and it seems to be doing something like that now as well.

MinPS is the minimum pixel-distance between samples in interpolated mode. MaxPs is the maximum, and samples get placed in between that range. You can check how they work by using the test flags at the bottom of the panel. Here's a small demo:

With MinPs set at 1 pixel:

139553

With MinPs set at 10 pixels:

139554

As you can see, a massive difference. Having too few samples leads to blotching and vague definition, and too many samples causes long render times and memory use.

Exception
01-18-2018, 01:53 AM
Hi,

Just wanted to let you know that your spherical light in 2015 is not the same as your spherical light in 2018.
You have 9.28lx for your spherical light in 2018 and 62.8% for your spherical light in 2015.

Hi Jason,
Yes I know, I mentioned it in the original post, and why I did that on purpose.

BeeVee
01-18-2018, 02:16 AM
Hi, I read this in online docs:

Rays - Brute Force Global Illumination Rays (BFGI). Sets how many GI samples are used per pixel. These are used with Sample Corners in Interpolated mode and MinPS. When MinPS doesn't have enough samples for a detected corner, it will be sampled directly using Brute Force rather than interpolated rays.

I'm playing with number of BF samples in interpolated mode, different MinPS and it seem it does nothing. Could anyone explain how that works ? Examples ?

Hmm, interesting. If you look carefully at that page you'll see that it's for "LightWave 2017", and shouldn't even be available for reading. The 2018 version is correct.

B

MichaelT
01-18-2018, 02:25 AM
FYI the level of noise with pure MC after a few minutes:

139552

Not sure how any use of buffers will help with this :D

Whoa... what settings are you using? I don't get anything like that at all.

And why do you insist on pure MC? No other engine does that. They all interpolate to get
rid of their noise. If you turn that off, there isn't an engine on the planet that wouldn't suffer noise.
With many engines you can't turn it off, even if you wanted to. Because that part is built into it.

(And by all, I am obviously not referring to every single engine that ever existed. But as a general
rule of thumb.. If it renders fast, it cheats. What it is doing is the interesting part, but that's another topic)

Here is what I get after 1min. And by using the buffers like I mentioned. But that also requires
that interpolation is active.

139555

Here is the same, without interpolation:

139556

There is no reason why you would want to do that, other than going for the pure renders. But that would take
ages to finish. And a massive amount of time to clean up its unavoidable noise.

Edit:

And just to drive home that even programs like Octane suffers from this. This is Octane with path tracing
(not the quicker cheat "direct lighting", although nice.. isn't correct) after 1 minute:

(The materials aren't the same.. but I didn't want to waste time making it.. as it is the noise I'm interested in)
139561

kolby
01-18-2018, 03:25 AM
Hmm, interesting. If you look carefully at that page you'll see that it's for "LightWave 2017", and shouldn't even be available for reading. The 2018 version is correct. B

It is in documentation for LW2018. https://docs.lightwave3d.com/display/LW2018/Global+Illumination+tab#GlobalIlluminationtab-BruteForce

omichon
01-18-2018, 03:33 AM
Ben, it has been reported (LWB-3090)

BeeVee
01-18-2018, 05:06 AM
Merci !

B

tischbein3
01-18-2018, 06:13 AM
Now the shadows between those horizontal shelves (and with ceiling above) look completely borked.
Thats a problem with interpolated GI:
Rise the amount of rays (1200 primary 400 secondary) and lower the interpolation softness to 10%
From my experiments the quality of the shading rises extremely while render time keeps in the sub 5 minutes area.

Edit:
Notice also how the shadows/shading in the top opening are much more defined...

Sanchon
01-18-2018, 06:18 AM
Can someone remove this boxed luminous light on the top and see difference in shelves shadows ? I don't have LW2018 yet to make tests.

MichaelT
01-18-2018, 06:36 AM
Can someone remove this boxed luminous light on the top and see difference in shelves shadows ? I don't have LW2018 yet to make tests.

Here you go:

139562

But download the trial :)

Sanchon
01-18-2018, 06:43 AM
Here you go:


Thank you. As for my eye these shadows looks good if we have strong light ( window ) from the lower side of the shelves. Maybe a little to dark between shelves. I wonder what it would look in different renderer like Octane or Vray.

MichaelT
01-18-2018, 06:48 AM
Thank you. As for my eye these shadows looks good if we have strong light ( window ) from the lower side of the shelves. Maybe a little to dark between shelves. I wonder what it would look in different renderer like Octane or Vray.

I made a quick Octane one here: http://forums.newtek.com/showthread.php?155730-Big-Bad-2018-2015-Global-Illumination-shootout&p=1533919&viewfull=1#post1533919

But even though that was for pointing out that most engines suffer the noise curse (it is simply an artifact of having to sample towards image convergence as I'm certain you know already :) But for those who don't)

Still.. there are ways to mitigate the dark shadows. Using environment light in the scene, that helps sample the light in a room more efficiently. Use of caustics.. (all objects have them) but it is like most other things. You need to tweak to get things right. There isn't really a silver bullet to this. Although you can create template scenes, that work for certain situations (to help you get started more quickly)

But LWG do need to work on improving speed and such.. it is a bit slower than V-Ray for instance. Which (after all) is also CPU based at its core, and still manages to keep up with GPU (on my machine at least) Also, maybe looking into the interpolations... to try and lower the frequency of illuminated splotches. Not impossible to get rid of.. but they are irritating (to me at least)

Sanchon
01-18-2018, 07:00 AM
Octane version is much better but there is different light setup - much more indirect light that make this room brighter at all. People from Vray had many years to focus only on renderer. As we know there is no person in LW team which focusing only on render engine. But unfortunately this is not an explanation of why the renderer could not be better.

MichaelT
01-18-2018, 07:11 AM
Octane version is much better but there is different light setup - much more indirect light that make this room brighter at all. People from Vray had many years to focus only on renderer. As we know there is no person in LW team which focusing only on render engine. But unfortunately this is not an explanation of why the renderer could not be better.

Yeah I know... but like I mentioned in the post. It was for noise study, and for that it works as it is set up. There is also a hole in the ceiling letting more direct light in that way.
I don't know.. they probably have more than one person focused on the rendering engine. As that have always been a selling point for LW. But in the end, it is only guessing on our part.
We won't know unless they tell us.

But V-Ray have had a long head start with this type of engine.. that's for certain. But now that they have one themselves.. I think they should focus on getting noise, splotches down first .. and fix the GI thing they're working on. After that they can improve speeds etc.. But again.. I have little doubt they already have some general idea where they want to go :)

jboudreau
01-18-2018, 07:49 AM
First off.. thats LW2015 :) Secondly, that's because he has a few 2 point lines around the floor. But that is an easy enough mistake, easily missed.
Just remove them, and it will be better.

139550
139551

Sorry man, I missed that, I thought when you said a space you meant there was a space between the wall and the floor. Thanks for pointing this out to us :)

RPSchmidt
01-18-2018, 07:59 AM
Thats a problem with interpolated GI:
Rise the amount of rays (1200 primary 400 secondary) and lower the interpolation softness to 10%
From my experiments the quality of the shading rises extremely while render time keeps in the sub 5 minutes area.

Edit:
Notice also how the shadows/shading in the top opening are much more defined...

I just wanted to say that to my eyes, that is the best render of this scene so far.

Rayek
01-18-2018, 02:37 PM
If I can find time (perhaps this weekend), I might try to put a similar example together and see what Vray, MODO, and Maxwell (and if I have more time, Thea and the Krays) produce in an optically-similar situation.

Ahead of you with Cycles and AMD's ProRender! I was planning to do add LuxRender and AppleSeed as well for comparison, but those I will do this weekend. And perhaps another one, if I find the time. It is always interesting to compare render engines.

I said my goodbyes in this forum a while ago, but I found the new path tracer in LW2018 intriguing, so I am posting some comparisons and tests here (just out of academic interest). I tested the same scene in Cycles and ProRender for fun. I limited render time to around 15 minutes or a "good enough" final result, and I decided to double the render resolution to twice of the original's setting (because I feel 640x480 isn't very realistic for testing, nor can details be made out).

Turning on caustics in Lightwave would cause render times to go through the roof, so I decided to leave it turned off. Full GI with caustics and caustic reflections are turned on for both Cycles and ProRender, though.

For the Lightwave version I initially got rather ugly looking light blending:
Time: 8m32s CPU
Max memory usage during rendering: 632MB
No caustics.

http://i68.tinypic.com/29qkxz6.png



I then increased the ray samples suggested above which results in a much better result:
Time: 16m48s CPU
Max memory usage during rendering: 1.1GB(!)
No caustics

http://i68.tinypic.com/1z48m4l.png



Next, I imported the scene into Blender. I came pretty close to the original's lighting setup. The latest Blender 2.79 builds allow Cycles to render simultaneously with GPU and CPU! Game changer!
Some objects had to be fixed: the geometry was lacking, and caused render issues here and there. I had to replace the spheres, for example. I used 2500 samples.
Time: 10m24s combined GPU+CPU
Max memory usage during rendering: 12MB
Full GI (including caustics)

http://i68.tinypic.com/2u4pu1v.png



Next, I rendered the scene in ProRender. v1.5 would lock up, and I had to fall back to v1.4 - which does not include a de-noiser, unfortunately. We'll just have to imagine this render without noise then. I had to fix the geometry of the back wall (above the small window) to prevent black triangles in the render (overlapping vertex, or something). The lighting setup is quite different, as I used the built-in sun object to light the environment.
Time: 14m00s
Max memory usage during rendering: ~350mb
Full GI (including caustics)

http://i63.tinypic.com/2hguz2w.png


Some tentative conclusions on my part.

1) Lightwave's new renderer produces less than ideal anti-aliasing. It's quite problematic. I noticed this in most of the other test renders presented by other users as well. Can this be fixed somehow?

2) I find the overall colour to be too saturated and blown-out. It might be due to non-linear color management, or something. I am no expert, but I feel the default final colour setups in ProRender and Cycles to be much preferred.

3) Lightwave's new render setup is rather difficult to manage. In other render engines I am up and running in a few clicks to produce good looking renders, but in Lightwave I had to perform a lot of trial and error. There doesn't seem to be a quick method to convert standard materials to the new PBR ones either. In Blender an addon is available to convert old-style raytracer scenes to Cycles materials with on click. In ProRender the material library option helped me convert the scene within minutes.

My first impression of the LW2018 path tracer in regards to usability is marred by the neurotic GUI. It's all over the place, and no smart and simple presets are offered. It feels unfinished in this respect.

4) It would have been nice if Lightwave had maintained the old render engine side by side with the new render engine. In Blender, for example, both the old and the new engines are easily switched between, if required. I would have loved to see that option in LW2018.

5) As mentioned by others here, the new 2018 path tracer still has some issues and bugs. I encountered this after turning on caustics for this scene: it resulted in quite an interesting blotchy art piece. Also notice the light leak in the top corner.

6) No GPU option is a bit of a showstopper. With the competition now implementing options to leverage BOTH GPU and CPU simultaneously while rendering, Lightwave's path tracer can't really hope to compete in terms of speed. I used to import scenes from other software into Lightwave Layout just for the effective and quick CPU rendering. That option is no longer available in LW2018, and the path tracer too slow because of its CPU-only limitation.

7) Memory usage! What's going on with this simple scene and the high memory usage in Lightwave's path tracer? Perhaps it was me not knowing how to set it up properly for efficient rendering, but the second version gobbled up more than 1 gig of ram! Compare to Cycles, which never went beyond 12.1mb of memory usage.

8) Full GI with caustics isn't a realistic proposition with CPU only, I think. At least, not without multiple render nodes. It might not be seen as a fair comparison, but GPUs make waiting for a path tracer to finish much more digestible. And it is relatively simple to add a new GPU when required, instead of setting up a new render machine.

9) Lightwave still locks up while rendering. I am not used to that anymore. It's annoying. I can't work on the scene while it is rendering. I had hoped they'd fixed that - but perhaps too forward-thinking?

10) Often I made changes to a material, or render setting, only to find I couldn't undo it. The undo is still broken, and made me want to scream at times.

All in all, it will need some work on the developers' part. It doesn't feel like a finished, user-friendly path tracer implementation/integration just yet. The lack of examples, user interaction, and tutorials from Newtek is worrying (again). I checked the new documentation, which is fine as a function reference, but lacks good examples of render workflows. I couldn't find much about how to deal with and properly set up caustics.

What I don't understand is spending so much time developing a new render engine, and not providing enough support to make the transition easier. Or simple presets - I am not that familiar with AMD's ProRender either, but I had no issues finding my way and it provided nice one-click render setups.

This, and the lack of GPU support is probably going to make life quite difficult compared to other path tracers.
At least the documentation and support can be fixed relatively easily - I hope they will.

MichaelT
01-18-2018, 02:52 PM
I keep saying this but :) - Use the feedback option in the help menus. It is the fastest, and best way to get a ticket regarding all issues in their systems. And the more people who report the same thing, the more attention it will get.

gar26lw
01-18-2018, 03:27 PM
excellent comparison and notes, Rayek. i hope the devs are reading this.

id be interested to see a comparison to Arnold here too.

Asticles
01-18-2018, 03:52 PM
Hi Rayek. I would to say in favour of lightwave, that you are getting similar (less but not so far) times in rendering with two engines that are using both gpu and cpu vs an engine that is only cpu.

Also using a gpu that maybe is four times faster than your cpu in brute force.

Regards

Rayek
01-18-2018, 04:01 PM
excellent comparison and notes, Rayek. i hope the devs are reading this.

id be interested to see a comparison to Arnold here too.

Thank you. It is always difficult to compare render engines directly, of course. One thing that slowed me down quite a bit in Lightwave was VPR, or I have to say the lack of a good and quick previewer. With Cycles and ProRender I displayed a viewport that updates with every change. It would resolve very fast, and both render engines provide options to control the preview with simple settings.

For the life of me, I couldn't get VPR to assist me at all. It's just too slow, or too undefined, or both. I am unsure what is going on - I suppose the developers could not have VPU gobble up all available CPU time in order to keep Layout responsive. That's the only explanation I can come up with. In the previous versions VPR was actually very helpful - not in this version (yet?).

I had to resort to creating preview renders instead, which slowed down the entire workflow. This is one area where having a dedicated GPU working on that viewport, while the CPU is left to handle the rest, really helps. The thing is, even in CPU mode Blender's preview would resolve much faster, and was helpful in quickly setting up things.

PS Just a random thought. Maxon integrates ProRender in Cinema4D - while I was skeptical of that decision at first, I now understand why: instead of reinventing the wheel and spend a LOT of time and money on developing a new render engine, the developer can focus on providing a first-rate and user-friendly experience in their application. And have all the fruits of a separate dedicated team working on new render engine features.

Newtek could have either implemented Cycles (of which the license allows commercial branch-offs) or AMD ProRender, and have a mature full GPU and CPU enabled path tracer, and focus on usability. With Cycles they'd not only could have saved tons of work, but have a GPU/CPU option too.

Well, as they say "hindsight is 50/50".



This weekend I will compare to some other (open and free) render engines.

jwiede
01-18-2018, 04:27 PM
(LW2018)
http://i68.tinypic.com/1z48m4l.png

(Cycles)
http://i68.tinypic.com/2u4pu1v.png


The substantially lighter shadows between the shelves in the Cycles version (and their shapes, and relative highlights/lowlights) are almost exactly what I'd expected and described, and (IMO, anyway) significantly "closer" to Exception's LW2015.3 version in that regard than any of the LW2018 versions.

Likewise, the corner right by the "glowbox" fixture in the Cycles version also looks much more believable than in the LW2018 versions (where the vertical edge corner, up where the walls meet the ceiling, looks too dark compared to the other corner edges). The Cycles version once again seems closer to Exception's LW2015 version than the LW2018 version in that regard as well.

It almost looks like LW2018 is having an issue with the corner transitions from the "side" walls to the "back" wall (and the "back" wall to its soffit), compare those corners to the inside corners between the "side" walls and their soffits to see what I mean. The tiny light leak between the "back" wall and its soffit far to the left additionally suggests there may be something odd going on with that "back" wall.

After looking at the GIBox2018 scene & model, I see nothing about the geometry of the object that would yield such issues or why some corners are being treated differently than others (nor any valid justification for the light leak).

Exception
01-18-2018, 05:23 PM
And why do you insist on pure MC? No other engine does that. They all interpolate to get
rid of their noise.

Thanks for your tests and insights.
I'm not sure where it comes across that I "insist" on using pure MC. I didn't even include it in the original post. I don't think it's a viable option either.

That said, what I hear from the developers is that they think pure MC is a long term replacement for interpolated. Interpolated as it is now is implemented as a secondary choice. Which may explain why it hasn't advanced much from 2015 onwards.
It will be up to us as users to cry out for a more thoroughly implemented 'interpolated' Gi solution. Right now we have the choice of perfect but extremely slow pure MC, and fussy, difficult, and not impressively fast Interpolated mode.

I love your assessment that pure MC is a non-choice. I agree. Let's make this clear to the developers?

Here's a pure MC render (not VPR) after 1 hour and 45 minutes with high settings (10 BFGI rays, AA AS 10-20, caustics and ISBG sampling on). An attempt to make a noise free pure MC render, which failed, obviously.
This may be useful as reference on how the render engine thinks perfection should look like. I do think I had the distant light have a softness angle on this though.

http://forums.newtek.com/attachment.php?attachmentid=139579&d=1516321590

Exception
01-18-2018, 05:40 PM
Rayek, thanks for those very insightful comparisons.
Am I the only one in thinking that the LW renders look far more crisp? The Cycles render almost looks as if it was a lower resolution scaled up?
Also the reflection of the thin vertical rods in the foreground in the cycles render don't reflect the red light at all.

I love tischbein3's discovery on the high ray settings, I'll definitely try this out!

m.d.
01-18-2018, 06:36 PM
Rayek, thanks for those very insightful comparisons.
Am I the only one in thinking that the LW renders look far more crisp? The Cycles render almost looks as if it was a lower resolution scaled up?
Also the reflection of the thin vertical rods in the foreground in the cycles render don't reflect the red light at all.

I love tischbein3's discovery on the high ray settings, I'll definitely try this out!

Those cycles renders look hideously soft...my first impression, and I was biased and looking forward to a kick *** cycles render. The GI looked proper however.

The shadow falloff in the shelves, accompanied by the oversaturation really looks like the 2018 scene is rendering and saving linear....should have 2.2 applied post render by the looks of it.


EDIT:

Love having you back Exception....
I poured over your original radiosity guides memorizing pretty well every line. By far the most precise and informative LW rendering guide there was.

samurai_x
01-18-2018, 06:41 PM
Next, I imported the scene into Blender. I came pretty close to the original's lighting setup. The latest Blender 2.79 builds allow Cycles to render simultaneously with GPU and CPU! Game changer!
Some objects had to be fixed: the geometry was lacking, and caused render issues here and there. I had to replace the spheres, for example. I used 2500 samples.
Time: 10m24s combined GPU+CPU
Max memory usage during rendering: 12MB
Full GI (including caustics)

http://i68.tinypic.com/2u4pu1v.png.

Can you post the blend file? That is slow for a gpu renderer. What's your system spec?

Sanchon
01-18-2018, 07:13 PM
I think that this default scene has broken light setup compared to another render engines. This is why LW render looks like old 2012 renderer compared to the new ones. Too much direct light, too less indirect - this is why between shelvees we have darkness. I'm not expert in interiors but as I know old render engine, please make radiosity intensity - 800%, outside light at 500% more, lower material diffusion to not to be overexposed, crank up bounces to 6 and between shelves should not to be any darkness.

LW should have tone mapping implemented directly in VPR and this problem will be gone. Tone mapping can fix most of the current renderer problems.

And please make in mind that if human eye is in interior ( or if you make photo ) all exterior view is overexposed because direct sunlight is too bright for eye. In this LW render I can't see it. Backdrop and sun intensity should be overxeposed. More light in interior, lower diffusion on walls as it is in natural.

Rayek
01-18-2018, 07:36 PM
Can you post the blend file? That is slow for a gpu renderer. What's your system spec?

The GTX1080 is actually not that great for GPU rendering, as it turns out. I read an article about it online - I believe a Blender GPU - CPU test one.

I've uploaded my version. Here it is:

http://www.wizzydev.com/uploads/scene.zip

I created a quick conversion, so it may well be that things can be optimized more.

As for the softness: for one it uses the denoiser to remove the noise. Remember that this is a "brute force" render - very different from the Lightwave version. The softness can be sharpened in post. But I agree, the raw render looks definitely fuzzier.

On the other hand, I feel the original LW scene is overly sharp looking though, and looks less realistic. To really compare, I'd have to render the LW scene with full GI and in brute mode, but that would take ages on my system before it resolves into something usable.

Btw, another test:
My question is, how can I get the final result to look more like Cycles? It looks to me as if Lightwave is not working linearly somehow. The colours are too strong, and the shadows too obvious. I also cannot get the lighting right: whatever I try it blows out. I increased the HDR brightness, intensity, distant light, combinations, but it either blows out or is too contrast rich.

I'd like a similar render as Cycles. Any advice is appreciated. I can share the scene.

Lightwave (~2 minutes):

http://i68.tinypic.com/157kuwk.jpg

Blender Cycles(4m40s)
http://i67.tinypic.com/2urp6x3.jpg

And just for fun Blender Eevee pre2.8 (2 seconds). Eevee is fun.
http://i63.tinypic.com/107w6zl.png

Sanchon
01-18-2018, 07:42 PM
It looks like differnet lighting between LW and Blender. Can you crank up radiosity, lower direct light to make it the same as in Blender ? And also on the glass - it looks like in the blender version you have much more intensity in the backdrop image.

Rayek
01-18-2018, 07:46 PM
I know, but as far as I can tell I replicated the lighting setup. Both have one distant light, and a HDR environment map for lighting.

Not sure if I am allowed to share it directly, though. I got it here: http://scifi3d.com/download.asp?intGenreID=10&intCatID=10&filekey=1022&key=592

jboudreau
01-18-2018, 07:49 PM
Ahead of you with Cycles and AMD's ProRender! I was planning to do add LuxRender and AppleSeed as well for comparison, but those I will do this weekend. And perhaps another one, if I find the time. It is always interesting to compare render engines.

I said my goodbyes in this forum a while ago, but I found the new path tracer in LW2018 intriguing, so I am posting some comparisons and tests here (just out of academic interest). I tested the same scene in Cycles and ProRender for fun. I limited render time to around 15 minutes or a "good enough" final result, and I decided to double the render resolution to twice of the original's setting (because I feel 640x480 isn't very realistic for testing, nor can details be made out).

Turning on caustics in Lightwave would cause render times to go through the roof, so I decided to leave it turned off. Full GI with caustics and caustic reflections are turned on for both Cycles and ProRender, though.

For the Lightwave version I initially got rather ugly looking light blending:
Time: 8m32s CPU
Max memory usage during rendering: 632MB
No caustics.

http://i68.tinypic.com/29qkxz6.png



I then increased the ray samples suggested above which results in a much better result:
Time: 16m48s CPU
Max memory usage during rendering: 1.1GB(!)
No caustics

http://i68.tinypic.com/1z48m4l.png



Next, I imported the scene into Blender. I came pretty close to the original's lighting setup. The latest Blender 2.79 builds allow Cycles to render simultaneously with GPU and CPU! Game changer!
Some objects had to be fixed: the geometry was lacking, and caused render issues here and there. I had to replace the spheres, for example. I used 2500 samples.
Time: 10m24s combined GPU+CPU
Max memory usage during rendering: 12MB
Full GI (including caustics)

http://i68.tinypic.com/2u4pu1v.png



I think the newtek forum is stretching the images. Here is my render in lightwave 2018 at 1280x960 took 6min 12 Seconds to render on 8 thread laptop

139585

http://animatrixproductions.com/Test_Render.png

Sanchon
01-18-2018, 07:57 PM
In the LW images there is something bad in the top right side of the image - at the top of the shelves. Too much defined contact shadow and not too smooth transition beetwen lower side of image. Left side is ok. Blender did this better.

Interiors are not my business. Anyone tested the new renderer and materials with exterior arch-viz images ?

jboudreau
01-18-2018, 08:01 PM
In the LW images there is something bad in the top right side of the image - at the top of the shelves. Too much defined contact shadow and not too smooth transition beetwen lower side of image. Left side is ok. Blender did this better.

Interiors are not my business. Anyone tested the new renderer and materials with exterior arch-viz images ?

yes I agree, I'm going to see if I can change some settings to get closer to what blender did.

Rayek
01-18-2018, 08:11 PM
I think the newtek forum is stretching the images. Here is my render in lightwave 2018 at 1280x960 took 6min 12 Seconds to render on 8 thread laptop

139585

http://animatrixproductions.com/Test_Render.png

I see various problems. The most glaring one are the patchy transitions on the walls. How many samples/rays did you fire? I think it needs more.

And I'd like to see those blown-outs on the floor fixed.

jboudreau
01-18-2018, 09:20 PM
The GTX1080 is actually not that great for GPU rendering, as it turns out. I read an article about it online - I believe a Blender GPU - CPU test one.

I've uploaded my version. Here it is:

http://www.wizzydev.com/uploads/scene.zip

I created a quick conversion, so it may well be that things can be optimized more.

As for the softness: for one it uses the denoiser to remove the noise. Remember that this is a "brute force" render - very different from the Lightwave version. The softness can be sharpened in post. But I agree, the raw render looks definitely fuzzier.

On the other hand, I feel the original LW scene is overly sharp looking though, and looks less realistic. To really compare, I'd have to render the LW scene with full GI and in brute mode, but that would take ages on my system before it resolves into something usable.

Btw, another test:
My question is, how can I get the final result to look more like Cycles? It looks to me as if Lightwave is not working linearly somehow. The colours are too strong, and the shadows too obvious. I also cannot get the lighting right: whatever I try it blows out. I increased the HDR brightness, intensity, distant light, combinations, but it either blows out or is too contrast rich.

I'd like a similar render as Cycles. Any advice is appreciated. I can share the scene.


Is this what you are looking for

http://animatrixproductions.com/Falcon.png

Here it is without being stretched, Also I put the Anti Aliasing up to 16 - This took 48 Seconds to render

139587

Here is a render at 2560x1440 - 1 min 55 Seconds

139588

Thanks,
Jason

Rayek
01-18-2018, 09:31 PM
Excellent! What light setup did you use?

jboudreau
01-18-2018, 09:39 PM
Excellent! What light setup did you use?

Hi I cleared all the lights from the scene and changed the distant light into an environment light. So there is just one light in the scene.
It's intensity is set to 1.28lx Also on my environment light I have Sample Backdrop unchecked.

My GI is using Brute Force (No Interpolation) Intensity is set to 50% and I have sample Backdrop checked on.

Also I think from what I can see form your render you need to change your Color Space to SRGB (Go under quick preset and choose SRGB) Then you have to go into all your images and change them to linear. You can multi select them all and change to linear

Hope this helps.

gar26lw
01-19-2018, 01:16 AM
For the life of me, I couldn't get VPR to assist me at all. It's just too slow, or too undefined, or both. I am unsure what is going on - I suppose the developers could not have VPU gobble up all available CPU time in order to keep Layout responsive. That's the only explanation I can come up with. In the previous versions VPR was actually very helpful - not in this version (yet?).

I had to resort to creating preview renders instead, which slowed down the entire workflow. This is one area where having a dedicated GPU working on that viewport, while the CPU is left to handle the rest, really helps. The thing is, even in CPU mode Blender's preview would resolve much faster, and was helpful in quickly setting up things.

PS Just a random thought. Maxon integrates ProRender in Cinema4D - while I was skeptical of that decision at first, I now understand why: instead of reinventing the wheel and spend a LOT of time and money on developing a new render engine, the developer can focus on providing a first-rate and user-friendly experience in their application. And have all the fruits of a separate dedicated team working on new render engine features.



good points. Yep VPR speed really needs to kick it up a notch. This preview render stuff died a long time ago.

UnCommonGrafx
01-19-2018, 04:31 AM
As an observation, and a rhetorical question, you know that vpr is the render engine? If it's slow, so shall be the render.
That's the trick with the new VPR: it ain't for preview anymore.

If it's not resolving quickly, somethings wonky and is slowing the render. You can demolish/sabotage your render with very few settings; most of those settings, unfortunately, are part of our muscle memory for how to get clean renders from the old engine. This is wreaking havoc on long ago users and our tendencies.

Truly a different way to interact with the renderer: directly. Edit: for example, there is no need for a limited region render anymore because you can move your mouse over an area and it will resolve to render levels as stated by all settings for the scene.

What jboudreau did is the "new" way: clear it and start anew. Watch your render times shrink. Watch beautiful renders come to be.
Chuckle,
Need more coffee.
Robert

rsfd
01-19-2018, 04:32 AM

Am I the only one in thinking that the LW renders look far more crisp? The Cycles render almost looks as if it was a lower resolution scaled up?
Also the reflection of the thin vertical rods in the foreground in the cycles render don't reflect the red light at all. …
The indoor Cycles render differs both in light intensities and direction (directional light from outside), compared to the LW setup.
Why it looks like a Gaussian Blur was applied might be an issue with the Reconstruction Filtering, but I cannot comment on this one.
Also, the reflection of the red light in the mirror ball is „washed out”, one does not get a clear vision of the lamp’s form (this is not „real world / photorealistic”).

The LW scene really has to be prepared for LW’s 2018 Render Engine.
All materials would need to be correctly adapted to the Principled Shader to get the quality that this shader can deliver.
Has anyone ever noticed, that the glass ball reflection in the mirror ball is completely wrong?
Exception’s 2015 render has it right, LW2018 would have it right, if materials would be right.

gar26lw
01-19-2018, 05:20 AM
As an observation, and a rhetorical question, you know that vpr is the render engine? If it's slow, so shall be the render.
That's the trick with the new VPR: it ain't for preview anymore.

If it's not resolving quickly, somethings wonky and is slowing the render. You can demolish/sabotage your render with very few settings; most of those settings, unfortunately, are part of our muscle memory for how to get clean renders from the old engine. This is wreaking havoc on long ago users and our tendencies.

Truly a different way to interact with the renderer: directly. Edit: for example, there is no need for a limited region render anymore because you can move your mouse over an area and it will resolve to render levels as stated by all settings for the scene.

What jboudreau did is the "new" way: clear it and start anew. Watch your render times shrink. Watch beautiful renders come to be.
Chuckle,
Need more coffee.
Robert

well. i’ve set everything to 1 sample and no glossy reflections and it’s still slow, compared to other apps and old lw.
i think the settings are quite easy to figure out, especially if you watch the arnold vid i posted.

to me, it’s the vpr update from initial resolve to about three steps in. that bit is slow.

MichaelT
01-19-2018, 05:58 AM
Thanks for your tests and insights.
I'm not sure where it comes across that I "insist" on using pure MC. I didn't even include it in the original post. I don't think it's a viable option either.

That said, what I hear from the developers is that they think pure MC is a long term replacement for interpolated. Interpolated as it is now is implemented as a secondary choice. Which may explain why it hasn't advanced much from 2015 onwards.
It will be up to us as users to cry out for a more thoroughly implemented 'interpolated' Gi solution. Right now we have the choice of perfect but extremely slow pure MC, and fussy, difficult, and not impressively fast Interpolated mode.

I love your assessment that pure MC is a non-choice. I agree. Let's make this clear to the developers?

Here's a pure MC render (not VPR) after 1 hour and 45 minutes with high settings (10 BFGI rays, AA AS 10-20, caustics and ISBG sampling on). An attempt to make a noise free pure MC render, which failed, obviously.
This may be useful as reference on how the render engine thinks perfection should look like. I do think I had the distant light have a softness angle on this though.


Then a lot of the interpolation stuff needs to be replaced in engine somehow. That noise is going nowhere after all :) Having said that, they do have geometry data + light data. So they already "know" what the scene should look like. I certainly see ways how they could use that to render faster. But we'll see what they come up with.

rsfd
01-19-2018, 07:07 AM

Btw, another test:
My question is, how can I get the final result to look more like Cycles? It looks to me as if Lightwave is not working linearly somehow. The colours are too strong, and the shadows too obvious. I also cannot get the lighting right: whatever I try it blows out. I increased the HDR brightness, intensity, distant light, combinations, but it either blows out or is too contrast rich. …
As Sanchon already posted:
The relation between your 2 light intensities in LW is different to your Cycles/Blender renderings.
The side parts of the Millenium Falcon are too dim, so you would need to brighten your Environment/Backdrop/GI intensity.
And the distant light is far too bright, it blows off any detail on the top (and textures).
That’s also the reason why the hard shadows are too dark. (These aren’t as much brightened by GI as in the Blender version).

As for the textures themselves: to me, the textures in Blender seem „washed out”, what could be a gamma issue, but as I do not know the original files, I cannot comment on this.

p.s.
Camera perspective between LW and Blender is different. And you obviously have rotated the distant light in the eevee render.
jboudreau's variation does not mimic your original setup. But at the end, it's a matter of personal taste.

gar26lw
01-19-2018, 07:48 AM
just gave blender a go with its cpu gpu renderer. wow!

MichaelT
01-19-2018, 11:38 AM
But the new renderer needs some attention regarding caustics. Because that part have always been troublesome in LW (I feel anyway) and much too prone to noise all over the place.

C4D for instance does this much better (1 min 24 sec, with 3d volumetric lighting):

139600

Asticles
01-20-2018, 06:17 AM
I've tested this scene with Appleseed and Luxrender and Lightwave is performing really well.
I would like that the shelves are touching the wall, because now they are creating confusion.

139622

Reagards

BeeVee
01-20-2018, 03:11 PM
This thread is a good pointer: http://forums.newtek.com/showthread.php?155778-Render-speed-We-are-going-about-it-all-wrong

B

jwiede
01-21-2018, 01:13 PM
The LW scene really has to be prepared for LW’s 2018 Render Engine.
All materials would need to be correctly adapted to the Principled Shader to get the quality that this shader can deliver.
Has anyone ever noticed, that the glass ball reflection in the mirror ball is completely wrong?
Exception’s 2015 render has it right, LW2018 would have it right, if materials would be right.

It's one thing to argue that new materials are needed for "best" results, but the "standard" materials shouldn't be yielding completely incorrect visual results. If they are (and they seem to be), that's a serious bug, and removes any value of having them available. If they're not going to function properly, then they shouldn't be present at ALL, and LW should NOT be using them to populate surfaces of older imported scenes. Either they need to be fixed, or removed.

rsfd
01-21-2018, 02:14 PM
@jwiede:
I can follow your argumentation. My personal opinion is, that the "old" materials are still there especially for compatibility reasons and for those who cannot adopt to the new system quickly for whatever reasons.
They still do work (though they need some corrections to be made when used in LW2018).
It may be that Exception rushed out this test scene before converting his 2015 scene correctly to the 2018 version. The new renderer is really different to the previous one (although I have to admit that I paused with LW v.10).
And there is a lot to learn about (as a Modo user, you should know about the changes that were made with PBR in 902).

I think that, with new scenes, one should constantly use the Principled Shader for all materials. And one needs to learn about the new lights system too, as PBR rendering does work differently compared to the "older" render methods.
Besides BeeVee's hint, LW2018 docs do contain a helpful overview about converting scenes from 2015 to 2018: https://docs.lightwave3d.com/display/LW2018/Example+-+Converting+scenes+to+2018


@ all:
Btw. there is one issue with Exceptions test scene, that I couldn't resolve for myself so far:
In the Mirror Ball, we see the reflection of the shelf boards (which have the same Chromium-like material and build up some sort of "light trap" with infinite reflections).
Although the boards on the wall show a {for me ;) } correct shading, the reflection of that area on the Mirror Ball is blocked to black. I've tried with entries of 128 each for Ray Recursion Limit and Reflection Recursion Limit (what -to my understanding- should be the correct values to adjust), LW continuously shows the blocked/blacked reflectivity. Other render examples do not show this issue. (If I find the time, I'll try to bring that scene to Modo902, but atm, it's more important to me to examine LW2018 to my needs as long as my Trial License still allows for saving).

rustythe1
01-21-2018, 02:21 PM
The indoor Cycles render differs both in light intensities and direction (directional light from outside), compared to the LW setup.
Why it looks like a Gaussian Blur was applied might be an issue with the Reconstruction Filtering, but I cannot comment on this one.
Also, the reflection of the red light in the mirror ball is „washed out”, one does not get a clear vision of the lamp’s form (this is not „real world / photorealistic”).

The LW scene really has to be prepared for LW’s 2018 Render Engine.
All materials would need to be correctly adapted to the Principled Shader to get the quality that this shader can deliver.
Has anyone ever noticed, that the glass ball reflection in the mirror ball is completely wrong?
Exception’s 2015 render has it right, LW2018 would have it right, if materials would be right.

actually I'm fairly certain that the 2015 is more incorrect, the reason for the dark reflection is because its absorbing dark light from that end of the room where as from that view the camera is seeing the bright light of the window, by simply changing the angle you can see the glass is the same colour from that angle or even from just behind the ball, so the 2015 version should also be showing a darker image as from the reflection angle to the camera there are 0 light sources behind the glass and essentially refracting a small portion of unlit wall.
139648

rustythe1
01-21-2018, 02:27 PM
and the ball viewed from the reflection to prove the point further
139649

jwiede
01-21-2018, 02:38 PM
Is it just me, or is the clear glass ball next to the mirror ball not showing up in mirror ball reflection? Or maybe not refracting in the reflection (which'd amount to nearly the same thing)? Odd.

rsfd
01-21-2018, 03:48 PM
@rustythe1:
As I do not have LW2015, I cannot load that scene with the original 2015 "look".
I argued from the look of the introduced first images, where the 2015 version obviously uses a pure glass, while the glass in LW2018 is darker.

The reason for that is simply an incorrect Glass material in 2018 compared to the 2015 version.
By re-reading my (cited) text, it may has been misleading (sorry for that). My argumentation should emphasize that the materials for the LW2018 version need to be corrected to get a comparable version to the result of LW2015.

(In the end, -as the materials obviously differ- it's correct in both versions, but in LW2018, the Glass material is not a correct representation of the LW2015 Glass material. In LW2018, the Glass comes as Dielectric with a Transmittance Distance of 100mm and Tr.Color 228-228-228 {Glass Ball has a diameter of ~840mm}. This absorption issue is the main reason for that dark glass and even darker reflection).

The attached screenshot shows what the Mirror Ball would „see”, if *only* the Transmittance Distance would be set to 2m. Camera is placed at the reflection’s origin and does also respect the law of „Angle of Incidence = Angle of Reflection” as good as possible).


@jwiede:
as you can see in the screenshot, the close ball blocks the one further away from being visible in the Mirror Ball. I doubt that the one further away would be visible as "reflection through refraction", as there are so much things going on in this constellation. One could get a quick impression about that by attaching a diffuse material for the ball further away though. Me at least, will not do that in the nearer future :)
p.s.
damn, couldn't hold on. Here you go: I think it's pretty clear, that -under these circumstances- one simply will not see the Glass Ball further away through the closer one in the reflection on the Mirror Ball.