3delight setup/usage?

stem_athome

Hi,

I have been having a few issues and hoping someone may help or point me in the right direction?

I am new to attempting to set up a full scene in DS, and certainly I have not started with the simplest. I am attempting to render the inside of a vault (no windows/openings), so have been trying to setup indirect light.

I wanted to use my own mesh as light source. Looking through the online help, I found I should use an "area light" brick as surface on my mesh , so added that and made test render. There where no shadows. So checked the surface setting and changed the "Shadow" color to black. On making render, there was no light. It appears that changing the shadow color changes the light intensity. So black shadow color, no light. I did find a "Shadow" brick, and attaching that to the shadow input of the "Area light" brick, which did then enable shadows.

But that confuses me, as should the "Area light" shadow setting not change the shadow color(not the light intensity) without the need for a further input?

I then wanted indirect light. The info I found in the online help led me to believe I should add an "Indirect light[camera]". After adding the camera, the render was washed out due to the default camera headlamp. I could find no information concerning how to remove/disable that light. I did find that I had 2 choices, I could add a default light, and hide it/turn it off, or add one of the area lights from content, remove that light and use the "Headlamp blocker" that loaded with it.
So I then made test render, but found that even thought the light on the camera was now set as blocked by the "Headlight blocker", the light from the headlight was reflecting in a wall opposite the camera. I did at first think it was a reflection from an object in scene, but after many various checks, it was certainly the light from the camera headlight being reflected.

Is there not a way to completely remove the camera headlight? (It appears that light is also exported into the.rib file)

So, I gave up on that. I looked at the "UberEnviroment2" lighting in conjunction with its area lights. The results did not show the camera headlight reflection, but the render was very slow. I did make many tests/tweaks to settings, but to get a reasonable result would of taken about 4 hours render time.

So I decided to look at 3delight standalone, which when importing the exported .rib file from DS, did render with the same quality and long render times. But as 3delight was using the same settings etc as in DS, I had to look further.

I installed the trial version of "Softimage" and used the "3Delight_softimage_plugin". I setup the scene, added a light and rendered. I got better quality ouput and the scene rendered in 7 minutes.(I did get an error from 3Delight that I was using an unsupported light, so it changed it to a disk, but the result was still what was expected).

So I can only presume that there is something wrong with the implementation DS has made, or I am using the settings/options incorrectly.(I have spent approx 12 hours changing the scene/settings/option etc, so not a lack of trying to get it set correctly, after all, it is only one light)

So what I am looking for is more information about the implementation and what the various bricks are actually supposed to do. There is little to no information in the online help, and the majority of links to information on this forum go to the old forum archive which is offline.

Thanks,

Mattymanx

There are many factors that affect render times. Surface settings, light settings, camera (if not the default) and advanced render options.

I recently did an image using the Area Light and UberEnvironment. I had many surfaces emitting light and my settings for the final render were very high. I rendered at 1920x1080 and it took 6.5 hours. I cannot show the image yet as it contains content that is not yet available. For test renders of the image I used progressive rendering as that will show me the overall image a lot faster. Though I have found from my own use that its slower in the long run for the final image.

stem_athome

Hi Mattymanx,

Thank you for the reply.

I am getting the distinct impression that the "Indirect light[camera] > Samples" are not being correctly applied to scene when using the Reyes engine(DS default), and so forcing the use of a lower shading rate to achieve a reasonable render result (which of course increases render times). The Path tracing(Progressive) engine does appear to use those samples.

I will need to check further.

Mustakettu85

Steve athome said:

Hi,

But that confuses me, as should the "Area light" shadow setting not change the shadow color(not the light intensity) without the need for a further input?

Well, the Shader Mixer bricks tend to have their kind of mysterious ways =) That's the way it is right now, you will need to add the "Shadows-Standard" to any SMixer light brick, if you want shadows.

However, as far as I could determine, Shader Mixer area lights with shadows tend to render slower at equivalent quality settings than using pre-compiled UberAreaLight shader with shadows (probably the one you called "one of the area lights from content" - they _are_ different).

If you are familiar with RSL (Renderman shading language), you could also add transmission()-based shadows to (a yet another) dzAreaLight shader in Shader Builder.

I then wanted indirect light...

