PDA

View Full Version : Render speed, We are going about it all wrong



rustythe1
01-19-2018, 02:53 PM
Well, i have been busy trying to beat the engine, jakuzaa posted an image in the show us your renders thread that got me thinking,
139603
I think he said it was about 16 mins on a threadripper, i thought whaaat, old lightwave could have done that way quicker so i set about trying to get the same results with a similar scene
so this was the result, fairly close and around 12 mins on my machine, so probably half the time on a threadripper,
139604
but then this got me thinking more, to get this you kind of have to fake the settings and lights beyond real world, but PBR is real world to a sense, so lets make everything real world,
139605
and, render in 45 seconds! yes its a little dark, but its real world, the windows are small and the blinds are down, its supposed to be dark!
so, here is the thing, to make it lighter you just need to make the windows bigger, or add real world artificial lighting etc as if you were dressing a real set for a photograph, then you can get a more realistic representation of what you want, i also found area lights hate having things close to them, this causes much of the noise in the images,
so for this scene i employed a little trickery in that i excluded the blinds from the area lights at the windows and used a spotlight to create the shadows on the walls etc, that way all the light is entering the room with out being sent all other the place early on and causing lots of noise early in the rays life,
i also found, when trying to clean noise in the shiny floor for example your first choice would be to probably pump up the reflection samples or aa, this is not the case though with rough surfaces, this is directly linked to light samples, and cranking those up has far less impact than aa, (if you check your reflection buffer on a scene like this it will most likely just be black)
also keeping all the lights at %100 equivalent or less is a must, to change the brightness of say the sun or window light, just move it further away rather than change its value this helps reduce things like fireflies as nothing is going into realms it wouldn't in the real world,
the upshot is a fairly decent render, fast, and more represents what you would actually see with the eye,
139606
this rendered in less than 2 mins on my almost 5 year old i7,
at 4k it came in at just under 5 mins
139607
with these sort of times, you can afford to pump up aa settings and light samples even further for final images, (remember, samples before aa for noise), no noise filtering used either, so i think single machine animations are back on the cards for now (for a time i was worried i would be stuck in 2015 for quite some time that a single processor became equal to a small farm!)

also here is the scene i made so you can all take a look and maybe it will help some people out
139608

UnCommonGrafx
01-19-2018, 03:39 PM
Just one thing as I read and impulsively respond: for a brighter image, ctrl-p the render tab and up your global light intensity. As I watched the video shared on Arnold, I have come to realize that is our "exposure" value, of sorts.

Asticles
01-19-2018, 03:56 PM
Yes, but doesn't touch environment exposure...
You must have an environment light and important, set visible to camera enabled.

gerry_g
01-19-2018, 04:01 PM
yes I was trying to render a room and couldn't get enough light, taking the global exposure setting above one hundred percent was more effective than cranking up the lights themselves

rustythe1
01-19-2018, 05:07 PM
yes, exposure in the render was my other conclusion (even if its done in post), but again, that's needing to adjust things beyond real world, if its too dark in a room, you turn a light on, simple, and that's the problem here, we are all trying to do things in an artistic way, which with the old engine was easy, but now because the engine is more true the reality, its harder to (or rather there is a trade off of time) to do it artistically, the more people try to trick and cheat the system thinking it will save time, the more time is wasted and taken,

samurai_x
01-20-2018, 06:31 AM
Well, i have been busy trying to beat the engine, jakuzaa posted an image in the show us your renders thread that got me thinking,
139603
but then this got me thinking more, to get this you kind of have to fake the settings and lights beyond real world, but PBR is real world to a sense, so lets make everything real world,
139605
and, render in 45 seconds! yes its a little dark, but its real world, the windows are small and the blinds are down, its supposed to be dark!
so, here is the thing, to make it lighter you just need to make the windows bigger, or add real world artificial lighting etc as if you were dressing a real set for a photograph, then you can get a more realistic representation of what you wan

