Improved light sampling

[Ondra]

This should address most of the problems with persistent direct light noise:



It will be available in Alpha v6, which will be out shortly.

There will still be scenes where the result won't be as good, I will continue improving the sampler in the future to bring the same improvement to them.

edit: Less synthetic example:


Still not entirely a real problematic scene. I am hoping somebody will try it in daily builds once I do new build

[Ludvik Koutny]

It should mostly help with these kind of scenarios: http://forum.corona-renderer.com/index.php/topic,316.msg18617.html#msg18617

In general, scenarios where CoronaLights are combined with CoronaLightMTL geometry emitters.

[racoonart]

Holy... That looks awesome. So which kind of lightsources will be working better? Only "mesh" lights or all kind of light sources (including portals)?
[Edit] Ok, question is already answered

[Ludvik Koutny]

Portals in Corona aren't really a light sources, they just tell renderer which direction should be sampled more.

Simplified explanation:
It will help in situation where mesh light steal sampling from object lights. In older build, if you made CoronaLight sphere and Sphere primitive with 64 polygons and LightMTL on it, then Sphere was considered to be 64 lights. So then, when lighting was sampled, there was considered to be 65 lights in scene, and CoronaLight sphere had equal importance as the remaining 64 of those polygons.

After this fix, polygons are not separate lights anymore, but grouped by the source objects. So one teapot is just one light, three teapots are three lights, and if you attach these three teapots together, they will be considered one light.

[bilamofo]

If we are gonna express ourselves this way, then this was me against my lcd monitor:



kudos!

[maru]

OH LORD

[Juraj]

Actually, very nice update !

[Tanakov]

Its ... so .. beatiful... I i ... wow.

[Polymax]

really very good news. Thank a lot!

[Stan_But]

sorry for so plagiarism.)) But...

[romullus]

It will be available in Alpha v6, which will be out shortly.

I've registered at forum two months ago, and that statment was one of the first things i've read. Waiting is almost unbearable now :]

Jokes aside, improvements looks impressive, but i'm curious to see how it'll prove itself in really complex scenario.

[Ondra]

I've registered at forum two months ago, and that statment was one of the first things i've read. Waiting is almost unbearable now :]

Sorry, I was sick, and I needed to help friends with another project.

[michaltimko]

I've registered at forum two months ago, and that statment was one of the first things i've read. Waiting is almost unbearable now :]

Sorry, I was sick, and I needed to help friends with another project.

Project : unlocking guns in bf4 :D

[Ondra]

Project : unlocking guns in bf4 :D

Writing a siggraph paper.

I decided not to play BF4 on weekdays until A6 RC1 is out

[Chakib]

[Marciortiz]

Can't wait for Alpha V6 here, from the bits that I could pick here and there I can see a massive update coming.


But I got a question if I may, is there any idea when the commercial version will be released? If we can dr with Corona + those few improvements already mentioned, I am very intend to present Corona as a new option to use at work.

[orsobruno]

we have alredy made the switch to corona, and we don't regret! actually we found the "migrate" option very simple, especially the material part.....the materials editor in corona it's just amazing, and even complex material become easy, when you see the results instantly in the "material ball"!!

and with this update, it will definetly make us desire the A6 more and more :)

Thank you very much Ondra for this software :)

[artmaknev]

Nice update, although I am really looking forward to distributed rendering availability!

[Alessandro]

A quick test with an old scene, 4 passes, lighted just with lights filaments.

[Levian]

even one person can change the world!
thank you for your work!

[Utroll]

I decided not to xxxxxxx on weekdays until A6 RC1 is out

That's the kind of sentence you won't be happy to see quoted when you'll be selling a product :D

Nice improvement, as always.

[Zzaba]

Corona is fantastically renderer! I love it ^)

[magicbox]

Good update are looking forward to

[Cherkes888]

Wow! Mega Cool ) You is a magic man)

[picfad]

Good news! Waiting for new release)

[longhard]

Good news! Waiting for new release  Thank you very much!！

[juang3d]

I decided not to play BF4 on weekdays until A6 RC1 is out

Let me say... I'm going to right now XD

Cheers

[fobus]

