Unknown Error Occurred in TraceRay

Started by Heeshung, December 21, 2008, 02:06:30 pm

Previous topic - Next topic

Heeshung

I let Terragen 2 sit on the backburner for a while because of crashes whenever I tried to render a water-dominant scene.  The beta finally came out, and I decided to give the same project another go.  I tweaked some things, and divided up the render to run on 3 physical processors and 6 physical cores.

One processor rendering the sky has finished, another one rendering the water is still going.  The last one, which is doing the majority of the work, seems to have crashed.  It doesn't seem like a FULL crash; the program still works and the render window is movable.  However, the render time counter has stopped.

This is what the screen looked like when I switched it on in the morning to check on it:


The computer is running Windows 7 Build 6801 x64 on a Intel Core 2 Quad Q9450 2.66GHz.

I'm not sure if it is still water-related as the error does say that it's a TraceRay.  All help is greatly appreciated.

Oshyan

It sounds like the last render thread has crashed. TraceRay probably does indicate the water as reflections are raytraced. Since you're on a 64 bit OS I'm not inclined to think memory is at fault, but it's worth knowing how much you have anyway. I would also suggest not running with more than 4 threads, and I'm unclear why - with a quad core processor - you say you're using "6 physical cores".

To be absolutely sure it's not memory or threading related, I suggest in fact testing with "0" threads (set min and max threads to 0 in your renderer settings). It will of course be much slower this way, but we can be more certain it is an error in the core of the renderer and not a memory or threading problem.

- Oshyan

Heeshung

Sorry, you can disregard what I said about 6 physical cores.  I just divided up the render to run on a couple computers simultaneously.

I have 4GB of memory.

reck

Hi Heeshung,

How are you finding Windows 7? I've been hearing some good things but i've not had a chance to try it uey.

Heeshung

Um, I know people...  I think I'll leave it at that.  ;D

I've run into surprisingly few problems so far.  Also, this is build 6801.  Some new builds have been developed which might solve the few problems I have.

Oshyan

Quote from: Heeshung on December 21, 2008, 04:30:08 pm
Sorry, you can disregard what I said about 6 physical cores.  I just divided up the render to run on a couple computers simultaneously.

I have 4GB of memory.


So you split up the render across multiple computers using crop rendering? But the error you're reporting is for the Core 2 Quad machine specifically? What are your thread settings for that machine?

- Oshyan

Heeshung

Quote from: Oshyan on December 21, 2008, 05:23:31 pm
So you split up the render across multiple computers using crop rendering? But the error you're reporting is for the Core 2 Quad machine specifically? What are your thread settings for that machine?

- Oshyan


Exactly.  The minimum is at 1 and maximum is at 16 (I've never changed them).  Also, another computer just finally finished rendering its section, and I'm noticing that the hues are slightly off, even they're using the exact same file.  Is there any way to fix this, or should I just stick to rendering with one machine?

Oshyan

Stick to rendering on one machine. There will be GI differences across machines, and even between crop areas on the same computer at times.

Try setting min and max threads both to 0 and rendering the same area that crashed.

- Oshyan

Heeshung

Thanks.  I'll try that as soon as I can.

rcallicotte

Oshyan, is the renderer really that random?  That seems sort of...weird. 


Quote from: Oshyan on December 21, 2008, 10:43:53 pm
Stick to rendering on one machine. There will be GI differences across machines, and even between crop areas on the same computer at times.

Try setting min and max threads both to 0 and rendering the same area that crashed.

- Oshyan
So this is Disney World.  Can we live here?

cyphyr

I remember in the old days that Intel and Amd processors could produce differing results particularly when dealing with fractal shaders. I think this was something to do with the differences in the Maths co-processors. Obviously not the same issue here but I can see that different machines and architectures may produce different results. Definately something that needs addressing.
Richard
www.richardfraser.co.uk
https://www.facebook.com/RichardFraserVFX/
/|\

Ryzen 9 3900X @3.79Ghz, 64Gb (TG4 benchmark 6:20)
i7 5930K @3.5Ghz, 32Gb (TG4 benchmark 13.44)

Oshyan

Quote from: calico on December 23, 2008, 12:06:44 pm
Oshyan, is the renderer really that random?  That seems sort of...weird. 


Quote from: Oshyan on December 21, 2008, 10:43:53 pm
Stick to rendering on one machine. There will be GI differences across machines, and even between crop areas on the same computer at times.

Try setting min and max threads both to 0 and rendering the same area that crashed.

- Oshyan



Sort of. Matt would be able to explain why a lot better than I can. I believe it may have been covered elsewhere before however.

- Oshyan

Matt

There are often discontinuities in the GI across crop boundaries because each cropped render only takes samples from within that crop region. The GI relies on averaging lots of samples together; the GI at any point in space is a blend of available samples that are nearby. Because it can only use samples from within the crop, they will be different from those used by another crop region. There are a few ways we're planning to improve this. One of them will be to allow the GI pre-pass to take samples outside of the image or crop region. Unfortunately this outside region will need to be pretty big to eliminate the problem entirely. Another thing we'd like to implement is the ability to render the GI pre-pass for an entire image beforehand, save it, and then reuse it in other renders.

Matt
Just because milk is white doesn't mean that clouds are made of milk.

Mohawk20

Quote from: Matt on December 30, 2008, 03:36:37 am
Another thing we'd like to implement is the ability to render the GI pre-pass for an entire image beforehand, save it, and then reuse it in other renders.


That would be really great!
Howgh!

Tangled-Universe

I'm really not that familiar with all the technical terms but isn't that being called "GI baking" and is often used in animations so the GI just has to be calculated once for an entire sequence of frames?