Changelog

(L) [2006/02/06] [tbp] [Changelog - tbp] Wayback!

Throwing it all down there, for lack of a better place.

2006-02-05:

Fixed some inconsistencies regarding handling of CR/CRLF/LF in the Wavefront parser.

Upgraded code & lib to tolua++ 1.0.7, more bindings available, misc cleanups on both the lua & host sides.

Preliminary support for a progressive refinement render mode; right now there's no refinement.

PR/25983 was fixed, grabbed a fresh copy of the gomp branch and re-enabled the OpenMP path; after hours & hours of debugging i'm still left with // code that runs 2x slower on 2xcpu bringing a net result of 0. Zitch. Nada. Peanuts. This is really driving me nuts.

Worked a bit on an EP search, but nothing tangible yet.

TODO:

mmapping of tree & assorted data support (in/out) is still borked because of materials; i'm not even sure there's still a match between 32 & 64bit dumps anymore.

Got some surprising results on the 'postsparkasse' scene (that can be found on the same site as sponza's atrium) on the compiler side:

compiling...

~> first node done in 0.783 seconds.

build::build: 6.519 seconds for 230276 tri, nodes 864361, leaves 432181.

build::build: stats: max lvl 25, 1071606 items, 113269 empty leaves ( 26%), 35 max items per leaf.

Now that scene would need some tweaking as it's made mostly for radiosity.

edit: it seems that some cleanup i've done a couple of days ago weren't that innocent regarding kd-tree compilation times; it's definitely faster... so i guess i need to find a way to burn all those saved cycles.

(L) [2006/02/06] [tbp] [Changelog - tbp] Wayback!

Sleep is for wimps.

Tried rule #3 from the MLRTA paper on my compiler and a couple of scenes.

It's not meant to be used in isolation (in fact it antagonize a bit with rule #2), and makes more sense for a renderer that culls faster than it traverses.

It doesn't seem to bring much improvment, and sometimes is a net loss. It requires a bit of tweaking.

On the other hand it's cheap, and makes more sense with fast culling & rule #1 + #2.

end result: as expected, less nodes.

(L) [2006/02/06] [tbp] [Changelog - tbp] Wayback!

With more coffee in my blood, tried a variant.

As it was simpler to plug it there, and without much further thinkage, i initially put that 'microscopic cell pruning' rule into the scoring mix.

But that's not what we're after as another split might be picked that will pass that test but is less optimal than the one we've discarded.

So... it's more like a win-win when that rule takes place once we have a winner.

Still, it needs adjustments and it's not ground breaking.

(L) [2006/02/08] [tbp] [Changelog - tbp] Wayback!

2006-02-08

Backport to msvc8 almost done and versions are synched; i haven't checked for exact output match yet.

OpenMP works now with msvc8 for rendering, the kd-tree compiler would need some surgery and that will wait for a rewrite.

Made some progress with the SSE MLRTA ep search but i'm still a bit puzzled.

(L) [2006/02/25] [tbp] [Changelog - tbp] Wayback!

Life would be very dull without an ever lagging changelog.

2006-02-25

Kd-tree compiler lib mostly done, at least for non-negociable features, gcc/linux port pending. But i still have an horrible bug that made it through 2 consecutive debugging sessions. I don't care, my middle name is 'steel nerves'.

A batch/dispatch thingy shuffling the load among cores/cpu has seen the light and has been ported to win32/linux64, overhead has been kept to a minimum (tho i have nothing to back that claim, note to self: measure it) and now efforts will be put toward educating the rest of the pipeline about NUMAness.

I have evidence showing divergence between trees built on different platforms (old compiler). It's really sad, but pretty hopeless... The newer compiler is supposedly more robust, but that's yet another side of the problem.

People download binaries and then never report back. A remote possibilty is that under undisclosed conditions this program generates black holes.

On that note, have a nice saturday.

Changelog - tbp back