Disappointed... ok - my own fault! :)

Started by EoinArmstrong, April 18, 2009, 01:49:34 AM

Previous topic - Next topic

EoinArmstrong

Hi there.

Some may know me as a long-time v0.9 user, and I've dabbled only a little in T2, waiting for its full release.

So when it arrived I eagerly opened it and tried a bog-standard render (1680x1050, 2 fractal terrains, only 1 extra surface layer, 3 grass pops, 2 cloud layers) on my machine (Quad Core 3Ghz, Win XP Pro SP 3, 3GB RAM), and left it overnight.

It crashed about halfway through, citing an 'Unknown Error in Ray Trace'.  Super.  As I use my machine for entertainment purposes only, it's a big ask to have it locked up for tens of hours for a render which may fall down dead at any stage.

Anyway, I've attached the tgd such as it is.  I hope the product stability improves, because at the moment my faith in it is fairly shattered. :(

Cheers,

Eoin.

Mohawk20

I checked the tgd in notepad, and noticed your populations are reasonably large. One of 8000x8000 and two of 12000x12000. If the populations are too big, you might be using a bit too much RAM, resulting in a 'ray trace' error (basically you're out of ram, so the next render bucket cannot allocate enough memory for the next ray trace calculations).

If you render again, could you perhaps check the amount of RAM and Virtual Memory used according to Taskmanager?
Howgh!

Oshyan

#2
Hi Eoin, it's great to see you around here again. It's unfortunate that your first experience back has been a negative one, but I hope you'll give it some time and do a bit more experimentation. By and large the TG2 final is pretty stable. The main issue you run into, which we don't yet have good error handling for, is memory - as Mohawk mentioned. If you do something that happens to use too much memory, it will usually just crash rather than gracefully let you know. We do intend to improve that behavior in the future.

In the meantime there are a few things you can do to help. First, you can turn on preallocate subdivision cache in the Renderer settings Advanced tab. This will help detect memory issues early by attempting to allocate the majority of needed memory at the beginning of the render, rather than increasing memory use over the render period.

Second, be judicious about your use of detail settings. Because of the many different detail settings and the level of control offered in TG2 vs. TG 0.9 it's a lot more risky to just crank every detail setting, especially with complex scenes. You've got a detail of 0.9 here which, while not terribly excessive, may simply be unnecessary (0.7 often provides a great level of detail with much lower render time), 3 *Very* high detail populations (did you test with lower detail to see if you needed Very High?), and a 3D cloud layer with nearly 300 samples, equating to a relative "Quality" value of 3 for that cloud layer. Now all of those are potentially reasonable settings *if you need them*, but it's important to realize that you often simply don't need "max quality", and it's best to experiment with crop regions and lower detail renders to find the best balance of detail, quality, and render time.

Third, keep an eye on your memory use. You have 3GB of memory, but that doesn't mean TG2 can use that much. TG2 is a 32 bit application running in a 32 bit operating system, so unless you have special tweaks configured, it can only ever use a maximum of 2GB. And if you have other apps running, it can be even less, especially when it needs to allocate a large block of contiguous memory (if available memory is sufficient but fragmented, the allocation can still fail). One thing you can do which may help is enable the so-called "/3gb switch", which is a configuration trick to allow applications that are properly setup to use *up to* 3GB of RAM themselves. Of course you only have 3GB total so this could be problematic, but it may be worth experimentation.

I hope that provides some useful information, and I hope you keep trying long enough to see how far we've come since TG 0.9. :)

Edit: forgot to mention a few other things you can do. You can reduce the size of the cache to conserve memory. This *may* slow down rendering, but it's a useful option to consider. There is a lower limit, I believe 200MB, but vs. the default 400MB you're saving half the memory, so it may be useful. The other option to consider is using less render threads. Your quad core will use 4 by default, but each additional render thread uses more memory. Of course it's not ideal to cut the number of render threads down as you lose performance, but again it may be a useful troubleshooting option or last resort. Hopefully the other ideas above help more.

- Oshyan

EoinArmstrong

Hi folks.

Thanks for the quick responses.  I think I've read the memory issue before and if I'd been more careful I should have realised my problems there.  Teaches me once again to be throughtful, rather than a total drama queen :D

Okies - Strange thing about the clouds - I set the sample to 64 and it set itself subsequently to 300-odd?  Something wrong I'm doing there?  Admittedly yes - "Very High" was prob unwise for simple grass, given the number of instances.

I look at the image-sharing forum almost every day and I'm blown away by what I see.  If I get even halfway there, I'll be delighted.

I'll be a bit more judicious with my memory, and, of course, I'll RTFM too - lol.

Hopefully I can come up with a decent try over the weekend.

Thanks again,

Eoin.

Oshyan

I'm not sure why your clouds would set *themselves* to 300 samples, but usually the quality slider is a pretty good starting point for sample levels and good quality output. A value of 1 will set the samples to a good level for your particular cloud settings. Sometimes I bump it to 1.5 for good measure, but I seldom need more than that. However if you're working with really demanding, complex, or unusual clouds you may need to set the number of samples manually.

Knowing your old TG 0.9 work I'm excited to see what you can do with TG2 once you get the hang of it. :)

- Oshyan

Matt

#5
The number of samples is automatically adjusted whenever you change the depth, density or edge sharpness, in order to keep the 'quality' setting approximately the same. Basically, the quality setting drives the number of samples, and more samples are needed to maintain equivalent quality when you increase the depth, density or edge sharpness.

It works this way so that you don't always have to think about the number of samples - as long as the quality setting is reasonable.

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

Oshyan

Ah right, I'd forgotten about this. ;D

- Oshyan

Tangled-Universe

Quote from: Matt on April 20, 2009, 09:49:19 PM
The number of samples is automatically adjusted whenever you change the depth, density or edge sharpness, in order to keep the 'quality' setting approximately the same. Basically, the quality setting drives the number of samples, and more samples are needed to maintain equivalent quality when you increase the depth, density or edge sharpness.

It works this way so that you don't always have to think about the number of samples - as long as the quality setting is reasonable.

Matt


Everybody should read this so others wouldn't endlessly have to repeat in other topics that not the amount of samples is decisive for quality but the quality setting itself :)

Oshyan

I'm not sure what you said is clear T-U. The samples value is really what determines actual render quality. The "Quality" slider just sets an approximate level of quality that you want to achieve and adjusts samples accordingly to maintain that level of quality when you make cloud setting adjustments.

- Oshyan

Tangled-Universe

Quote from: Oshyan on April 22, 2009, 01:09:37 AM
I'm not sure what you said is clear T-U. The samples value is really what determines actual render quality. The "Quality" slider just sets an approximate level of quality that you want to achieve and adjusts samples accordingly to maintain that level of quality when you make cloud setting adjustments.

- Oshyan

You often see people asking questions that their clouds don't look good or grainy and that they don't understand it because they render with "X samples".
The number of samples alone doesn't tell anything if you don't know especially the depth, density of the clouds and detail setting provided by that sample-count.

If you say "my clouds look bad, although I use a quality setting of 1.5" that would make lots more sense then because that would automatically tell you that you have enough samples for that type of clouds. Like you said yourself the quality slider is an approximate level for quality. The quality setting is a constant, not the amount of samples. So whatever you change to your cloudsettings, the quality setting doesn't change but the samples do. Therefore it is way more convenient to speak in quality-values rather than sample-values.

IMHO of course :)

Oshyan

Ahhh I see what you were saying. So yes, absolutely, I agree! :)

- Oshyan