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.
That's all.
In other news, ray detail multiplier, unique variations and .obj export, those are great! :)
i had the same problem.
it seems its just better to caculate the pops when you render, does'nt seem to have any problems
Hmm. Zaii999, did you have problems with other populations, or just rocks?
- Oshyan
I tried to calculate the population at render time, the same results with a rock object.
yeah Oshyan, it seems to do it with all object populations
UPDATE: it appears to be working properly sometimes, and if it does'nt when i press populate it will update after i move around in the 3d preview.
To save starting a whole new thread to go with the many different 2.3 threads being posted I'll just add this to the one I started and edit the subject.
_______________
Default terrain+RTE=Weird flattened areas.
[attachimg=#]
Noticed this briefly last night when I was playing with something else and thought I'd have a better look at it today to see if it was an actual error or just something I did wrong. I can't fix it.
Interestingly, the planet doesn't render this error with RTE when I've been doing the 'rescaled noise' renders, the only difference in the surfaces seems to be a default power fractal, instead of just 1m(max) displacements from the function nodes, which render perfectly.
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.
I thought it was just my computer.
i've noticed that too, some of my pops would take like 5min+ to finish calculating.
Quote from: njeneb on April 22, 2011, 01:18:59 PM
I have also noticed that 1,000,000 plus pops calculate much faster.
I thought it was just my computer.
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.
crazy.
Regarding the white shapes in the update post.
All my GI pre-passes also feature these arc shapes now. It only appears in a render if RTE is used.
Screenshot of a holy pre pass, GI=2/3.
I can see right through nearly every GI pass I'm doing to the atmosphere behind, it can't be calculating surface lighting accurately like this, can it?
This isn't normal, of course. We'll need to know what's different (from the default) in your project to figure out what's causing it.
QuoteI 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.
Quoteit appears to be working properly sometimes, and if it does'nt when i press populate it will update after i move around in the 3d preview.
I can confirm that.
Quote from: Matt on April 23, 2011, 11:49:43 PM
This isn't normal, of course. We'll need to know what's different (from the default) in your project to figure out what's causing it.
Quite a lot different actually. I have my own default file, I'm going through it bit by bit just now. This doesn't happen with your factory settings default file, only mine and only since updating, it was never like this in 2.2.
If I can't pinpoint it I'll post a .tgd later on. Cheers.
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.
[attachimg=#]
[attachimg=#]
Other things I've tried; I've been through nearly all(if not all) of the settings, I've replaced all these nodes one by one with newly created ones (and with copy/paste from the program's default.xml file). Still got the problem whenever I insert and replace nodes to the .tgd.
Weird, looks like I'll just have to create a new default project from scratch, unless anyone can see where I've went wrong here.
* Completely unrelated. I noticed some intriguing lines in .tgd parameters when I was going through them in notepad. I must see if they can be made use of(I won't ask for help if I break those). ;)
Quote from: dandelO on April 24, 2011, 02:53:17 PM...I must see if they can be made use of...
They can. Great! :D
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
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.
It happens in your file even with RTE *off* as far as I can tell.
- Oshyan
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.
Oh, I see what you mean.
- Oshyan
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
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
Odd, I replaced the Background Node in that project and made sure it was enabled and it seemed to still be happening.
- Oshyan
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
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.
DandelO, your render settings were different too. But they are not the cause of the problem.
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
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
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.
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
I neglected not to use unique variations and then last night when I was rendering something else I thought of that.
Sounds right, since the last version didn't create them it's understandable that the calculation would take longer. If it's for a sphere population then this is a feature I don't need anyway. Thanks for the reply, Jo. I'll test it out once I'm finished rendering. :)
"Unique variations" has been in the Rock object since 2.0, maybe even the Tech Previews.
I was going on these lines from the 2.3 change log.
QuoteIf a population uses an object generator's Unique Variations feature (e.g. the Rock object), there was a bug that prevented changes to the object from being seen by the populator. This has been fixed. However, you still need to force a repopulation in order to get the changes.
That just means that any change after the first time the rocks were generated wasn't being picked up. But unique variations were always working in some manner. If you saved and reloaded a project, the changes would happen. Now you don't have to. That probably means you weren't really getting a population of smooth rocks before, until the next time you loaded the project.