So, I gave up on that. I looked at the "UberEnviroment2" lighting in conjunction with its area lights. The results did not show the camera headlight reflection, but the render was very slow.

There is a way to make the render with UE2-based GI faster, if you don't mind some work setting up "scripted rendering". I did a sort of a micro-tutorial on this here:
http://www.daz3d.com/forums/discussion/21611/P570/#650631

Right now, this method does not support atmosphere shaders (the ones like fog, attached to cameras), though.

stem_athome

Hi Mustakettu85,

Thanks for the reply,

Mustakettu85 said:

Well, the Shader Mixer bricks tend to have their kind of mysterious ways

There is something certainly amiss.

I spent a few more hours trying to get better results with my scene, but finding a need to either add excessive amounts of Indirect light samples(to the Indirect light[camera]") or lower the shading rate well below one. Both make rendering times too long.

So I started again. Same scene, with daz area light and "Indirect light[camera]. On some base settings that I thought should be OK, the render was far too noisy. (render time 1min 43 sec).
I looked at adding a "photon mapper[camera]" to the "Indirect light[camera]", the docs state that is for color bleed, with makes no sense to me, I would expect it should be adding photons for Indirect light. But after adding the "photon mapper[camera]", 3delight errors of:-

No light casting photons
dzglobalmap not found
shader_indirect_camera_on object

Render time 3min 47sec. Although the errors, the render was improved, but not usable(still too noisy).

So I exported the scene to a .rib file., in the .rib file I edited the area light to emit photons. I then rendered in 3delight studio(free version), I got a good usable render in 2min 25sec

I have now been looking for a light in DS library that emits photons, but cannot find one. I have looked through the shader mixer, but can find nothing there to enable lights to emit photons. So currently at a loss. I certainly do not want to have to keep exporting to .rib and editing.

So the big question is. How do I get an area light (or any light) in DS to emit photons?

Mustakettu85

'Delta' lights (distant, point, spot) from Shader Mixer will cast photons by default. For other lights, you'll need to add a line to their rendertime scripts - which is only possible with those whose rendertime scripts are not encrypted.

Rendertime scripts and "scripted rendering" are DS specific ways of controlling RIB output regarding RiAttributes, RiOptions etc. TL;DR: if you don't want to edit RIBs manually, you'll have to learn a bit of DAZScript.

If you insist on using Shader Mixer further, there was a rendertime script brick there, too, - although I cannot guarantee it will work.

Either way, if you follow the link from my previous post in this thread, and then the first forum link from there, you will also find a ready-to-use photon mapping kit of mine for download (no Shader Mixer involved). It has a readme detailing installation, usage AND the code to add to rendertime scripts (try that for your Mixer area lights).

Either way, photon mapping for GI in the context of 3Delight is "oldschool", and the devs don't really recommend it anymore. Raytraced GI with GI caching, particularly for complex scenes, will generally be faster.

I'm sorry, I am on the phone now and can't write detailed replies, but in all honesty, you should find a lot of info I already posted on the subject, if you follow the link from my previous post. And the other 'regulars' on that thread (it's like a 3Delight+DS research laboratory =) ) should also be able to help you further.

Takeo.Kensei

Not sure you need photon mapping on area light and from my experience uberarealight does the job with a cornell box

Taken from 3delight manual.

Enable photon map generation for desired lights using Attribute "light"
"emitphotons" ["on"]. Normally, only spot lights, point lights and directional lights
are turned on for photon generation. Light sources that do global illumination work
(such as calling occlusion() or indirectdiffuse()) should not cast photons.

However you can try the following SM network

stem_athome

Mustakettu85 said:

'Delta' lights (distant, point, spot) from Shader Mixer will cast photons by default. For other lights, you'll need to add a line to their rendertime scripts - which is only possible with those whose rendertime scripts are not encrypted. I find that to be a cumbersome way of being forced to work.

Rendertime scripts and "scripted rendering" are DS specific ways of controlling RIB output regarding RiAttributes, RiOptions etc. TL;DR: if you don't want to edit RIBs manually, you'll have to learn a bit of DAZScript.So to access all render settings/options, there is a need to create scripts? Wow, how more convoluted can this get.

Either way, if you follow the link from my previous post in this thread, and then the first forum link from there, you will also find a ready-to-use photon mapping kit of mine for download (no Shader Mixer involved). It has a readme detailing installation, usage AND the code to add to rendertime scripts (try that for your Mixer area lights).

I tried that, followed instructions, and no indirect light.
I exported the scene to .rib, and before looking at the flie I ran it in 3Delight studio, it crashed 3Delight studio with "Fatal Error:- Invalid type for token function (6)"

Either way, photon mapping for GI in the context of 3Delight is "oldschool", and the devs don't really recommend it anymore. Raytraced GI with GI caching, particularly for complex scenes, will generally be faster. Using anything other than photon mapping(when it does work) results in either no indirect light, or a need to use excessive amounts of samples. That of course makes it a long render time. I am starting to understand why I see other users reporting render times of many hours.

From what I am seeing in the 3Delight plugin for XSI, 3Delight is extremely fast, and gives excellent renders in very short time. That is contrary to what I am seeing in DS.

Sorry if that all sounded like a rant, but after spending several days trying to get what should be basic rendering functions to work, I have got nowhere. I will have a break from DS as it is making me lose the will to render.

stem_athome

Takeo.Kensei said:

Not sure you need photon mapping on area light and from my experience uberarealight does the job with a cornell boxIt appears to be using occlusion. I did attempt to use uberarealights, but as before, I found that an excessive amount of samples where needed, making render times excessive.

Taken from 3delight manual.

Enable photon map generation for desired lights using Attribute "light"
"emitphotons" ["on"]. Normally, only spot lights, point lights and directional lights
are turned on for photon generation. Light sources that do global illumination work
(such as calling occlusion() or indirectdiffuse()) should not cast photons.

I have gone through the manual, and through various other resources (such as example "Renderman Shading Guide).
It is not as if I was trying to create a complex scene with complex shaders/lights. It is simple scene with simple shaders and one light. As it is, it would of been quicker manually creating the .rib and running it in 3Delight studio.

However you can try the following SM networkSee previous posts. Have tried that already.

Takeo.Kensei

Steve athome said:

Takeo.Kensei said:

Not sure you need photon mapping on area light and from my experience uberarealight does the job with a cornell box

It appears to be using occlusion. I did attempt to use uberarealights, but as before, I found that an excessive amount of samples where needed, making render times excessive.

No I doubt Uberarealight is using occlusion. You may confond with Uberenvironment

The question is : What do you think excessive sample is?

It works without excessive render time even if slower than if I coded all

Here is an example

Indirect light Camera inside a cube = no light from outside
1 Uberarealight plane with 158 samples
1 indirect light camera with final gather on and 500 000 photons. Other settings attached
Render with maxdepth =4 and final output at gamma 2.2

Rendertime = 4 min 30. And you see the indirect light without the need to have an area light emitting photon

Mustakettu85

Steve athome said:

I find that to be a cumbersome way of being forced to work.
...So to access all render settings/options, there is a need to create scripts? Wow, how more convoluted can this get.

Yes. And yes, it can get way more convoluted. Try figuring out a good algorithm for sticking workable RiIlluminate calls into DS interface. I haven't yet, and I've been at it a long time.

It's not the 3Delight devs who did the 3Delight integration with DS. It would've been as beautiful as their Softimage and Maya integrations, then.

DAZ Studio is a free app with hobbyist-oriented history. This has unfortunate consequences. I feel for you. We're all in the same boat.

This work is what you pay for the free unlimited core 3Delight licence coming with DS.

...I think there was a 3Delight plugin for Blender somewhere - but I don't know how easy it is to use.

I tried that, followed instructions, and no indirect light.

Check:
- installed the scripts (the PhotonMappingTwoPass shows up in the scripted renderer menu);
- installed and compiled the RaytracedGI shader (compiling via Shader _Builder_ tab - and I am sorry for the shader name, duh);
- edited the rendertime script of your chosen light shader or used a ShaderMixer delta light;
- actually added the photon-casting light and the RaytracedGI shader into your scene.
// if you edit a dzLight script, load the light from the content folder! The menu lights are not the same! //

I just downloaded my own kit to a machine I have here (I'm not at home), and it works. See attached renders (sorry for low quality settings, I'm in a hurry - yes the light is on the cylinder, and I left its actual surface dark on purpose).

Here's a custom area light with photons on, used in the render:
https://www.mediafire.com/?hgk16789m5frp12

Throw to:
[USERNAME]\AppData\Roaming\DAZ 3D\Studio4\ShaderBuilder\Shaders\Src\Light\

Compile. Apply from the "Shader Presets/Shader Builder/Light" content folder: there's some sorta bug or whatever with DS that won't let area lights reliably apply from the Shader Builder tab.

I exported the scene to .rib, and before looking at the flie I ran it in 3Delight studio, it crashed 3Delight studio with "Fatal Error:- Invalid type for token function (6)"

An unfortunate side effect of DAZ's example render script (the basis for every other one), which does DS "default display call".

Very few people export to RIB in the DS world (and those who do, usually do it to edit them manually), so I didn't bother figuring out how to correct the script to generate "perfect RIB".

How to fix manually:

- Find the Display call in the RIB and delete the next line, with the word "function". Save. Renders fine in the standalone, although throws warnings about being unable to write buckets to DS's driver. The "50thousand" photons render is fresh from the standalone.

Oh and BTW, the script won't do "collect and localise", so keep DS open so as not to flush its temp dir (the RIB links to textures already there).

Using anything other than photon mapping(when it does work) results in either no indirect light, or a need to use excessive amounts of samples.

Or a need, again, to make two little intertwined scripts (make once, use forever) that call the GI cache option and the raytrace hider in 3Delight (and forget all about photons unless you're into caustics). I am rendering this way; Kevin Sanderson successfully followed my notes and even did a short GI _animation_.

TL;DR: a lot of things can be done even despite the clunky DAZ Studio scripting. But yes, it's not particularly user-friendly.

Takeo.Kensei

I'll add that it also works with Uberenvironment in indirect light mode

Same scene 10 min with 256 samples on both light without indirect camera (so without photons)

[Edit] UE settings attached.

stem_athome

Hi Takeo.Kensei,

Takeo.Kensei said:

No I doubt Uberarealight is using occlusion. You may confond with UberenvironmentYes, I was thinking of Uberenvironment.

The question is : What do you think excessive sample is?

With photon mapping >32 (majority of work is to create good photon map coverage). With path_tracing, depending on scene, I do not normally (with other renderers) find a need to exceed 64.

Indirect light Camera inside a cube = no light from outside
1 Uberarealight plane with 158 samples
1 indirect light camera with final gather on and 500 000 photons. Other settings attached
Render with maxdepth =4 and final output at gamma 2.2

Rendertime = 4 min 30. And you see the indirect light without the need to have an area light emitting photon Using only a Uberarealight plane with photon mapping, 3Delight error, stating no light emitting photons. Exporting to .rib. The light has no attribute as emitting or not emitting photons. Exporting(as .rib) the light on its own, it is set as not emitting photons.
I did change the lights attributes so it would emit photons in a test scene, but the result was the same. So I would (at this time) say it is best used without a photon map.

stem_athome

Hi Mustakettu85,

Mustakettu85 said:

...I think there was a 3Delight plugin for Blender somewhere - but I don't know how easy it is to use.I only found one for Blender 2.5. The same plugin had been hacked/updated to work with later versions(2.6 I think), but decided not to look at it.

Here's a custom area light with photons on, used in the render:

That gave me a really bad render (due to my settings/geometry) and with that, quite a lot of insight as to what 3Delight is doing. Many thanks for that.

.................and forget all about photons unless you're into caustics....................In 3Delight, you are probably right. I do want to experiment more with it in 3Delight, if only out of curiosity.

I have had a number of "Ah" and "D`oh" moments with this today, and now (some possible bugs aside) getting good usable results quickly. I now need to read through that thread you linked to (and dig out some books I have on RSL).

Takeo.Kensei

Steve athome said:

The question is : What do you think excessive sample is?

With photon mapping >32 (majority of work is to create good photon map coverage). With path_tracing, depending on scene, I do not normally (with other renderers) find a need to exceed 64.

I don't know what path tracer you used but 64 is pretty low. And you're not using a path tracer here

A good number is at least 128 and go up 256 if not more to get something good enough

stem_athome

Takeo.Kensei said:

I don't know what path tracer you used but 64 is pretty low. And you're not using a path tracer here

A good number is at least 128 and go up 256 if not more to get something good enough

I have no need for such high settings as I do not render complex surfaces such as skin(sss), I do not render characters etc, just hard surface simple materials.

stem_athome

Mustakettu85 said:

There is a way to make the render with UE2-based GI faster, if you don't mind some work setting up "scripted rendering". I did a sort of a micro-tutorial on this here:

I have just found time to try that. Looking very good.
My current test scene, the render time had increased to 15min due to added lights/geometry. Using that scripted rendering (after a few tweaks to surface materials) is down to 3min 32 sec.

Many thanks.

Takeo.Kensei

Steve athome said:

Takeo.Kensei said:

I don't know what path tracer you used but 64 is pretty low. And you're not using a path tracer here

A good number is at least 128 and go up 256 if not more to get something good enough

I have no need for such high settings as I do not render complex surfaces such as skin(sss), I do not render characters etc, just hard surface simple materials.

FYI just basic surfaces

stem_athome

Takeo.Kensei said:

FYI just basic surfaces

So you show me an example of basic surface material of unspecified settings, on a low polygon sphere, in a scene of infinite size, with a light source at unspecified distance / intensity /size, with shadows created how (map/trace)? with indirect light yes/no?. Sorry I find it difficult to take your example seriously. Simply throwing more and more samples at a render to increase quality without taking into consideration all other aspects of scene is not something I do.

I admit, at this time I know next to nothing of 3Delight. I am still confused as to the output render quality differences (with same sample settings) from DS and the plugin to XSI. Maybe that is down to material optimization or implementation?

I gave attached quick renders of a sphere. Rendered in Yafaray (I use that renderer mainly for direct light / AO renders and Photon mapping)
one is photon mapping. Area light with 16 samples. Indirect light(final gather) at 16 samples.
The other is Pathtracing. Area light with 16 samples. Path samples 4, depth 2

Mustakettu85

Steve athome said:

Many thanks.

You're most welcome!

In addition to your RSL books, a lot of viable examples for contemporary 3Delight shading is found in the shader sources for their plugins (3Delight Studio Pro includes a Maya plugin which you can install even if you have no Maya, and then in the 3Delight/Maya/RSL folder you will have .h source files to consult when writing your stuff; the Softimage one must also have sources somewhere). Also this post by Paolo Berto Durante on their official forums (and his other posts, too):
http://www.3delight.com/en/modules/PunBB/viewtopic.php?id=3932

stem_athome

Hi Mustakettu85,

I have been looking more into 3Delight.

Mustakettu85 said:

Either way, photon mapping for GI in the context of 3Delight is "oldschool", and the devs don't really recommend it anymore. Raytraced GI with GI caching, particularly for complex scenes, will generally be faster.

Yes, I have been looking at Photon_mapping again.
From what I see, the devs may well call photon mapping "old school", but it looks more a case that they never bothered to fully implement the ability to render full GI via photon mapping, only the minimal once bounce indirect light, but even that is lacking due to using the photon map directly.
The process of photon mapping full GI is to "create photon map > Create irradiance/radiance map > create KDtree > render (as with Yafaray)." That process in PRman is (according to documentation) similar (create photon map > create irradiance map via ptfilter > Create brickmap(tree) via brickmake), but those tools to follow that process are missing/unavailable in 3delight.
Looking through the 3delight forums, a post from developer stated that photon mapping would be introduced (back in 2009), but it appears that for multi bounce GI, they would be/are using a mix of photon mapping and point based graphics.

Looking more, I find that (probably) the way to go, is to bake out maps (Bake3d), but it looks like a need to create/place code within materials (looks like what XSI is doing with 3delight). So I will look at that rather than photon mapping.

Up to now, I have been finding many things "not to do". So eventually I will find "what to do" LOL.

Mustakettu85

Steve athome said:

The process of photon mapping full GI is to "create photon map > Create irradiance/radiance map > create KDtree > render (as with Yafaray)." That process in PRman is (according to documentation) similar (create photon map > create irradiance map via ptfilter > Create brickmap(tree) via brickmake), but those tools to follow that process are missing/unavailable in 3delight.

They just do a lot of things differently from PRMan devs (their style appears to be to streamline a lot of things and "hide" a lot of extraneous operations from the user). With GI photon mapping in 3Delight, the indirectdiffuse() shadeop should be handling all the steps towards "final gather" on the fly, but since 3Delight is closed-source, there's no way to find out what it does exactly.
UPD: compare indirectdiffuse() to photonmap(): the latter shadeop is the one that uses the map as-is; indirectdiffuse() does a lot of "something" behind the scenes.

However, photon mapping (via indirectdiffuse() shadeop) works okay for multiple bounces, unless memory fails me.

Looking through the 3delight forums, a post from developer stated that photon mapping would be introduced (back in 2009), but it appears that for multi bounce GI, they would be/are using a mix of photon mapping and point based graphics.

Point-based technique is a yet another way to get GI, and there is even a sturdy script supplied with DS (it's called "Point-based occlusion" but if you use the UberEnvironment2 light shader set to "Bounce light" instead of AO, it will do PB GI). You can study the script's source code to understand how to set up multiple render passes within the confines of DS (there is a pre-compiled shader using the bake3d() shadeop hidden there in the DS installation somewhere - the "Point-based Occlusion" script first overrides all the materials with it, writes out the point cloud to DS's temp dir - you can ptcview it from there - and in the beauty pass it hands the name of the point cloud to the UE2 shader that does the rest).

Takeo wrote some useful things about using this script in this thread: http://www.daz3d.com/forums/discussion/44460/

But point-based technique is the one limited to a single bounce.

Takeo.Kensei

@Steve : as much as I like Yafaray, it is not the same beast as 3delight and the purpose of their authors is quite not the same. Yafaray is quite unique in the way it works

About multiple bounce GI there is an interresting post in 3delight forum

http://www.3delight.com/en/modules/PunBB/viewtopic.php?id=2732

stem_athome

Mustakettu85 said:

They just do a lot of things differently from PRMan devs (their style appears to be to streamline a lot of things and "hide" a lot of extraneous operations from the user). With GI photon mapping in 3Delight, the indirectdiffuse() shadeop should be handling all the steps towards "final gather" on the fly, but since 3Delight is closed-source, there's no way to find out what it does exactly.
UPD: compare indirectdiffuse() to photonmap(): the latter shadeop is the one that uses the map as-is; indirectdiffuse() does a lot of "something" behind the scenes.

However, photon mapping (via indirectdiffuse() shadeop) works okay for multiple bounces, unless memory fails me.

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. It is why I was looking for a way to convert the photon_maps/radiance to tree(brick_maps). But as it is not there, I will need to look more for alternative.

I was looking more at what XSI is doing, but after it bakes maps (from surface) it is using internal(not accessible) algorithms to complete the render (for both RAYES and Path).

As it is now, I will move away from indirectdiffuse(), and look at trace() and gather() (although I am not sure yet how to use gather() in DS as gather() it is a construct. ).

stem_athome

Takeo.Kensei said:

@Steve : as much as I like Yafaray, it is not the same beast as 3delight and the purpose of their authors is quite not the same. Yafaray is quite unique in the way it works

I still have one attempt left at photon mapping in DS/3deleight.
From the use of "Indirect light (camera) and "Photon mapper (camera)", the photon map is generated and then the use of (I presume) indirectdiffuse(). But I am curious as to not seeing the use of, or at least settings for, the "photonmap shadeop". So I want to see results, when that shadeop is added (with non-default settings) to the photonmap process.

About multiple bounce GI there is an interresting post in 3delight forum

http://www.3delight.com/en/modules/PunBB/viewtopic.php?id=2732

Considering that thread is over 3 years old, the question would be as to if any implementation as been made?

Takeo.Kensei

Steve athome said:

Takeo.Kensei said:

@Steve : as much as I like Yafaray, it is not the same beast as 3delight and the purpose of their authors is quite not the same. Yafaray is quite unique in the way it works

I still have one attempt left at photon mapping in DS/3deleight.
From the use of "Indirect light (camera) and "Photon mapper (camera)", the photon map is generated and then the use of (I presume) indirectdiffuse(). But I am curious as to not seeing the use of, or at least settings for, the "photonmap shadeop". So I want to see results, when that shadeop is added (with non-default settings) to the photonmap process.

If you looked at the DAZ tutorials on advanced shading they implemented caustics with a DS Shader Mixer material.
https://www.youtube.com/watch?v=FwCHxSTlOQo
https://www.youtube.com/watch?v=Rfk8J25hmCc

The caustic are made internally with a shadeop call to the caustic() function (that is what I believe cause that seems logical)

From that tutorial you can do something similar for your purpose

About multiple bounce GI there is an interresting post in 3delight forum

http://www.3delight.com/en/modules/PunBB/viewtopic.php?id=2732

Considering that thread is over 3 years old, the question would be as to if any implementation as been made?

I didn't see any product but implementing the Method 2 with Point Cloud after generating a photon map should be doable inside DS

stem_athome

Takeo.Kensei said:

If you looked at the DAZ tutorials on advanced shading they implemented caustics with a DS Shader Mixer material.
https://www.youtube.com/watch?v=FwCHxSTlOQo
https://www.youtube.com/watch?v=Rfk8J25hmCc

The caustic are made internally with a shadeop call to the caustic() function (that is what I believe cause that seems logical)

From that tutorial you can do something similar for your purposeI do not see the use of/settings of the "photonmap shadeop" in those vids. If the "photonmap shadeop" was used, there should be available settings for "Estimator (number of photons used for lookup)", "LookupType (irradiance or radiance)" and if irradiance type lookup "Mindepth (minimum number of bounces for a photon to be considered in irradiance computation).
I know there is the "Final gather" on the "Indirect light (camera)", but I do not know what that is doing/using, as I do not know what that brick contains. Is there a way to see inside that brick?

I didn't see any product but implementing the Method 2 with Point Cloud after generating a photon map should be doable inside DS

I am not at all sure about that process. (feeding photonmap results into a point cloud).
Yes it is mentioned on that old thread, but have not seen anything yet that makes me think such a process is available/possible.

Takeo.Kensei

In the video and the shader used, it is a call to the caustic() shadeop; not photonmap().

From the caustic brick I can say the Estimator was named Sample and the lookup type is certainly irradiance...quite logic

The mindepth is in the indirect camera parameter

What you have in the manual is not necessary implemented or implemented with the same name

You can't see what's inside a brick. You can only guess

2°./ Trust me that is doable but that need some programming

stem_athome

Takeo.Kensei said:

In the video and the shader used, it is a call to the caustic() shadeop; not photonmap(). I do not see that.
The "Caustic shadeop" is a lookup:- "float caustic ( point P; Vector N )". Although it can be written using the photonmap shadeop.

From the caustic brick I can say the Estimator was named Sample and the lookup type is certainly irradiance...quite logicIf it is a caustic shader or caustic shadeop, it will not have an "Estimator", only the "photonmap shadeop" has the "Estimator". It is not the same as samples.

What you have in the manual is not necessary implemented or implemented with the same name

Seriously? So what reference should I be using if I cannot refer to 3delight docs and the DAZ docs are badly incomplete?

You can't see what's inside a brick. You can only guess LOL

Takeo.Kensei

Steve athome said:

Takeo.Kensei said:

In the video and the shader used, it is a call to the caustic() shadeop; not photonmap(). I do not see that.
The "Caustic shadeop" is a lookup:- "float caustic ( point P; Vector N )". Although it can be written using the photonmap shadeop.

From the caustic brick I can say the Estimator was named Sample and the lookup type is certainly irradiance...quite logicIf it is a caustic shader or caustic shadeop, it will not have an "Estimator", only the "photonmap shadeop" has the "Estimator". It is not the same as samples.

Read Manual P 117 and tell me there is no estimator again.
And I already wrote some shaders and made test to compare. So I'm pretty sure

What you have in the manual is not necessary implemented or implemented with the same name

Seriously? So what reference should I be using if I cannot refer to 3delight docs and the DAZ docs are badly incomplete? You can complain to DAZ for the lack of doc but you won't be the first

stem_athome

Takeo.Kensei said:

Read Manual P 117 and tell me there is no estimator again.

Which manual?

The 3delight manual PDF page 117 is info concerning ray_tracing. (part of section "Message passing and Information"). I see no mention of "Estimator" in that section.

The DAZ user guide PDF only goes to page 96

If you are looking at the 3delight manual(PDF), then have a look at page 106-107. That shows the "caustic() shadeop", and its implementation using the photonmap() shadeop