www.kraytracing.com

Where does KRay stand in SSS support? I'd like to see that up and running.

Hi! It would be nice to do a preview render selection "region"

jrandom wrote:Where does KRay stand in SSS support? I'd like to see that up and running.

It is. Special command turn ON this. But I am not sure that part code is finish by Grzegorz...so we cant`t activate.

Chumarin Ruslan wrote:Hi! It would be nice to do a preview render selection "region"

eeeeem... just use LW "limited region"... or am I missing something?!

Throwing KRay at 24 hardware threads (two 6-core hyperthreaded processors) has brought something interesting to light:

When I use the Scanline mode (fastest, gets the most out of each and every hardware thread) there are Final Gather artifacts at the meeting points between areas rendered by different threads. This makes the Final Gather more shimmery in animations and there are some subtle but noticeable artifacts on flat, solid-colored areas lit by diffuse light. These artifacts can be minimized by adding more passes, but that's a lot slower.

If I choose, Random, Renderworm, or Frost, these artifacts are minimal (or in the case of Random, gone entirely), but these render methods only take advantage of a fraction of my total processing hardware. Aside from better AA, what I would most like to see is the Random render method updated to take full advantage of many-thread processors.

jrandom wrote:Throwing KRay at 24 hardware threads (two 6-core hyperthreaded processors) has brought something interesting to light:

When I use the Scanline mode (fastest, gets the most out of each and every hardware thread) there are Final Gather artifacts at the meeting points between areas rendered by different threads. This makes the Final Gather more shimmery in animations and there are some subtle but noticeable artifacts on flat, solid-colored areas lit by diffuse light. These artifacts can be minimized by adding more passes, but that's a lot slower.

If I choose, Random, Renderworm, or Frost, these artifacts are minimal (or in the case of Random, gone entirely), but these render methods only take advantage of a fraction of my total processing hardware. Aside from better AA, what I would most like to see is the Random render method updated to take full advantage of many-thread processors.

Random should use all your CPU power. If it's not then something is wrong. Like I said in the other thread, wait for the next update. Or you can also try this: enter previewsize 0,0; into header commands and use random mode. See if this uses all your cpu power.

jure wrote:

Chumarin Ruslan wrote:Hi! It would be nice to do a preview render selection "region"

eeeeem... just use LW "limited region"... or am I missing something?!

I'm using LW Limited region. I compare with 3ds max Vray. Very convenient to allocate the desired area that needs to be corrected, and then save the image.

Chumarin Ruslan wrote:

jure wrote:

Chumarin Ruslan wrote:Hi! It would be nice to do a preview render selection "region"

eeeeem... just use LW "limited region"... or am I missing something?!

I'm using LW Limited region. I compare with 3ds max Vray. Very convenient to allocate the desired area that needs to be corrected, and then save the image.

I'm still not sure about this... what 3dsmax does that you can't do in LW?

jure wrote:Random should use all your CPU power. If it's not then something is wrong. Like I said in the other thread, wait for the next update. Or you can also try this: enter previewsize 0,0; into header commands and use random mode. See if this uses all your cpu power.

No biggie, I shall wait for the next update. Is there a timeline on when it's coming out or are you still in the thick of writing it?

jrandom wrote:

jure wrote:Random should use all your CPU power. If it's not then something is wrong. Like I said in the other thread, wait for the next update. Or you can also try this: enter previewsize 0,0; into header commands and use random mode. See if this uses all your cpu power.

No biggie, I shall wait for the next update. Is there a timeline on when it's coming out or are you still in the thick of writing it?

no we are just testing stability. it should be out in a week or two.

jure wrote:no we are just testing stability. it should be out in a week or two.

Hooray! I am very looking forward to it.

jure wrote:

jrandom wrote:

jure wrote:Random should use all your CPU power. If it's not then something is wrong. Like I said in the other thread, wait for the next update. Or you can also try this: enter previewsize 0,0; into header commands and use random mode. See if this uses all your cpu power.

No biggie, I shall wait for the next update. Is there a timeline on when it's coming out or are you still in the thick of writing it?

no we are just testing stability. it should be out in a week or two.

Do you have list of changes?

Region Rendering with n-Poly.
It would be cool if it could be possible to select with an n-poly the region which should be (re)rendered. With the standard limited region i often have to rerender more than necessary. And there should be a "save" and "load" region option to keep this area reloadable for later changes.

yes VPR and micropoly displacement would be AWESOME !

After much experimentation, this is what I'd like to see:

1. Much better anti-aliasing.

2. Animation-quality (ie. flicker-free) final gather that is feasible on a single hefty home computer (as opposed to having to rent out a render farm). This one is such a big deal that I bought the PBRT book and am going to try my hand and writing a renderer just to see how difficult a task this really is.

3. Micro-poly displacement would be phenomenal. This is what allows for realistic terrain and tree bark w/out multi-day render times per frame.