Newtek kind of made a mistake with this name pbr render engine. Even the old lw 2015 was a physically based renderer. Even other old render engines are physically based.
We just didn't have a few direct plugs that are used in other appz to utilize the metallic, specular etc workflow.
You don't need to fake settings, that's what tone mapping is for. If you used vray or kray way back, tonemapping was important to get good, well lit, balanced images.
Just like real cameras or even phone cameras now, the longer the sensor captures the scene, the brighter and clearer it becomes.

Nicolas Jordan
01-20-2018, 03:26 PM
We shouldn't need to try and think up some trickery to try and out smart the render engine to get fast render times that are on par with 2015. The darker image almost looks like images that were rendered back before the days of GI. I'm just not going to be using the new render engine until it becomes faster. Hopefully it will continue to be improved and developed further so users don't need use Threadripper just to get decent render times.

JamesCurtis
01-20-2018, 04:21 PM
Just so you know, I rendered the supplied scene as is and it rendered in 3min 36sec on my i7 5820 6 core processor.

gar26lw
01-20-2018, 05:13 PM
yes, exposure in the render was my other conclusion (even if its done in post), but again, that's needing to adjust things beyond real world, if its too dark in a room, you turn a light on, simple, and that's the problem here, we are all trying to do things in an artistic way, which with the old engine was easy, but now because the engine is more true the reality, its harder to (or rather there is a trade off of time) to do it artistically, the more people try to trick and cheat the system thinking it will save time, the more time is wasted and taken,

why is it that it is assumed everyone is doing or wants realistic arch viz renders?

not everyone uses lightwave for that. personally i’d rather have a flexible, easily customisable/controllable and fast renderer instead of one that’s slow and real world. i want to be able to make artistic choices and create different looks.

Nicolas Jordan
01-20-2018, 05:30 PM
why is it that it is assumed everyone is doing or wants realistic arch viz renders?

not everyone uses lightwave for that. personally i’d rather have a flexible, easily customisable/controllable and fast renderer instead of one that’s slow and real world. i want to be able to make artistic choices and create different looks.

I agree, I have a few demanding/picky clients that will insist something looks wrong in a rendering even though it is physically correct/accurate so I usually have to make changes to match what they expect to see and not what they would see in reality. It is nice to have the choice and flexibility to create renderings that are physically accurate while also still being able to make changes that might not adhere to those rules. I think they are trying to accomplish this with LW 2018 by still supporting standard surfaces. Just not sure why everything takes longer to render no matter what.

samurai_x
01-20-2018, 05:37 PM
why is it that it is assumed everyone is doing or wants realistic arch viz renders?

not everyone uses lightwave for that. personally iíd rather have a flexible, easily customisable/controllable and fast renderer instead of one thatís slow and real world. i want to be able to make artistic choices and create different looks.

Pathtracers are harder to make stylized compared to general purpose, biased renderers.
It can still look bad depending on who's using the renderer though. Having pathtracing in lightwave 2018 doesn't mean everything looks good.

prometheus
01-20-2018, 06:41 PM
I agree, I have a few demanding/picky clients that will insist something looks wrong in a rendering even though it is physically correct/accurate so I usually have to make changes to match what they expect to see and not what they would see in reality. It is nice to have the choice and flexibility to create renderings that are physically accurate while also still being able to make changes that might not adhere to those rules. I think they are trying to accomplish this with LW 2018 by still supporting standard surfaces. Just not sure why everything takes longer to render no matter what.

just thinking, all the node appliance of materials, and even entering nodes for displacement, nodes for hypervoxels...the node rout seem to always have requried vpr taking longer to render or update displacements often, but that may not be it.
Standard materials is now passing through the node system, unlike standard materials from the past.

wingzeta
01-20-2018, 09:11 PM
It is hard to make some of these accusations about the new render engine, when you don't really know how to use it yet. It is quite different. I'm struggling with it too, and wouldn't use it for a paid project, until I know what I'm doing. It has been stated numerous times, that you can't just open a 2015 scene in it and hit F9 (not accusing anyone of this). I'm sure we all know there is some work involved by now.

