random hemisphere (tlrcam related

[IanT]

Excellent progress

I'm not sure why you'd have a problem multi-threading MLT though ... it lends itself very well to parallelism (as long as your core ray tracing methods a thread-safe to begin with). About the only considerations are:

- using Atomic numbers (AtomicLong, AtomicInteger) for mutation counts and other useful statistics
- making sure you use an usynchronized random number generator and give each MLT thread a separate one to avoid clashes

I'll be open-sourcing Radium in the near future so you'll be able to have a look at that

Ian.

[oodmb]

well, its not that there is a bug with threading and MLT, its just that i havent yet configured MLT to work with threads yet. i'm still fairly new to threads anyway and i have no idea what atomiclong and atomicinteger are. the random number generator that i'm using is strictmath, but that shouldnt be my problem.

[filippo]

I have some question...i
scene format?
t's possible to add light?
can I set parameter?
filippo

I love new render engine

sorry for my poor language

[oodmb]

yah, its easy. you add light by giving a mesh an emiter material:
the higher the luminance of the emiter colour, the brighter the light.

m
glow
emit
15.95 15.99 15.98
}

[oodmb]

1200 mutations. its alot closer to converging, but now its got me wondering just how many mutations it will need to converge.

[Kram1032]

looks great
I wonder, how different your code is from Onos (besides Optimisation) as your radiosity effect is far strong that his...

[IanT]

1200 mutations. its alot closer to converging, but now its got me wondering just how many mutations it will need to converge.

How many mutations/second are you seeing and on what kind of PC? Also, various MLT paramaters are crucial to achieving fast convergence (max change, large step probability etc ... I assume you're using a mutation strategy based on Kelemen's paper?)

Echo Kram's comment ... the GI looks way too strong. The white walls should be mostly white with just a hint of colour bleed from the coloured walls (this effect should be more pronounced on the ceiling, but nowhere else).

Still, amazed by your progress so far...

Ian.

[oodmb]

yah, i agree. i think the problem is with how i'm compensating for the probability a chain will end, as the result looks much better in the image that did not have compensation:



i think might be able to deal with the caustics not being bright enough in that image by changing how the emitter's power works. it might also possibly work better if i change to code to be specraly based rather than color based, although thats alot larger of a modification.

[oodmb]

i'm working on a mac right now and i must say that i'm realy suprized that the open and save file stuff still works. also, its realy alot more fun watching the scene converge on a mac for some reason than it is on a windows.

[IanT]

i think might be able to deal with the caustics not being bright enough in that image by changing how the emitter's power works.

Ah yeh, I remember scratching my head over this one.

Solution I picked in the end was to assume that the "colour" defined for the emitter represents the total power of any emitter it is assigned to. This means that the power per unit squared (as used in implicit path terminations, e.g. caustic path) is "colour"/A (where A is the emitter surface area). The total power (when calculating direct light irradiance for example) is simply "colour".

This approach avoids problems when assigning the same emitter BSDF to different emitters.

Ian.

[IanT]

i'm working on a mac right now and i must say that i'm realy suprized that the open and save file stuff still works. also

The joys of Java

Apple also implemented some Mac-specific Swing properties to make Java GUI apps look even more Mac-like (e.g. making a frame's menu bar appear on the main Mac menu bar, rather than contained in the frame). I'll dig these out at some point and post if you're interested.

Ian.

[oodmb]

wouldnt that mean that for a caustic path, the colour from the light would be less than a colour returned from a direct calculation? if if thats the case, then wouldnt the colour of the caustic on the screen be not as great?

[IanT]

wouldnt that mean that for a caustic path, the colour from the light would be less than a colour returned from a direct calculation? if if thats the case, then wouldnt the colour of the caustic on the screen be not as great?

The value for direct light irradiance at point P (per the above example) is...

"colour of emitter" * cosL * cosN / d2

where:

cosL is the cosine of the angle between the normal at the emitter point and the direction to P
cosN is the cosine of the angle between the surface normal at P and the direction to the emitter point
d2 is the squared distance between P and the emitter point

...which basically results in most direct light calculations being much lower than the associated caustics (because d2 is usually quite large).

Ian.

[oodmb]

the majority of the problem seems to lie it two areas
A:
the equation i was using for the direct lighting was

Code: Select all

 double dd = d.dot(d);
      
double mm = (atHit.now.normal.dot(d)) * - (lumpatch.normal.dot(d)) *
                   (1 / (dd*dd* lumpatch.time));

where d was not normalized. fixed it now reads:

Code: Select all

Vector3 df=d.normalized();
double mm = (atHit.now.normal.dot(df)) * - (lumpatch.normal.dot(df)) *
              (1 / (lumpatch.time* lumpatch.time));

i was also assuming that the dimensions of the scene didn't effect the output picture as it is like in biased rendering which apparently was a wrong.

[filippo]

there is a txt file to unterstud the render engine?
file format?
parameter...ecc
filippo

sorry for poor language