PDA

View Full Version : color bleed node setup



wellsichris
06-17-2009, 02:27 PM
okay for anyone that's interested this is where I'm at with a color bleed node setup. essentially each surface ray traces out to see what colors are around it. the random, randomizes the normals angle, the angle the ray is traced. Also this works with an environment. so if you have a gradient background. it will see that as well. Do know this isn't changing the luminosity of the surface, just the color. So if you have a white background and no lights. it's not like radiosity, all the things with this shader would have white added to there surface color but there would be no light to let you see that. it would just be black. So this isn't radiosity.

all the samples are in the AA so crank up that AA, just plug your basic color into the last multiply and then that into the color, and it should work. also you need Pom's Random Node for this to work. if anyone wants to push it further go for it. I'm sure it could be done better, the biggest issues for me is how the samples are tied to the AA, I wish I knew a smarter way to do that.

Cheers,
Chris

Panikos
06-18-2009, 01:57 AM
Hey, you invented GI :)

wellsichris
06-18-2009, 10:22 AM
on a per shader level, ;)

probiner
06-18-2009, 06:47 PM
Nice one

DrStrik9
06-20-2009, 04:12 PM
Dang. Tell me what it's like to have brains. :-)

wellsichris
06-24-2009, 11:59 AM
So I think I have found a bug, not sure, maybe someone has an explanation. so the first image takes .2 seconds to render. it's removing the random number and and just putting in an offset. postive 1 on the x input. no AA or AS, so super fast. but then you copy and do a negative offset on the x input and add those together then divide them by 2 just to get the average and the time jumps up to 26 seconds! and if you add more samples it goes off the charts. Each one by it self is .2 seconds, but then add and divide by 2 and you get a 100X slowdown? it doesn't make any sense, does anyone have any idea, or is this just a bug? anyway. If it worked like you'd expect a linear way. it would be fast, I expect some time to add and divide but not like this,

Chris

edit, so I added just a constant vector to the original and did the divide and it was .2 seconds. add and divide 2 vectors = .2 seconds. so the time to add and divide is nothing. it's something else,

UnCommonGrafx
06-24-2009, 12:09 PM
Could you save out a *srf for this surface as the nodes you shared aren't hooked up to anything. And the way I hooked them up firstly, didn't work. Changing from object to world (or vice versa) finally worked for me, even in fprime. I think...

Still not sure though.

wellsichris
06-24-2009, 12:32 PM
if nothing is plugged into the multiply at the end it won't work. the idea is take whatever shading network you have for color and multiply it by this node setup and then plug that into color. You can just plug it directly from the ray trace to color, but that means the color surface is just what it sees around it. so you have to have other things in the scene or an environment for it to work that way. and yes when it's plugged in right it works with fprime. 3.5

so the shader here is just going directly from the ray trace to the color.

Chris

UnCommonGrafx
06-24-2009, 12:40 PM
Ok...Hmm, perhaps I'm trying to use this for what it isn't intended.

Trying to use this as a shadow catcher-thingy for shadows on a luminous backdrop.

Thanks for the surface; off to try it.

wellsichris
06-24-2009, 12:42 PM
So it works in Fprime, adding multiple copies of the node setup then adding and dividing, works fine and is fast like you would expect. I have tested with 6 copies. anyway its not nearly enough to look good, but it shows the potential, and the speed, now if it only work in lightwave render.

if you test this one, same process applies, plug your color into the last multiply and then plug the multiply into your color input.

Chris

p.s. when you try to render with lightwave beware, it hangs so bad it won't even let you cancel the render. you have to kill LW. I'm leaning heavy in the, "this is a bug" direction.