Raytraced Indirect Lighting For Blender Render Available Now, Please Test!

[sgraham]

@abc123

this is cool, is it works with baking?

It should work the same when baking.

[sgraham]

@VickyM72

This should have been done a long time ago in my opinion, nice work! I’d like to see this working with a real interior like this one which was done in BI with only Direct Lighting:

[ATTACH=CONFIG]263974[/ATTACH]

Do you have the blend file for this scene, or know the author? Have them test the build! You would probably get a bit more light in certain areas, like under the cloth near the bottom of the chair. My guess is it would be pretty subtle differences. I’d love to see it though as it is already pretty distributed looking light. The carpet would probably grab some of the color of the cabinet.

[VickyM72]

@sgraham

Ahh man, don’t make me review my algebra and merging powers of… you know squared is x[SUP]2 [/SUP]right? and squaring x is also x*x right?

so it is number of samples to the power of 2bounce
or shortest form would be: samples[SUP]2bounce
[/SUP]which is also the equivelent of: samples^(2bounce)
if you like that notation better…

this is the current behavior of BI samples, so if you have no bounces, say with plane ol’ occlusion, that is the same as 1 bounce, or simply samples squared. but with each bounce, you get a whole new set of samples squared to evaluate the bounced sample properly.

HUH?!! Just kidding…

It’s from a “BI vs. Cycles vs. YafaRay” observation found here: http://blendernews.org/xe/?mid=Feature_Articles&document_srl=1274

Yes, I think the scene could definitely benefit from what you are doing here

[sgraham]

@Harvester

I really appreciate you attempt to “revamp” the Blender Render which I personally still like to use. Thank you.

You’re welcome! Thanks for the positive feedback.

[VickyM72]

I also want to thank you for this, I use BI all the time myself. Obviously from the picture I posted above it has more uses than “cartoony renders”, which a boatload of people think is all it can do

[sgraham]

@VickyM72

HUH?!! Just kidding…

It’s from a “BI vs. Cycles vs. YafaRay” observation found here: http://blendernews.org/xe/?mid=Feature_Articles&document_srl=1274

Yes, I think the scene could definitely benefit from what you are doing here

haha nice. I would imagine it would come out a lot like you see in yafaRay and Cycles, but probably take a lot longer to render Too bad there’s no blend file there I’d be happy to render it.

@VickyM72

I also want to thank you for this

You’re welcome!

[Therahedwig]

@sgraham"

I am considering changing that for myself, I’m not sure if the foundation wants to change the default behavior in Trunk though. Or like I said in a previous post, I could put a checkbox so the default behavior is the same, but it can be disabled.

As for playing nice with that patch the answer is, yes it should because I am running through the same code for sampling indirect lighting that the BI would normally run through to color a pixel.

I will say though that this patch is kind of a hack I personally would not want in Trunk. I would much rather have a real “size” value on the light so that a point light would act as a sphere area light. It looks like this is partially implemented but only works on raycast shadows. I took a look at the code for this patch, and it is essentially removing a clamp on the diffuse calculation (light dot normal), which allows for light to wrap around the surface (as it should not unless the size of the light is bigger) and then linearly interpolates (mixes) between half the softness amount (why half?? arbitrary?) and 1.0 (full brightness) with an alpha of the un-clamped diffuse. In other words there is nothing physically correct about it, which is my personal beef. But I know some people aren’t worried about that. I believe I tried the same thing back in the day when I was learning to code shaders using RenderMan, it was cool in theory, but then using it in production you can get very strange/undesired results, especially with objects interacting with other objects you get bright spots where shadow should be. No offense to the author.

It should be noted that this patch was constructed in the BEER thread, which was a thread to examine options for NPR rendering in BI. Specifically it was made for Valve’s ‘half-lambert’ shading model. The advantages were that it renders quickly and noiselessly while giving a sense of indirect lighting. The other solution was eventually the dynamic shading primitives.

Anyway, this is pretty cool. I like seeing development in BI.

[sgraham]

@Therahedwig

It should be noted that this patch was constructed in the BEER thread, which was a thread to examine options for NPR rendering in BI.

That makes sense. And in fact I would not mind it being a part of the options as long as it was clearly labeled for what it is, “fake lightwrap” or some such name. Or at least be placed in a section for non-physical settings.

[lsscpp]

@sgraham

Ahh man, don’t make me review my algebra and merging powers of… you know squared is x[SUP]2 [/SUP]right? and squaring x is also x*x right?