What I wish they had done, was create some presets "Indoor Render Fast, Indoor Render Medium, HQ, Outdoor Render Fast, etc..." The problem with that seems to be that you wouldn't want the presets to highjack your light sample control, which are per light, and if a preset doesn't account for the light samples, it can't really work for varied situations, so it still wouldn't give a good result. So I see why they didn't do presets. What they can do is put the relevant controls in one place. I would like the camera samples to be in the render panel like it was in the Arnold video. The difficulty there, is that you may have 10 cameras in your scene, that each have different optimum sample settings. A camera inside a building vs. outside. That is why I liked it when they put the camera tab in the render panel in the past. I think they should at least put the camera tab back in the render tab, and the light tab too, but it would be nice to be able to undock the tabs. In 2018 these settings you need to fine tune your render are all over the place.

Let's face it, one of the strengths of LW was always being able to hit F9 without much tweaking and get a result. The GI check box was like a "make it look good" button. It is hard to jump into 2018, and have it work in a very different way, but that doesn't mean it doesn't work. Ultimately it will be a step forward, with getting realistic materials, and I think the artistic control is there to be figured out, it is just scattered among a bunch of controls. I hope they consolidate these controls, and maybe rework the default settings if that would give people a better starting point.

Some sort of gang synchronization switch would be cool if they had the relevant settings laid out like in Arnold. You click the switch, and then as you adjust camera samples it automatically lowers other numbers to maintain relative values. Just an idea.

In other words it would be beneficial to maybe create another layer of control for render settings. Imagine a New "Render Overview" control panel that does have all the relevant controls in one tab. Camera and light samples with dropdowns to choose which camera or light, GI, Exposure, reflection, refrac, sss, etc. And when you change the value, it adjusts it in the other panels as well. Just a place to get everything at your finger tips, but without losing any control. It would be easier for people to share set ups too, and presets might look more feasible. Sorry for rambling.

Nicolas Jordan
01-21-2018, 09:30 AM
It is hard to make some of these accusations about the new render engine, when you don't really know how to use it yet. It is quite different. I'm struggling with it too, and wouldn't use it for a paid project, until I know what I'm doing. It has been stated numerous times, that you can't just open a 2015 scene in it and hit F9 (not accusing anyone of this). I'm sure we all know there is some work involved by now.



The thing is if you knew how to set the settings and use 2015 then 2018 isn't any different except for a few minor things because it has all the same controls. If users keep thinking there is something they are missing and that they just need to get a better handle on the new render engine then you will be thinking this for a long time. As users all we have to control the render engine is the GUI for it. It's obvious the way it renders out scenes has changes but the GUI really hasn't much. My conclusion is that it's a different render engine with the same GUI controls. This render engine just has longer render times in every scene I have tested and that varies a bit from scene to scene. I'm starting to see ridiculous ideas like sacrificing AA quality and turning off GI just to get more acceptable render times. Truth is if you knew how to use 2015 then you know how to use 2018, it just takes longer.

RebelHill
01-21-2018, 09:57 AM
The thing is if you knew how to set the settings and use 2015 then 2018 isn't any different except for a few minor things because it has all the same controls. If users keep thinking there is something they are missing and that they just need to get a better handle on the new render engine then you will be thinking this for a long time... It's obvious the way it renders out scenes has changes but the GUI really hasn't much. My conclusion is that it's a different render engine with the same GUI controls... Truth is if you knew how to use 2015 then you know how to use 2018

This is one of the BIGGEST issues with making the transition from pre18>18... The UI and controls are, for the most part, very much the same, but their operation certainly is NOT. On the one hand it's nice that there's this "continuity" in the UI, because it makes the whole thing familiar to existing users, but that familiarity is also a curse on the other, because it tricks you in to thinking that you can apply the same settings in the same ways, and that what was an optimal set of values/switches for a given scene/rendertime in previous version will also be optimal in 2018... it's simply NOT true, however.


This render engine just has longer render times in every scene I have tested...

And this is purely because of what I've just said above... because you think the given settings are directly comparable, when they're not. It also misses the fact that there are some new tools, and thus workflows, available in 2018 that weren't present in previous versions, so "optimal" is a balance (just as it was before ofc) of both the right settings in the panels, and the best choices in overall scene setup (principally lighting but also a bit with materials).

