FINALY AVAILABLE!

http://people.brandeis.edu/~mirman/

yay- 4000 spp

I fixed boolean opperations, and I have a webpage.

http://people.brandeis.edu/~mirman/

anybody who can, can yall try to open tlrcam's jar and see if you can read the source?

at 900 spp.

i ran some tests and found that path tracing runs at about 8000 mps on this image, and mlt/this runs at 7000 mps. not as big a difference over the long run as i though. it means i can stop trying to optimize it as much.

Problem: both mlt, this, and path tracing start out rendering at about 30000 mps, then go on to an average of 20000 mps for about 5 miniutes, (the warm up ends after about 1 miniute), and then finally jumps down to below 10000 mps. I have no idea why it is doing this.
ideas: Java's garbage collector not acting up...
mt random number generator something
memory leak.
no clue.

Any ideas?

More from the new MLT algorithm

I improved it a little, and it seems to work fairly well. Now all I need is an importer, to blender or some other program, and I will open source it- well, possibly with a copyright so I can prove that I wrote it, something like PBRT has.- all except for the new MLT code, which I'd prefer to keep a secret a bit longer.

Now tell me, is this an improvment worth pursuing? Or should I go ahead and implement the paper on adaptive multi-dimensional sampling that seems to show such great improvements (does anybody know of any renderers that use this?)

Regular path tracing- 300 spp- this was the first time i tried to benchmark it without eclipse being open and me doing stuff. on my 1.9ghz core 2 duo, with 2 threads, on vista 64, i was getting an average of 10000 mps

The image after 315 spp, I'm not going to say how long this took because it was only on one core and was rendered while I was using my computer intensively.

The new algorithm after 20spp, at about 10 minutes on a dual core. -Lprob .01-.99 -maxRej 10-1000

the regular MLT algorithm with 20spp at about 10 miniutes, with an -Lprob .4 and maxrej of 500

the regular image's lprob and maxrej was set to be what the new algorithm's lprob and maxrej would average out to given thoes paremeters and scene. All MLT is based off of Keleman et al.'s robust mutation strategy paper, and paper on hybrid MLT.

stratisfied sampling+MLT

I haven't found any papers on this subject exactly, but I had an idea (and hopefully if there is nothing out there, I can write my own paper). What I seem to have had the most trouble with in MLT was to sample uniformly(as uniformly as possible) every direction at a bounce, where applicable.  The trouble is, it is very hard to keep track of where MLT has sampled previously, and what it should do next/how it should do it next.  What I have done is essentially modified the balance heuristic in order to sample every pixel as evenly as possible

, and sample every direction as evenly as possible.  This only required slight modification to my path tracer, and does not introduce any bias.  There are numerous other subtleties, but I'd rather not go over all of them, because if It is a unique idea/implementation, I could write a paper on it, which would be nice.

With the modified balance heuristic at 51 spp at about 20 miniutes:

        

without the modification at 81 spp at about 30 miniutes:

High Dynamic Range lighting

I have the preliminary HDRI implemented, i just want to do it now with more than one sort of map (lat/long)

Now I have insane amounts of work to do, so I will not be able to post anything else for a while.

Updates

that previous pic had a bug in it, a bug that happened to make it look way cooler than it should have (and take longer to render)

here is the less cool but bug less image.

I still have to reimplemented virtually all my materials and SSS, but I've decided, after noticing that with some fixes it runs about 1/4 to 1/2 the speed of indigo that my renderer is not completely horrible. when i had the bug that made the image look cool, I realized that all I needed was to spend some time making making cooler scenes for it to render. Well, i'm not going to do that. I currently have no time to do it, and a kinda lame importer, not to mention like no materials as of now. Instead, what i'm going to do is to fix my thin lense camera to work with bidi, add hdri and add bloom. probably on the way, add a shader or two, because i've finally decided upon a material system and it should be easy to do now.

Another idea I've been contemplating is writing a shader that should be able to read user defined shaders and produce corrosponding sampling sets. I'm sure this has been done before, I even remember reading parts of the paper. But I don't have the paper, so I'll just figure it out when I want to.

speed and rings

well, i did some behind the scene stuff with the tracing code, and took away a linked list that i was using (the algorithm was easier to implement that way in the beginning), and now its about 3-10 times as quick. Its now running at 30000 samps/s

this image was taken after about 6 hours and 2000 muts/pixel. I feel as though I've made so much progress in the past 2 weeks)

All Better

Fixed a bug in the MLT code, now there are no magic squares on the walls.

I still want to learn to implement latin hypercube stratified sampling with the MLT, and Haltron and the likes. I'm thinking about giving up all hopes of simple pathtracing and making this a pure MLT+-bidirectional renderer. i figure i can use the same geometry, scene, and visual core in order to add regular path tracing capiabilities one day. the added simplicity would make it much easier to implement lots of MLT specific optimizations.

There is also the possibility that i might abandon all hopes of this being a usefull renderer, and make it super unbiased (polarization, spectra, quantum properties of light... double slit...)

In other news, I've been reqruited to make my renderer suitable for animations. there are many reasons other than speed that I'm ignoring that would make my renderer useless for animations. The reason I agreed was because i had an idea that if i applied MLT directly to the animation sequence, the most relevant parts of the sequence would render first, and each image would be equaly rendered. My delta sampling could also be applied with respect to time so that that artifacts cause the animation to be less fuzzy.

I have way too many ideas and way too little time to try them all. Its sad.