Page 1 of 1

Pro 2.5d build 20 bug: texture generation not completing

PostPosted: Thu Sep 11, 2008 1:43 am
by fusi
Hi i think ive found a bug in Pro 2.5d build 20:

i created the following project:

http://91.135.13.31/04.proj

and generated a design map from it - didnt edit it. i then ran the generation wizard, selecting all the options. on the lightmap configuration wizard pane, i deselected cast shadows (though i dont think this has anything to do with the bug as i have experienced the same bug with this option enabled). i then let it run. i returned some time later to find the following onscreen:

Image

i left it for a while longer hoping that maybe it would unstick itself but unfortunately it didnt and i had to cancel the render :(

platform configuration:

win xp (32bit) sp3
l3dt pro 2.5d build 20

core 2 quad q9550 cpu @ stock 2.83ghz (x8.5)
dfi t2r x48 lanparty mobo - fsb @ stock 333mhz
corsair dominator xms2-8500 @ 1066mhz @ 2.1v @ 5-5-5-15
ati 4870hd 512mb @ stock: core 750mhz / mem 900mhz

i doubt sound card, psu, case etc are relevant. as i mentioned i have experienced this bug before with a different project. l3dt remains responsive - it seems to me like theres some thread synchronisation issues somewhere - sorry! :s

PostPosted: Thu Sep 11, 2008 9:26 am
by Aaron
Hi Fusi,

Thanks for the bug report. Can you please send me the logfile? (to aaron@bundysoft.com) You can open it from the start menu under:

All Programs->Bundysoft->L3DT [version]->L3DT log file

This logfile should trace the last actions of L3DT before you killed the calculation.

I'll also run the same calculation (i.e. same maps size) on my quad core and see how it goes. That logfile sure would help though ;)

Best regards,
Aaron.

PostPosted: Thu Sep 11, 2008 6:17 pm
by fusi
Hi Aaron - sorry i didn't attach the log file - didn't realise one existed! i just had a look through the log and there's nothing there really that stands out (just a load of tile swapping messages and then 'user cancelled' or smt like that) - but sods law i cant link it because i closed notepad and opened l3dt to click through the help menu to get to this forum and unknowingly overwrote it!

i'm rerunning the same steps again now to see if i can reproduce it

p.s. one thing i do recall is that at about halfway through the bugged texture render, i had a quick look at the progress and saw that the cpu usage was around 75% (in task manager) - im rerunning it now and its at a solid 100% (on all cores that is) so perhaps one thread got stuck somehow in the bugged run? just my 2pence :)

PostPosted: Fri Sep 12, 2008 12:00 am
by fusi
Hiya

managed to do it again - here's the log file:

http://91.135.13.31/log.txt

you'll have to scroll up a bit (line ~13700 ish) to see where the texture generation failed and i had to abort

the same symptoms were presented; negative time remaining and around 25% cpu being consumed - the texture appears to be complete in the preview window - makes me think its a thread sync/race issue - the worst kind of bug to fix! :s)

however, cpu usage remained at 100% until it stopped functioning - unlike the previous failed attempt where it hovered around 75%

this time i had edited the design map and enabled shadow casting (might of done a few other things too but i cant remember - i think its recorded in the log anyway but you know that already :p)

btw ive also noticed quite deep holes (maybe 5 times as deep as the highest peak) being generated sometimes on height-maps - almost like the erosion has eaten away at just one vertex - the erosion coefficients were generated by l3dt - doesn't happen very often though and its not a very big deal

anyway, i have run it again with the same configuration and it has completed successfully this time

hope this helps
cheers
fusi

PostPosted: Fri Sep 12, 2008 10:49 am
by Aaron
Hi Fusi,

Thanks for the log. I've managed to reproduce the fault, and I'm now looking into it.

Best regards,
Aaron.

PostPosted: Fri Sep 12, 2008 1:18 pm
by Aaron
Hi Fusi,

Can you please download and try out the v2.6 beta 4 update from the downloads page. This version fixes (or so I hope) a bug in the multithreaded calculation manager that may have caused it, on occasion, to tie up a monitoring thread in a low-priority (mostly sleeping) infinite loop.

Please let me know how it goes.

Best regards,
Aaron.

PostPosted: Sat Sep 13, 2008 8:52 pm
by fusi
Hi Aaron

it seemed to be ok for a bit, but unfortunately it then hung on the light map:

screenshot: http://91.135.13.31/l3dt_bug02.jpg

project: http://91.135.13.31/08.proj

log: http://91.135.13.31/Pro2.5.4.21_log.txt

debug data: http://91.135.13.31/debug.dat

HTH
cheers
fusi

PostPosted: Sun Sep 14, 2008 12:51 am
by Aaron
Hi Fusi,

Okay, thanks for the info. I'm relieved, in a way, to hear that the same problem is evident with the light map. The light map calculation uses the same threaded tile manager as the texture mapping calculation, so this find pretty much confirms the threaded tile manager is to blame. A quick inspection of the code shows that it has some state information that is not properly guarded against concurrent thread access, and this could result in the manager thinking it has threads active when it does not. I will sort this out today or tomorrow, and post back here when the fix is ready for download.

I thank you for your patience, and apologise for the inconvenience caused by this bug.

Best regards,
Aaron.

PostPosted: Sun Sep 14, 2008 2:11 am
by fusi
no sweat - glad i can help :)

p.s. plz multithread the shadow caster! its the slowest stage! (i cant think of any dependancies that would make it an unsuitable candidate?) :)

PostPosted: Sat Sep 27, 2008 6:21 am
by Aaron
Hi Fusi,

The fix for this bug is included in v2.6 beta 5, which is now on the downloads page. Please let me know if it doesn't work for you.

fusi wrote:p.s. plz multithread the shadow caster! its the slowest stage! (i cant think of any dependancies that would make it an unsuitable candidate?) Smile


This is high on my to-do list for v2.7. The algorithm, as currently written, has some performance optimisations that can't be multi-threaded. However, I think I can re-write the algorithm with multi-threading and with some different (possibly faster) optimisations. I'll look into this after v2.6 is finally released.

Best regards,
Aaron.

PostPosted: Tue Sep 30, 2008 6:19 pm
by fusi
ok cool thanks Aaron ill give it a whirl and let you know

PostPosted: Mon Mar 09, 2009 11:17 am
by Aaron
Hi Fusi,

fusi wrote:p.s. plz multithread the shadow caster! its the slowest stage!


As promised in my previous post in this thread, I've optimised the shadow raycast routine in the latest developmental build (see here), which improves the shadow casting speed by a factor of between 3 and 30 times.

Cheerio,
Aaron.