3delight setup/usage?

Takeo.Kensei

The 3delight manual of course. Was at p110 sorry

The passage mentioning caustic shadeop

You need a "sample" parameter so that the renderer knows which quality you want to extract from the map. Without you'd get only one sample. Either it is called sample or estimator doesn't change the nature of the thing. And I'm sure that's more or less what is implemented inside DS

* Taken from 3delight manual

float caustic ( point P; vector N )
This shadeop performs a lookup in the caustic photon map that belongs to the surface being
shaded at the surface location described by (P, N). This shadeop can be written using the
photonmap() shadeop:
Chapter 6: The Shading Language 110
color caustic( point P, normal N )
{
uniform float estimator = 50;
uniform string causticmap = "";
attribute( "photon:causticmap", causticmap );
attribute( "photon:estimator", estimator );
color c = 0;
if( causticmap!="" )
{
c = photonmap(
causticmap, P, N,
"lookuptype", "irradiance",
"estimator", estimator );
}
return c;
}

stem_athome

Takeo.Kensei said:

The 3delight manual of course. Was at p110 sorry

The passage mentioning caustic shadeopBut that is the "Caustic() shadeop" as written using the "Photonmap() shadeop". It specifically states that under that example you show:- "Table 6.14: caustic() shadeop implementation using the photonmap() shadeop"

You need a "sample" parameter so that the renderer knows which quality you want to extract from the map. Without you'd get only one sample. Either it is called sample or estimator doesn't change the nature of the thing. And I'm sure that's more or less what is implemented inside DS

"Samples" and "Estimator" or not the same.

I think the main problem/confusion is due to implementation. (I am not even sure if the photon maps are actually being used)

When using "Indirect light (camera)", it will use ray_tracing for indirect light calculations. But that means an high number of samples are usually needed for good results. The more samples, the better quality of output. (as with you earlier example of samples). So a bad result means adding more samples.
With Photon mapping, the trace is already done and the results are in the photon map. Poor results would normally mean there are too few photons, or not enough photons have been checked to compute good irradiance/radiance smooth coverage. So you would increase the number of photons and/or increase the number of photons taken into account for irradiance/radiance calculations. The number of photons used for irradiance/radiance calculations is defined by the "Estimator". By default, that is 50.

Now, if I have a scene, with "indirect light (camera)" + "Photon mapping (camera)", and set the "photon count" to 1(one) and then render, where are the calculations coming from for the indirect light? Certainly not from a photon map containing one photon. The result of such a render can be quite bad unless you increase the number of samples. But when increasing the number of samples, those samples are being used to calculate indirect light via ray_tracing, not from a photon map of one photon. So even with a photon map of one photon, you can get a good result if you use enough samples.

I have made many tests, but all lead to the same issue of having to use many samples when they should not be needed with photon map available (does not matter if I use 1 or 10,000,000 photons, even in a small enclosed space).

Takeo.Kensei

I'll stop there

Good luck

Mustakettu85

Steve athome said:

When using "Indirect light (camera)", it will use ray_tracing for indirect light calculations.

Shadeop indirectdiffuse() will always use ray tracing for the single final bounce to the EYE (camera). If the RIB says to do more bounces, it will query the surfaces and, if it sees a "global" photon map attached to it, it will query it for all the other bounces.

Steve athome said:

indirectdiffuse() (for photonmapping) is only a way to automatically query photon maps for secondary bounces (3delight doc 7.4.2.1). It will only be accessing photon maps for radiance, which is not enough for smooth shadows unless lots of samples are used.

We don't know _how_ exactly it accesses those maps. Evidently there _is_ some additional filtering of sorts going on.

But again, how much is "lots of samples"?

If anything, I generally use about 64 samples - but with my trace()-based GI shader (for the raytracer + diffuse raycache scenario). But I'm the sort that a) does not mind a bit of noise; b) uses delta lights for direct lighting.

Unfortunately, I personally have left GI-oriented photon mapping behind. I know it works, but I find raytraced GI with caching easier to work with. So I really can't help you further with intricacies of setting up photon GI.

although I am not sure yet how to use gather() in DS as gather() it is a construct.

Just like any other function in the shading language. I'm sorry I don't know if it's doable via Shader Mixer. I just feed RSL code to Shader _Builder_.
There's a tutorial in my freebie thread (link in my signature) where I use 3Delight's Envlight2.sl as an example of how to import RSL code into DS via the Builder. Envlight2 uses gather() to sample an HDRI map and get nice shadows.

But trace() will do the same thing (and more!) without that much coding effort. Here's a snippet of code (it's inside a light so it uses Ps - shading point at surface):

returnGI = trace(
        Ps, Nn,
        "raytype", "diffuse", 
        "distribution", "cosine",
        "samples", samples,
        "maxdist", maxdist, 
        "environment:map", envmap,
        "environment:tint", envcolour,
        "environment:space", envspace,
        "hitmode", "shader"
     );

Basically... that's that. Gets you indirect bounces and HDRI dome lighting with cute soft directional shadows where rays don't hit geometry. "Maxdist" controls how far the shader actually traces before calling the environment map. The rest of the shader is variable declaration etc.

PS It is indeed a wise decision to leave indirectdiffuse() behind. Another wise decision would be to forget about Shader Mixer, too. The Builder is much more robust, and the source code is always there for you.
And, well, RSL coding is a nice skill that will get you places.