Just tested light solvers. As Ondra says we it is good to keep light groups under 250 pcs. In my example we see that with "combined" light solver we can't get noise free lights (in accepted time). But with "Object-based" solver it is possible if we under 250 pcs of light groups. To make this groups we need to collapse object lights into one object (as I understood). But as we see with collapsed lights in building we're have very strange light solution. Looks like some of the lights are not sampled well. So if we have much lights that can't be collapsed (moving for example, or lights in buildings like in my example, or smth else) we can't get benefit from this solver. Hmm... It was one of the main reasons for this feature I think...

[Ludvik Koutny]

Seems like second picture may actually show solution to render the scene in acceptable time. In general, you should cluster together lights that are close together and illuminate same surfaces. So for example try to attach lights that are in same rooms :) And if there is more rooms with lights than what fits in 250 limit, then try to attach a bunch pairs of neighbouring close rooms together in distant background areas :)

[fobus]

Second picture has downside on second frame (attached image). To geet 250 groups I had to collapse all oter lights in buildings. So other buildings looks like attached... In animation it is unacceptable.

[Ludvik Koutny]

Could you count how many separate rooms with lights in them is in the entire scene? And then also how many other (exterior lights is there).

The point is, i would like to know how many light groups would this scene require in total. So amount of separate rooms with lights + amount of exterior lights.

[fobus]

Could you count how many separate rooms with lights in them is in the entire scene? And then also how many other (exterior lights is there).

Three main buildings has ~200 rooms interested to us (other we can't see). There is a ~30 lights on streets. And countless number of rooms in nearby buildings, cars and so on. And it is one of the simplest exterior scenes.

[Ludvik Koutny]

Ok, so my first suggestion would be simply to hide all the lights that are not visible for given shot.

If that is not possible. Then i would place real emitters only in buildings of interest, and attach them by rooms they are into, and for background buildings, i would use self illuminated CoronaMTL instead of lights... :) I am not sure it will perform well, but i would give it a try.

The reason i asked about exact number is that the limit of 250 lights after which light solver is switched can actually be changed, but it comes at some costs, so i first need a good example case to justify asking him to increase the limit.

[fobus]

Hmm... As I understood from Your words light solver switching to combined automaticaly after reaching 250 groups? It's interesting. May be it will be usefull to make choice to increase or decrease this limit?

As for this particular scene I don't think it will be good to use self-illuminated material in rooms of nearby buildings because it may be difficult to light interiors of their rooms to be natural. And of course we can't turn them off because we neeв them in animation all together as our camera moves across the street. But I'll try to do like You said.

Update:
Long scene parsing is huge slowdown for tests ;(

[Ludvik Koutny]

Not to combined, but it will just disable smart sampling of lights. I would try self-illum...  it may be a bit more noisy then real emission, but should not look less natural. As i already said, there is no difference between emission and self illumination aside from fact that self illum is not sampled explicitly, but only randomly by GI. So it will be probably slower, but not nearly as slow as real emitters with too much attaching together or when smart light sampling gets disabled.

[Ondra]

can you upload me the entire scene so I can find out what is causing the long parsing? (if it is the one you uploaded before I already deleted that)

[fobus]

can you upload me the entire scene so I can find out what is causing the long parsing? (if it is the one you uploaded before I already deleted that)

I can only upload "Mandrika" scene. I'll send You a link to PM.

to Rawalanche: it's looks like Your way to solve this scene works. From the first tests it is near to what we need.

[fobus]

Finaly this scene solved :)

Fast render. Great result.
Viva la Corona!

[Ludvik Koutny]

Awesome :)

[arqrenderz]

So, whats the "final" solution for this kind of projects Fobus?

[fobus]

So, whats the "final" solution for this kind of projects Fobus?

place real emitters only in buildings of interest, and attach them by rooms they are into, and for background buildings, i would use self illuminated CoronaMTL instead of lights... :)

[rafpug]

Hello Fobus

Very Good!
...and always compliments to the Staff.

[3dgraphics]

can you fobus explain a bit how u got this project so clean!

[fobus]

can you fobus explain a bit how u got this project so clean!

I just collapsed all the emitters by rooms. And placed in surround buildings self-illuminated lights with no emission. All of the lights are geometry with material applied.

[3dgraphics]

thanks!!!