so it is number of samples to the power of 2bounce
or shortest form would be: samples[SUP]2bounce
[/SUP]which is also the equivelent of: samples^(2bounce)
if you like that notation better…

this is the current behavior of BI samples, so if you have no bounces, say with plane ol’ occlusion, that is the same as 1 bounce, or simply samples squared. but with each bounce, you get a whole new set of samples squared to evaluate the bounced sample properly.

Thanks for clarification

[sgraham]

I’m noticing that there are remnants of having a bake lightmap (RE_BAKE_LIGHT) option for bake_type. Do any of the Blender Veterans know why that was discontinued, removed or never finished? In fact it is defined as ‘0’ as in the first bake mode that was defined.

[sgraham]

I can confirm, Indirect Lighting is there when I bake in FULL RENDER mode. Now trying to get ENV, INDIRECT, and LIGHT modes working (where LIGHT is everything except texures and just needs to be multiplied)

[lsscpp]

sorry double post

[lsscpp]

I made some tests.
Using more than 2 bounces gives a little more light in the scene, but definitely pumps render times too far. I compensate this introducing ambient occlusion at 0.01 in Additive mode.
The result looks really good, the only problem is that the test took 1:05 minutes while Cycles took about 6 seconds!!!

here are the tests:

A

B

and this is the modified blend with Cycles setup:
http://www.pasteall.org/blend/24541
be aware that for some reason lamp size in Cycles has to be half of BI lamp soft-size

Is now up to you to guess which render is Blender internal and which is Cycles! :eyebrowlift2:

Next step should be testing with a real scene. Curious about that…

[fahr (Chad Gleason)]

Honestly this is awesome! Even though what I REALLT want is baking in Cycles, this is the next best thing! Thanks for working on this, and I hope it makes it to trunk. We desperately need a GI baking solution!

[sgraham]

@fahr

Honestly this is awesome! Even though what I REALLT want is baking in Cycles, this is the next best thing! Thanks for working on this, and I hope it makes it to trunk. We desperately need a GI baking solution!

Thanks and you’re welcome! That is really what I wanted too! But this was the easiest for me to implement… I am pretty sure there is a good reason why they haven’t added baking to cycles yet. (because it would be a lot of work)

[CDMJ (Craig Jones)]

They are working on baking in Cycles for the two man team from the Valve initiative - but from what I read, it will still bake from the Cycles material to a shadeless blender internal material So Blender Render will still be a part of the pipeline… and thank you for working on this, it will definitely improve the possibilities for artists.

[sgraham]

@lsscpp

I made some tests.

Thank you lsscpp! This is really cool. I can’t tell the difference and I’ve been looking at these images for a long time! Thanks for the Blend file too, I couldn’t figure out how to get the specular in Cycles, was messing with a Glossy node, but it just gave straight reflections.

[sgraham]

@Craig Jones

They are working on baking in Cycles for the two man team from the Valve initiative - but from what I read, it will still bake from the Cycles material to a shadeless blender internal material So Blender Render will still be a part of the pipeline… and thank you for working on this, it will definitely improve the possibilities for artists.

You’re welcome! Interesting… I wonder if this has to do with the fact I saw stuff about nodes and strands in the baking code for BI. Or are there some type of nodes for BI that I’m not aware of? I don’t really know what strands are either…

[Ace_Dragon]

@lsscpp

I made some tests.
Using more than 2 bounces gives a little more light in the scene, but definitely pumps render times too far. I compensate this introducing ambient occlusion at 0.01 in Additive mode.
The result looks really good, the only problem is that the test took 1:05 minutes while Cycles took about 6 seconds!!!

Looks like this patch is running into some of the same barriers that Brecht encountered before he decided to drop all work on BI and (after a short stint at Refractive software), develop Cycles.

This seems to confirm that BI’s raytracing code and shading architecture in general needs some major rework done if the old engine is to overcome one of its greatest weaknesses, and that is the fact that it initially wasn’t designed with raytracing in mind and thus is partly why you can easily slow it down to a crawl when new raytracing features are added and used.

So in other words, the speed issues may be related to the code architecture which may not be easily resolvable.

[Therahedwig]

Uhm, isn’t the difference mostly because cycles is gpu enabled and BI isn’t? Because honestly, without an nvidea gpu cycles is just as slow if not slower than BI with aproximate lighting.

I think in that regard, the real problem is that BI is not gpu enabled instead of BI not handling raytracing well.