I've been using this new renderer for 2 years now, and I've yet to find a scene in 2015 that cannot be rendered either faster, to the same quality, or in the same time to better.

Nicolas Jordan
01-21-2018, 10:26 AM
This is one of the BIGGEST issues with making the transition from pre18>18... The UI and controls are, for the most part, very much the same, but their operation certainly is NOT. On the one hand it's nice that there's this "continuity" in the UI, because it makes the whole thing familiar to existing users, but that familiarity is also a curse on the other, because it tricks you in to thinking that you can apply the same settings in the same ways, and that what was an optimal set of values/switches for a given scene/rendertime in previous version will also be optimal in 2018... it's simply NOT true, however.



Are you saying that GI setting like primary and secondary ray setting do something different in 2018? Do min and max pixel spacing do something different than what they say they do? Do AA settings like Min/Max samples do something different now? Does Adaptive Sampling threshold and radius do something other than what the setting says now? If these don't do the same thing they did before that should be indicated why and explained to users. From what I have seen all these settings and more do what they did before. Maybe the math behind the programming solutions has changed here and there but that's not something user can control.



I've been using this new renderer for 2 years now, and I've yet to find a scene in 2015 that cannot be rendered either faster, to the same quality, or in the same time to better.



Is there a secret recipe to this? What kind of scenes are you rendering that you are getting these kind of results?

jwiede
01-21-2018, 10:53 AM
This is one of the BIGGEST issues with making the transition from pre18>18... The UI and controls are, for the most part, very much the same, but their operation certainly is NOT. On the one hand it's nice that there's this "continuity" in the UI, because it makes the whole thing familiar to existing users, but that familiarity is also a curse on the other, because it tricks you in to thinking that you can apply the same settings in the same ways, and that what was an optimal set of values/switches for a given scene/rendertime in previous version will also be optimal in 2018... it's simply NOT true, however.

Newtek creating a false "familiarity" with the UI offers no useful benefits whatsoever, as we're seeing in the most excruciating manner. Creating conditions where users are more likely to make mistakes than choose correct settings is explicitly poor UI/UX design. Separating fields of tightly-coupled parameters so that one can be preset-controlled while the other requires manual adjustment is also explicitly poor UI/UX design. When new engine parameters are given the same labels and similar descriptions as old engine parameters, blaming users for thinking they're similar is directing blame at the wrong people.

All you're really saying is that Newtek/LW3DG did a poor job with the UI/UX for the new render engine, then incorrectly blaming users for it.

RebelHill
01-21-2018, 11:20 AM
Are you saying that GI setting like primary and secondary ray setting do something different in 2018?.. ...Maybe the math behind the programming solutions has changed here and there but that's not something user can control.

Do they do/mean something different..? At the "surface" level, no, not so much... but the thing you're missing is the fact that these settings are the variable inputs TO the math behind the scenes, and since that has changed in many regards, then those input values/mix-of-values that were "optimal" for a given scene in the previous renderer wont necessarily be (and almost always aren't) in the new.


Is there a secret recipe to this? What kind of scenes are you rendering that you are getting these kind of results?

Not really secret... http://forums.newtek.com/showthread.php?155474-LW-2018-Comments-Opinions&p=1532266&viewfull=1#post1532266 additional details are also in the manual, and if you experiment with the different options available, you'll start to get an intuition as to how best to combine them (which pretty much boils down to what I describe in the linked comment).


All you're really saying is that Newtek/LW3DG did a poor job with the UI/UX for the new render engine, then incorrectly blaming users for it.

No... what I'm saying is there's a damned if you do, damned if you dont tradeoff to be made. Either go around changing all of the UI level stuff into something totally unfamiliar, and your complaint (and that of others) would then be how the divergence from the old familiarity created a steeper learning curve. Keep the same "appearance", and the complaint is that it's "obfuscating" best practices for usage by creating "false beliefs" about what will work best based on past experiences. At least by keeping the familiarity, you enable users to get "something" straight out the gate, even if that's not the most efficient solution

No one is BLAMING users for not having it sussed out from day dot... but given the position that the changes will create some kind of barrier no matter which way you do it, all anyone can do is to point out that things have changed, complaining about it wont help, learning new things will.

