Hang time - 2.3 + render error update

Started by dandelO, April 21, 2011, 02:34:10 PM

Previous topic - Next topic

Oshyan

Wow dandelO, this is a real mystery! I replaced virtually every node in that file and examined it line-by-line in a comparison tool with the default project. I must be missing something, but for the life of me I can't figure out why it's happening. Bizarre. Hopefully development can figure it out, heh. Thanks for the TGD.

- Oshyan

dandelO

Weird, eh? Nothing has changed from my default project since updating. All the same settings worked fine before.
Matt mentioned the other day that GI is calculated by the ray tracer, this error only appears in the GI pass and it only appears on the terrain when RTE is used. If that's any clue.

I can't make the included default.xml file render with the error, even using RTE. I'm stumped.

Oshyan

It happens in your file even with RTE *off* as far as I can tell.

- Oshyan

dandelO

Yes but when you check RTE, the terrain will render out with the holes included in the final rendered image. If RTE is unchecked only the GI prepass is affected and the terrain renders as normal.

Oshyan


Matt

Quote from: dandelO on April 24, 2011, 02:53:17 PM
Weird, looks like I'll just have to create a new default project from scratch [...]

This would be a good idea every time we release a new version anyway. Often there are changes to the defaults which are important, and you'll miss them if you always use a custom startup project.

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

Matt

#21
Quote from: dandelO on April 24, 2011, 02:53:17 PM
I've stripped down my default project to the very minimum nodes where the problem can still be seen, there's usually loads of nodes in there so I've deleted them one by one. Attached it here.

It's being caused by supersample prepass. I get the same problem with the default scene if I enable this (have to disable the backgroud node to make the problem visible). I'll look into it right away.

EDIT: I get this problem with the default scene, even without supersample prepass, just by disabling the background node.

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

Oshyan

Odd, I replaced the Background Node in that project and made sure it was enabled and it seemed to still be happening.

- Oshyan

dandelO

Same here but only when the BG is disabled, like you said.
When I was going through the settings one at a time, I noticed my BG node was checked to cast shadows(a hangover from an old version, I think), I changed it to unchecked, in line with the default.xml before I uploaded it here, that was the only difference I could see in the actual node settings, although, before I removed the clutter nodes to upload it there was a few shaders inside it's internal network besides the background shader for stars.
I wonder why that scene has an enabled BG but still shows the problem.

I made a new default scene as advised. :D

Matt

Quote from: Oshyan on April 24, 2011, 08:45:50 PM
Odd, I replaced the Background Node in that project and made sure it was enabled and it seemed to still be happening.

I get that too. Even cutting and pasting the Background node is enough to allow it to happen, all in the default scene.
Just because milk is white doesn't mean that clouds are made of milk.

Matt

DandelO, your render settings were different too. But they are not the cause of the problem.
Just because milk is white doesn't mean that clouds are made of milk.

jo

Hi dandelO,

Quote from: dandelO on April 21, 2011, 02:34:10 PM
It says in the changelog to report anything strange with the new progress dialog changes.

I tried this on purpose as it was a little buggy with the old progress bar but it worked after a few seconds. Create a population of rocks, smooth normals, 2000 faces(to create a population of spheres). The single rock loads fine with the progress timer showing for a second or two.
When I hit populate TG has an infinite hang and whites-out asking to be terminated. Before, the progress bar would repeatedly reload about 5-10 times in quick succession and then the object would be ready.

I'm checking this out. It looks like TG2 is doing real work while it appears to be hung. Basically it's spending a big chunk of time doing something (allocating vertices for the rock objects) and not going back to the main event loop, which is why it looks like it's whiting out and not being responsive. It's certainly a long time to do it's stuff though. I don't think this is a consequence of the new progress window but maybe more to do with some population changes I'm not so familiar with.

Regards,

Jo

jo

Hi,

Thought I'd answer two at once :-)

Quote from: njeneb on April 22, 2011, 01:18:59 PM
I have noticed the populater window does not show up for small pops. I have also noticed that 1,000,000 plus pops calculate much faster.

Quote from: zaai999 on April 22, 2011, 01:28:19 PM
and last night, maybe it was just me, but i was changing the lead-in scale on a population density shader and i swear i saw some of the Bounding boxes update themselves.

I don't know about populations actually calculating faster. In any case the new behaviour is that the populator window, which is actually the progress window which shows progress for lengthy operations, won't show if calculating the population takes less than around about a second. This means you don't see the progress window popping up so much and also that some things may seem to update themselves more quickly.

Regards,

Jo

dandelO

Cheers, Jo. When I took the snapshot in the first post I'd left it calculating like that for about 10 minutes to be sure. Before, with the old progress bars in place, it would take maybe 10 seconds to populate the same area while the progress window flickered a few times repeatedly. Now it just seems to hang for ever and then need terminated. It was only a 100m2 area. Normally that sized area would be populated in a flash but I gave it a good length of time to see if it would work before posting here because really smooth rocks have always been a bit buggy to populate but they did work.

jo

Hi dandelO,

I've been looking into the rock population issue a bit more. Not 100% sure why the population is taking so much longer in the new version, although some changes were made to the Rock object. Essentially using 2000 faces is outside the range we expect the rock object to be efficient for. If you want a sphere you can populate you'd probably be better off using an imported model right now. Alternatively you could still use the Rock object but change the Unique variations param to 1. It's the creation of all the unique variations with the high number of faces which is slowing things down.

Regards,

Jo