random hemisphere (tlrcam related

[OnoSendai]

There are a couple of problems with reshooting.
a) You will be changing the resulting probability density of reflected rays, so you had better be taking that into account

b) You have to use an arbitrary number of random numbers (well perhaps you could work around this?) which doesn't play nice with MLT etc..

[IanT]

i do that too, except rather than rejecting the path, i reshoot it about 50 times till it works (gets slow and bugy in theory with smoothed ultra reflective surfaces). i might have solved my problem, but i dont think it's solved fully, i realy dont know. its alot harder to tell at this point.

If it fails, you could probably just reflect it around the smoothed normal ... this would guarantee it succeeds the second time (for isotropic BSDFs) but you'd almost certainly need to tweak the pdf (or the radiance) to avoid bias and/or artifacts.

Ian.

[oodmb]

well, i fixed the normal smoothing problem. it turned out to be a UV issue. i also got the cameras working properly so they can render non square images (the x and y were being switched awkwardly somewhere). i added two types of resumes: runtime pause, and start from file resumes. i added a grid texture. also seemed to have fixed the memory leak error.
there are some major scene file changes though


(the normals are still at error in this image)

here is the resulting stuff. its virtually bug free now:

it also includes the compiled .exe

[Kram1032]

very nice
why didn't you add a no-normal-problem scene?

[zsouthboy]

Dude, you're kicking ass.

Keep up the good work

[oodmb]

i just fixed the normal issues today and dont have a picture rendered yet to show anybody
i do have a picture that shades the dot product of the camera against the normal that proves that the normal issue is fixed, but just take my word for it that its fixed.
right now i'm working on adding mlt and getting very mixed very odd results.

[Kram1032]

Ah, I see
So, you have a random-problem, again, I guess?

[Zom-B]

Hey oodmb...

I just tested your little baby.... rendered the ring for over 12 h @ 800x800.
The Problem with your Program is, that for me its "attacking" my computer...

For some reason, My two monitors starts to shut off and on, just if they would change resolution, also the Viewport gets sometimes strange colored boxes like I get on my monitor if my graphic card gets overheated... random Mouse freeze or slow mouse reaction are common too
Everything on process priority of LOW...

While working only on one monitor everything seems to be ok, after activating the second one your prog crashed with a crashlog I attached.

I tried to resume the ring render from the rtlr file, but my computer first freezed and then restarted...

[oodmb]

is that using the java version or the compiled version, because i've also been noticing alot of bugs in the compiled version that dont exist in the java version, although nothing quite like that. i can't seem to figure out whether your computer is a dual core or not from that error file. it seems to me from that error file that the problems are more with java than with my program. if you did have dual core, were you running it in dual core mode?

one of the problems might be that the render sample threads run just under maximum priority, the other might be that i use thread deaths in the code which is a depreciated method(probably for good reasons).

do you think you could also post the rtlr?

[Zom-B]

I used the Java version on my dual core in 2 threads mode, get the rtrl file here.

[oodmb]

well, right off the bat i can tell you that i too have been having issues with dual core computers and multiple threads (odly enough having multiple threads on single core ht computers seems to speed things up a bit). another problem will be that some of my methods are not yet thread safe. yet another problem is that i dont think java is letting the threads be spread out between the cores, it might just be taking advantage of a single core for the app and the other core for the java stuff, which obviously would probably suck when you have two threads running on the same core both max capacity without thread safeyness and without ht. the other problem because you said you have screens could just be some odd issue with the graphics card and java.

[IanT]

yet another problem is that i dont think java is letting the threads be spread out between the cores, it might just be taking advantage of a single core for the app and the other core for the java stuff, which obviously would probably suck when you have two threads running on the same core both max capacity without thread safeyness and without ht.

This won't be the problem (with any JVM less than 3 years old). It will be one of:

- the methods in the core ray-tracing loop aren't thread-safe (as you already suspected)
- too many synchronized methods in the core loop. In theory, the only synchronized methods you'll need will be those that add samples to the image. With care, you can even get rid of these

EDIT to respond to:

(odly enough having multiple threads on single core ht computers seems to speed things up a bit).

Hyperthreading effectively gives you dual-core for integer operations, so most rendering code will benefit from HT as well as true dual-core (but obviously not to the same extent)

Ian.

[eman7613]

A.) what jre do you have installed?
b.) is it a JIT or just a wrapper?

[oodmb]

i got MLT working! precedence doesn't quite work yet and i'd be carefull when putting two refractive materials within each other, but other than that, it seems to work. rays are still re-shot in glossy materials. i'm currently working on another method that doesn't even allow rays to be shot below the normal. i also took out the code that decides the importance of the threads, i'm not sure how well threads would work with the mlt anyway. i havent yet got the resume to work with MLT. there is also a new tag in the scene file that specifies use of MLT: sample metro

here is a new image of some caustics, note that the caustics might not be bright enough because the render of this picture lacked compensation for the probability that the ray might end without hitting the light.

[OnoSendai]

Congratz!