RebelHill
01-21-2018, 12:35 PM
New plan, Nic...

Get a scene you can render well in 2015, but not in 2018 (please something "normal-ish", as in not with obscure plugs that may/may not work the same... huge lighting/shading complexities giving several hour rendertimes, etc, that'd take me hours to makeover)... post the 2015 version, and Ill convert/make it go in 2018.

jwiede
01-21-2018, 12:45 PM
No... what I'm saying is there's a damned if you do, damned if you dont tradeoff to be made. Either go around changing all of the UI level stuff into something totally unfamiliar, and your complaint (and that of others) would then be how the divergence from the old familiarity created a steeper learning curve. Keep the same "appearance", and the complaint is that it's "obfuscating" best practices for usage by creating "false beliefs" about what will work best based on past experiences. At least by keeping the familiarity, you enable users to get "something" straight out the gate, even if that's not the most efficient solution


But the learning curve IS steeper, regardless. The false "familiarity" doesn't really help users get usable (performant, quality) results, as we're all seeing. That it helps them get "something" isn't really a practical benefit, because that "something" still won't get them to the performant, quality end result they're seeking -- in order to do that, they must climb the learning curve, and the need to overcome that false familiarity serves to make the curve steeper, not shallower.

And again, the UI/UX issues go beyond just the false similarity: Render presets don't even capture all engine-relevant settings, because sample numbers, filter radius, and other key aspects have been moved back to camera and light settings (which aren't captured in "render presets"). By splitting those parameters up, there's no direct means of adjusting all render-relevant values (f.e. to provide a quick preview in VPR, or to manage different output resolutions). Doing so negates much of the value of such presets, because users still have to know a priori which other settings need adjustment "outside" the preset, and which way to adjust them.


No one is BLAMING users for not having it sussed out from day dot... but given the position that the changes will create some kind of barrier no matter which way you do it, all anyone can do is to point out that things have changed, complaining about it wont help, learning new things will.

Had the devs actually tried to construct a decent set of useful "starter" render presets as part of the LW2018 deliverable, they would have immediately realized the way they had split up many of the render settings makes constructing useful render presets problematic. Based on how quickly the issues became obvious after release, it's rather clear that had there been an Open Beta, they would have noticed most prior LW users were approaching the render settings incorrectly during that Open Beta (on top of many other obvious issues).

Both of those are actions they really should have taken as part of proper SW QA regardless, so the whole "damned if they did, damned if they didn't" trope doesn't even apply. If anything, this just further highlights additional harms stemming from their inadequate SW QA process.

RebelHill
01-21-2018, 12:57 PM
The steepness of the learning curve given one option or the other is a bit of a generalisation... some users may well find the "familiar but misleadingly so" controls feel like the bumpier option, others would also find the other way to be true. I'm pretty, totally, utterly confident that had they gone the other way, and totally overhauled the way you manage/optimise the renderer, that you would be in this very thread complaining about how great a learning curve that left users to overcome.

Things have chaged, there's a learning curve that IS going to be inherent in that no matter what. You can either keep moaning, learn, or stick with 2015 and what you already know how to do.

As for presets... that's no fix either, since what's optimal for a given scene is VERY dependent on the particulars of that scene... which materials are present? Visible in reflections of which other materials? With those reflections blurred how much? Oh and was that an area light you're using, or a distant? Etc, etc. Again, I'm pretty, totally, utterly confident that you'd be here saying how "Such and such a preset looks crappy on scene Y, takes ages to render on scene X", and so on.

rustythe1
01-21-2018, 01:53 PM
New plan, Nic...

