Kray Keeps on Krashing

[sarford]

Since Kray for Mac is unstable I've switched to Windows for rendering my scene.
I've loaded up my room with shaders, most of them nodal.
I load up my scene, set my resolution multiplier to 25%, select Kray Options, switch to Photon Estimate Precomputed and hit Render Frame.
No problem there, Kray renders just fine.
Now I add the footer command 'recurse 100' and hit Render Frame again.
LW freezes for ever and I have to force quit.

Strange thing is, this morning it worked, even with recursive 100. I am at a total loss... what the hell is happening here?

[sarford]

This is after I switched off all nodes in the surface editor.
After adding the 'recursive 100' command, LW freezes.
It also freezes if I increase the recursive level through the Render Global tab in LW instead of the Footer cmd.

[jure]

I have no idea why it would work one time and not the other. But what I do know is that "recurse 100" can be very demanding on the cpu so maybe it didn't stop, it just takes a loooong long time to render. However I have no idea why you would want to use recurse 100 command. This is just unnecessarily adding to your render time.

In any case, if it's crashing and it can be reproduced easily then send me the scene and I'll make sure the bug gets fixed.

[sarford]

i Jure,

Thanks for your reply. I know recursion in Lightwave means how many times a ray reflects or refracts, but my perception is that Kray uses the recursion level as the number of times a ray bounces inside the scene. I got that idea from the wiki. It also states that a high recursion number doesn't raise the render times much.

Ray recursion limit tells Kray how many times the light should bounce. In contrast to other render engines, a high number of light bounces doesn't increase the render time significantly.
The number of bounces can be overridden by adding the following command to the tailer line in Kray GUI: recurse 100; This will tell Kray to use 100 bounces of light.

Did I mis-interpert the explanation and is recursion in Kray the same as in LightWave?

Cheers, Simon

[jure]

i Jure,

Thanks for your reply. I know recursion in Lightwave means how many times a ray reflects or refracts, but my perception is that Kray uses the recursion level as the number of times a ray bounces inside the scene. I got that idea from the wiki. It also states that a high recursion number doesn't raise the render times much.

Did I mis-interpert the explanation and is recursion in Kray the same as in LightWave?

Cheers, Simon

No this is entirely correct. However you will not see any difference once bounces get above 15-20... Because light contribution from those bounces is very very low. However adding more bounces for reflections and refractions will mean kray needs to trace rays deeper and 100 is a very high number. Check out Vray settings for example, by default they trace only 5 recursions for reflections/transparency to save render time.

[Janusz Biela]

recure 10 is enough for render. More is just longer without big difference.

[sarford]

Ok, one more question, not to be snugg but just curious, if you shouldn't use a high recursion level, why can you add a footer cmd with level 100 ? In what cases would you use that?

cheers, Simon

[Janusz Biela]

Ok, I understand. But how do I get my scene lighter in the shadow areas (areas without direct sunlight) without brightening the sun areas? My idea was by increasing the number of bounces the shadow areas get lighter.
One more question, not to be snugg but just curious, if you shouldn't use a high recursion level, why can you add a footer cmd with level 100 ? In what cases would you use that?

cheers, Simon

Dark shadowas are not problem with engine. I repeat again Kray render with mathematics rules as all engines renders (V-ray, Maxwell etc) Problem is with your TONEMAP setup and lights. People use all kind of trick to bright up scenes (for example in interiors best tricks are Area lights in windows and area lights from the ceiling . Does not exist tonemaping silimar as human eye which reduce strong light from outside and keep good contrast inside room (of course programmers try to create it...Exponential, LWF Gamma, Reinhard...but still wihout good results). I f You like easy way please use EXPONENTIAL, with higher parametr (3-6)....but this is not ideal solution. Exponential is old tonemaping but far from ideal results. It easy control light with this tonemap becouse nicely reduces bloom lights effects. The most difficult is use LWF gamma 2.2....

[jure]

Ok, one more question, not to be snugg but just curious, if you shouldn't use a high recursion level, why can you add a footer cmd with level 100 ? In what cases would you use that?

cheers, Simon

Honestly you would never use it. Except maybe in the case where you have 100 glass planes one after another...

[jwiede]

Okay, so I realize this thread is a bit old now, but your last comment got me thinking (and I needed time to recover from the headache that caused)...

Imagine a scene with a glass bowl of various gemstones, and a spotlight shining into/through the bowl onto a neutral-color tabletop below. Since you've potentially got a large number of little refraction entry/exits (the gemstones), wouldn't it be reasonable to set recurse in such a case to the number of gemstones plus 2 (for bowl)?

I'll admit I've used pretty high numbers for recurse in the past specifically because I knew I had a bunch of refractive objects in the scene, and didn't want to worry about it so gave an arbitrarily high number. I realize losing some of the later bounces really wouldn't make that much of a difference, but at the same time, sometimes it's the tiny extra details which make the difference between "adequate" and great.

Given the wiki description, it even seems rational for users to set recurse values that are at least equal to the number of potential entry/exit-generating items in the scene. That it's crashing at recurse of 100 shouldn't be happening in any case, right?

If you can't reproduce the problem there, would other scenes that generate the crash/freeze help?

Also, will an update be coming that fixes the phys-sky (sky, not sun) issue? Could it perhaps this issue as well?

[jure]

Given the wiki description, it even seems rational for users to set recurse values that are at least equal to the number of potential entry/exit-generating items in the scene. That it's crashing at recurse of 100 shouldn't be happening in any case, right?

Yes this is all very true what you are saying. But like I said, only use it when you really need it...

If you can't reproduce the problem there, would other scenes that generate the crash/freeze help?

Yes. Please send all crashing scene to us. It's very important that we get this scenes so we can fix bug. But please try to reduce them as much as possible before sending them to us.

Also, will an update be coming that fixes the phys-sky (sky, not sun) issue? Could it perhaps this issue as well?

Which sky issue do you mean exactly?