Get a scene you can render well in 2015, but not in 2018 (please something "normal-ish", as in not with obscure plugs that may/may not work the same... huge lighting/shading complexities giving several hour rendertimes, etc, that'd take me hours to makeover)... post the 2015 version, and Ill convert/make it go in 2018.

Thank you for this and please take him up on it nic as i really want to see the results too, i think everything you have been saying in the many threads were exactly the first conclusions i was coming too, and mostly the reason for this thread, i think some people missed the point i was trying to make, probably isn't that clear as i was simplifying it with this scene, but as you say each scene is different, there can be no presets (hence my initial comment about the rough floor, you need to change light samples to clean it up, but if you just had plain walls and carpet you could drop your light samples from 16 to something like 2 or 4)
also if you watch the video gar26lw mentioned it goes a long way on explaining how changing a setting further down the chain of things can affect settings you have above that, so you can then go and lower those settings as,

zapper1998
01-21-2018, 03:45 PM
Loaded yur scene I7-980 HT 12 core, rendered in 4min 4sec

Nicolas Jordan
01-21-2018, 03:58 PM
New plan, Nic...

Get a scene you can render well in 2015, but not in 2018 (please something "normal-ish", as in not with obscure plugs that may/may not work the same... huge lighting/shading complexities giving several hour rendertimes, etc, that'd take me hours to makeover)... post the 2015 version, and Ill convert/make it go in 2018.

I will see what I can come up with. Most of my production scenes are fairly heavy with lots of purchased meshes that are licensed that I don't think I can post publicly. I will see if I can find something that I can strip down because I would like to post it here if I can.

Kryslin
01-21-2018, 08:53 PM
New plan, Nic...

Get a scene you can render well in 2015, but not in 2018 (please something "normal-ish", as in not with obscure plugs that may/may not work the same... huge lighting/shading complexities giving several hour rendertimes, etc, that'd take me hours to makeover)... post the 2015 version, and Ill convert/make it go in 2018.

I think the one exception to this is anything with FiberFX. While I'm getting decent render times, they are nothing near the volume render times I was getting with FFX (4m and change). However, the quality is world's better.\, so I'll take that trade-off.

Something I've noticed, is that sometimes using a smaller render tile is not faster. I ran a test using each size tile on a 800 x 600 render, with Heavy FFX (5 layers) use. At 8x8, it took 15m and change. At 1024 x 1024, it took 9m30s. About 6 minutes difference.

vipvip242
01-22-2018, 06:16 AM
I've launch your scene 'as is' (F9 render) on i9 7940X (14cores/28 thread @ 4Ghz on all cores, 64BG DDR4 3200 Ram ) : 61,1 seconds on lightwave 2018.01, win10 64

Ernest
01-22-2018, 06:42 AM
The steepness of the learning curve given one option or the other is a bit of a generalisation... some users may well find the "familiar but misleadingly so" controls feel like the bumpier option, others would also find the other way to be true. I'm pretty, totally, utterly confident that had they gone the other way, and totally overhauled the way you manage/optimise the renderer, that you would be in this very thread complaining about how great a learning curve that left users to overcome.

And you would be pretty totally utterly right but I still think jwiede is (more) right, in this case (how weird is that!).

We would all definitely be complaining if they had changed the interface to something different because we would want to be productive with the knowledge we've already accumulated. That's the reason why we would be complaining. Because with a different interface, our accumulated knowledge would no longer translate into productivity using the tool. That's the only reason. We don't want a similar interface for an aesthetic sense of comfort, but for immediate productivity. And the thing with this similar interface that works differently is that the accumulated knowledge not only does not translate into any added productivity but it actually does translate into counter-productivity! Our accumulated knowledge on render optimization actually un-optimizes renders. That's why it's objectively a worse choice.

It's like if there's a soccer club and this group of old timers has been coming for years to play soccer there and have gotten really good at it. But the owner of the club realizes that soccer is dying and that bowling is the sport of the future. But the guys coming to his club are so used to playing soccer and are so familiar with it that turning the soccer field into a bowling alley would make them all cry and complain.
So, to avoid any harsh transitions, the owner gets a bowling ball, paints it to look just like a soccer ball and places it in the soccer field. That should make for an easy transition!

gar26lw
01-22-2018, 07:04 AM
some lw users the other day ..

https://n-cdn.serienjunkies.de/59480.jpg

RebelHill
01-22-2018, 08:02 AM
That's why it's objectively a worse choice.

Not objective at all, it's still subjective. Ofc that allows each to have their own view on which would have bee the more/least agreeable way for them, and if you polled every single user there may even emerge a consensus more on one side than the other. Still doesnt make it objectively true.

Tbh, to a certain extent, it's kind of a pointless argument anyway, because the interface for such things has changed somewhat... settings popped in different places, samples per light rather than universal, etc. But at the end of the day, these are the settings, the input numbers that ARE needed to tell the renderer what to do, and there's only so much you could do to re-arrange all that. So it almost makes no difference how radically the interface were to be changed, people would still carry their pre-existing intuitions with them and face the same difficulties in unlearning the past ways.

End of the day, the renderer has changed, completely, totally... it's not been upgraded or tweaked. The old one has gone in the trash, and the new is (pretty much I imagine some basic functional calculations aside) a total, ground-up rewrite.

That brings a learning curve, no matter what you do with the UI, adn the fact that this change has occurred has been no secret.


But the guys coming to his club are so used to playing soccer and are so familiar with it that turning the soccer field into a bowling alley would make them all cry and complain.

Right... maybe they dont like the change, maybe they'll go to some other club... but if it is clearly sign posted to them... "Hey, this is a bowling alley now", and they STILL try to kick the ball..?

01-22-2018, 08:14 AM
Yes... Lots of attempted ball kicking....

samurai_x
01-22-2018, 08:25 AM
Pick any of the free interior scenes at evermotion or even the kray forum.

Rayek
01-22-2018, 06:58 PM
I don't really understand this thread? I tested the scene the OP posted, and I noticed GI is completely turned off. Looking at the sample renders obviously render times will be fast, since GI is missing. The quality of the renders is pretty bad, and unsuitable for client work, in my opinion. Real-time OpenGL render engines look a hundred times better with simulated GI, and render in real-time (note to self: I should do an Eevee conversion of the scene).

In this case I would expect full-on quality as a client. Otherwise I can switch to Unreal Engine and do my work there. Sorry to be a bit harsh, but what is the point of deactivating GI?

I have been testing more this past weekend. Other things of concern to me are:
- the anti-aliasing. The default settings are WAY too harsh in my opinion, and edges with bright areas look horrific with the default settings.

- the overall colour management workflow. In Cycles I turn on Filmic for wide range f-stops, choose a standard preset for overall exposure, and I can easily test for blown-outs by switching to false colour, which indicates blown-out areas with red.
Not so simple in Lightwave. And it is still not possible to do any tone mapping while rendering in LW2018 - I would've hoped they'd adopt a more current approach in this regard.

Here is a quick conversion to Cycles. It took 57 minutes to render, and I went with full quality, brute force path tracing. Including caustics and caustic reflections. Just one sun light, no emitters used like in the LW version. Render samples set to 3000.

http://i63.tinypic.com/303eauh.png

Some may say this sounds slow. Well, a path tracer *IS* slower to render. Period. That said, from my experiments so far I got the feeling Lightwave's path tracer is actually quite fast.

As for the missing presets debate. In other path tracers I use(d) various presets that are available to the user for good initial results. If you feel the need to tinker around, no issues either. Not having access to a couple of sane presets in LW 2018 makes life unnecessarily harder for the average user. And having the settings spread out over the GUI in Lightwave isn't helpful either. And I don't really understand either why Newtek didn't have someone record a bunch of videos explaining the overall workflow and settings in different situations (exterior, interior, space, product rendering, etc.).

There are some other issues I am encountering, but the (default) anti-aliasing (the overly sharp CG look), the colour management and lighting workflow, the overall user experience (GUI) and the lack of GPU support are the ones most frustrating.

Here is a render with full GI (1 hour and 11 minutes) in Lightwave. The secret to reducing the blowouts: use the Image Controls in the image editor (duh! Should've thought of that earlier!) I set the white point to 2.5, and the black point to 90% - which results in a far nicer lighting. I just wish we could do this while rendering takes place.

http://i64.tinypic.com/fz66pg.png

I changed the anti-aliasing to a threshold of 0.094, and more samples, and at least the overall anti-aliasing looks much nicer now. New problems are fireflies and noise.The de-noise method takes place after rendering, and is not an optimized @render time method, it seems. It won't take care of fireflies either.

I attempted to use the noise reduction in LW, but it didn't really help that much. The default noise settings kills details, and reducing noise in the relevant buffers results in splotchy walls. In Cycles it's a simple checkbox: click, and it works, with smart settings. Also gets rid of fireflies, btw. The noise reduction in LW seems a bit like an afterthought to me. Definitely room for improvement. Cycles applies it during render time, and seems to use a very different approach which effectively kills render time by half for decent final results.

Mipmapping is turned off by default in Lightwave. That I do not understand. Shouldn't it be on by default for better results? Did for me.

I prefer the Cycles render by a hundred miles. Of course, different beasts, different lighting. Still, Cycles does a better job - which makes sense, since it is a more mature product.

On a side note, it's a bit awkward to have the rendering completely lock out the user. I had hoped they would have changed this in 2018 - or to at least be able to change exposure and adjust tone mapping while the render is taking place. Other render engines allow for this, and it is very useful. Having to wait for the render to finish is VERY counter-productive indeed.


The trouble is that Lightwave cannot utilize your GPU(s), though. That's a crying shame, and limits the new LW render engine's flexibility thoroughly. If I want to cut my Cycles, ProRender or Octane render time in (almost) half, I run to the nearest computer hardware store, purchase a 1080, and install it. Done. GPU rendering isn't nearly always the answer, and I am aware of this - but at least there ought to be the option. The lack of GPU as a render option is limiting to small studios and (pro)sumers in particular.

At this point I am beginning to understand Maxon's C4d developers: instead of re-inventing the wheel, instead implement an existing modern path tracer that supports OpenCL rendering out of the box (ProRender). And that is developed by a different team, so it allows the C4D developers to focus on a tight integration with a good UX experience. High level GPU render engine programmers are very difficult to find, and harder to keep. Which makes Newtek's decision to forego GPU rendering understandable, but it puts their new render engine at a disadvantage from the start.

And with many path tracers now already or soon supporting simultaneous GPU+CPU rendering, and real-time OpenGL render engines already outpacing the GI quality of traditional non-path tracing rendering and closing in on path tracers for animation, I feel that Lightwave's new renderer sits between a rock and a hard place.

@rustythe1: your sig indicates your rig has 3x 4gb GTX970 installed. Don't you feel like it's a waste of your hardware when you are rendering in 2018?

The situation with LW's new render engine is similar to, I feel, as when Cycles was first introduced in Blender, and ProRender in Cinema4d. I think it would have been prudent to keep the old render engine, and offer a choice, just as the other 3d apps did/do, as well as a quick method to convert materials quickly between the two.

If the old LW render engine was still available alongside the new path tracer more options would have been open to the user too. More flexibility again.

All this may sound a bit negative, but I actually see a lot of potential. It just needs more polishing, better default settings, presets, better learning support from Newtek. A good @render time denoiser. And GPU options (which will probably never come to pass).

JamesCurtis
01-23-2018, 08:30 PM
I agree with your points, especially the one of retaining the old rendering system for a choice by the user. That way, we wouldn't need to keep two versions of LW installed.

prometheus
01-24-2018, 01:24 AM
I agree with your points, especially the one of retaining the old rendering system for a choice by the user. That way, we wouldn't need to keep two versions of LW installed.

I would still need two versions, the old one..32 bit, too many model plugins not available in 64 bit that I use.

gar26lw
01-24-2018, 02:32 AM
I would still need two versions, the old one..32 bit, too many model plugins not available in 64 bit that I use.

Same. Wish x32 for modeller at least

gar26lw
01-24-2018, 07:40 AM
looks like the way to render speed is threadripper


https://youtu.be/CYfA1prozsE

i have to say, i prefer the renderman style of update

Nicolas Jordan
01-24-2018, 10:49 AM
I just posted a new thread with a production scene that takes about twice as long to render in 2018 as it does in 2015. Here is a link to the thread if anyone is interested http://forums.newtek.com/showthread.php?155830-LW-2015-vs-LW-2018-Arch-Viz-render-testing&p=1534782#post1534782