Mustakettu85's "EnvLight2" help needed

Esemwy

I've done my best to follow the instructions from ShareCG "Alternative Image-Based Lighting in DAZ Studio using 3Delight ”envlight2” shader" by Mustakettu85, but to no avail.

for reference, the tutorial I'm following is from here:
http://www.sharecg.com/v/52437/get_file.pdf

I've worked at it for hours, and all I've managed to accomplish is blank silhouettes (i.e. nothing). I've set __nondiffuse to 0, so that's not the problem. I've tried it with and without __nonspecular connected. I've used JPG, HDR, and TIF files from UberEnvironment2 for my environment map. Nothing works. I'm sure it's something simple I'm missing, but I just can't see it.

Attached are my shader network, the user parameters, and the envlight2 brick parameters. Any help would be greatly appreciated.

Mustakettu85

I have just run a quick check - incidentally it's a new machine again (where I work they drop like flies...), so a brand new installation of 3Delight standalone and DS - and everything should work.

I don´t see anything wrong about your user parameters.

But there is something about your envlight2 block inputs that puzzles me. All the defaults are set at 0.0, regardless of the type; the input parameters are not initialised as uniform; which is strange. Because the parser should be picking up the default settings of the .sl source and produce something like the attached image by default.

Which makes me think that the code did not import itself properly, and here lies the problem.

Is there actually any code in the macro editor? And if there is, does the "Evaluation" tab say "Cl"?

If there is something wrong about the macro, you should try re-importing the source again. It should come in with the inputs initialised as uniforms, and the defaults being assigned the same values as in the original code. Something like the attached image. Then, once you get the inputs connected to the user parameters and load an HDR, everything should be OK.

PS: I now have an "official" freebie thread on these forums here - http://www.daz3d.com/forums/discussion/42984/P15/

Esemwy

Well, I posted a lengthy reply here last night, but it apparently went astray.

I went back and checked the source file. DAZ did in fact fail to pick up the default values. I tried starting over (again), but the defaults aren't populated and all the types are marked as default instead of uniform (whatever that means). I went ahead and fixed all that in the macro block editor and verified that the initialization code and evaluation code are correct (as far as I can tell; it compiles anyway).

After the most recent attempts, I went back and looked at the DS log file.
---------
Loaded image OmKHPark_EnvM.hdr
Ran tdlmake on image /Users/Shared/My DAZ 3D Library/Runtime/Textures/omnifreaker/Environment/OmKHPark_EnvM.hdr
Rendering Image
3Delight message #3 (Severity 2): T2040: 'XXXXX/Library/Application Support/DAZ 3D/Studio4/temp/d8_OmKHPark_EnvM.tdl.env' not found (in shader 'ShaderBuilder/Light/EnvLight2' on object 'shapematerial_Default_147_92')
Saved image: XXXXX/Library/Application Support/DAZ 3D/Studio4/temp/render/r.png
Finished Rendering
---------

I'm thinking a failure to read the converted environment light might result in less than perfect results. The interesting thing is that the file was created, but doesn't have a .tdl.env extension, but just .tdl.

I've got no idea at this point.

Mustakettu85

If it cannot find the environment map, then it will render black, it´s a given.

Try changing the type of the envmap variable to "texture" instead of "environment" (in both user params and macro inputs) and see if it helps?

And you may also want to check access rights in your OS - I don´t know which one you're running, but it's just that your paths don't look like the paths familiar to me (I only have experience with Windows).

What I mean is that on Windows, all these extra extensions somehow don't matter. I've seen tdlmake create an ".tdl.tdl.tdl.tdl.tdl" file, and it worked.

Esemwy

As you suspected, I am not running Windows. I run OS X here. I only use Windows in my day job for running viruses. ;-)

Changing it to a texture keeps it from complaining, as does changing it to a string.

The original function prototype looks like:

light envlight2(
color light_color = 1;
float Kenv = 1.0;
float Kocc = 0.0;
string envmap = "", envspace = "world";
float samples = 64;
float maxdist = 1e10;
float bias = -1;
string __category = "";
float __nonspecular = 1; )

I'll start fresh again tonight when I get done with my day job.

Mustakettu85

Yes, in RSL proper there are no "texture" or "environment" types; map names are just strings. This is something DS-specific and is likely to be connected with the way DS calls the tdlmake utility.

Esemwy

It turns out that there is a bug in the shader code. The first several lines of the Initialization Code read:

{
uniform string raytype="";
rayinfo( "type", raytype );

uniform string gather_cat = concat("environment:", envmap);
vector envdir = 0;
color envcolor = 0;
float solidangle = 0;

The line that reads "envcolor = 0"? That value never changes, and it's used in the gather statement. It makes to product for every point on the environment map come out 0. Hard coding it to 1 made everything work, although I suspect the correct thing is to initialize it to 'light_color'. So what I ended up with was:

{
uniform string raytype="";
rayinfo( "type", raytype );

uniform string gather_cat = concat("environment:", envmap);
vector envdir = 0;
color envcolor = %1%;
float solidangle = 0;

I'm not sure what envdir and solidangle do in this context, but I'm suspicious of them. I'll understand them better when I know what gather actually does.

Stay tuned.

Mustakettu85

To tell the truth, it's quite weird that initialising the "envcolor" variable with the value of "light_color" was the thing that made it work for you.

You see, it is actually a perfectly legit way to init a variable, by assigning a zero value to it, when you know that it will _always_ have a meaningful non-zero value assigned later in the code.

The full syntax for using gather() in 3Delight can be found here (while 3Delight is Renderman-compatible, it has always been sort of Renderman-extended, to be more precise, so it's always best to refer to the DNA guys' own docs and forums):

http://www.3delight.com/en/uploads/docs/3delight/3delight_32.html (scroll down for the "The gather Construct " heading)

If we look at the documentation and then at the code,

 gather(
      gather_cat, 0, 0, 0, samples,
      "environment:color", envcolor,
      "ray:direction", raydir,
      "environment:direction", envdir,
      "environment:solidangle", solidangle )

we see there is no bug in the actual source - gather() outputs its results in the "envcolor" variable (among others). So it doesn't really matter what we init the variable with, as long as gather() is fed an environment map to importance-sample.

The thing is - I used the shader as-is on numerous Windows machines, and there were a few other people who reported their success. Given that Windows users seem to be in the majority, we could assume they were running Windows too... while you are not.

So the issue must be something about either the Shader Builder in the Mac build of DS or the "shaderdl" compiler utility in the DS-specific Mac build of 3Delight.

Let's do one more thing... Could you please test your edited shader with a few different HDR maps now? They should produce _different_ lighting and shadows. If they all wind up the same - it means gather() is being interpreted the wrong way.

Esemwy

I had to go off and find some more environment maps. The only HDR from UberEnvironment2 that would render bright enough was OmHKPark_EnvM, which is what I've been testing with.

The result is, it's working, but now I don't know what we finally did to get it working. Even switching the envmap back to an environment from a string, and it keeps working, although I'm not getting that tdlmake error any more.

It's definitely taking colors from the environment. If I render using a sunset, my white sphere becomes orange, and when I render with a seascape, the sphere takes on an aqua cast.

My guess is that I had more than one thing wrong initially, and as you helped me understand the settings, I finally got them corrected all at the same time, and the variable I thought meant something and changed was just a coincidence. I think the last thing I did before that was to look at the original shader file and make my default values match the exact format of what was there. But there again, the only change is that light color was now set to 1 instead of color "rgb" ( 1,1,1 ), which as I understand it means the same thing.

Here's my test renders with the intensity pumped up to 200%.

For now it's an engineering mystery.

Mustakettu85

Those spheres look good =) Have you tested with a plane underneath them to see shadows?

And you can set the intensity to way higher than 200% (just change the max limit in the user parameters). Somehow, yeah, a lot of HDR maps come in very different brightness levels, so you may need to have intensity all the way up to 1000% for some.

HDR lighting works best when you enable gamma correction and set gamma to 2.2 (that gets the linear output of the renderer into the non-linear colour space of the monitor). Then intensity can be lower.

Esemwy

And now I'm getting the "can't find .tdl.env" file again. It's obviously a bug somewhere.

Mustakettu85

Good grief! I'm very sorry. I am afraid you should file a bug report with DAZ, then.

mjc1016

It's a caching problem, not a shader problem.

Somewhere along the line your temp file, where the *.env file lives is being cleared OR there is a NEW env file being generated (like if you change the gamma...you should have some-hdri.tdl.env...then change it again and it should generate a some-hdri.tdl.env.env) and the corresponding 'update' isn't being tracked. Many times problems like this are OS related...specifically read/write permissions to various folders being used for the temp files.

The easiest way around...save the scene, shut down DS, restart, reload...then tdlmake will generate (optimizing images line when starting a render) a new set of maps.

Also, I've found it best to decouple (use a different name) for the Intensity/Kenv variable. Simply because, depending on the HDR map, you could be setting the intensity as high as 1000%, which if they are couple/the same will totally wash out the scene (of course if Preview Lights is off, it doesn't really matter).

Esemwy

mjc1016,

You're correct. There is a cacheing problem. It doesn't seem to be my permissions, though, unless DAZ is mangling/resetting them itself, which I suppose is possible. But, it's working again this morning, so I can't check...

Mustakettu85,

I had a chance to test shadows this morning. They don't work. Black scene.

Mustakettu85

Esemwy, I do believe you should file a bug report about it, since it's definitely DS that does weird things (it's the same link as any other help request: https://helpdaz.zendesk.com/requests/new ).

Esemwy

I was going to do it last night, but got caught up in the script I was writing.

The failure to load the environment map is intermittent, so I don't expect any sort of timely resolution.

My fear is I'll get the same response as last time I submitted something hard.

Sorry for the trouble using the tdl make utility. Unfortunately we do not support content creation and related question. I recommend that you post your question to the forums as we have quite a few experienced users and the developers who frequent the forums.

This was in response to a question about the confusingly documented -skymap functionality in tdlmake.

I have to grab the message from our dA conversation, but I'll give it a shot.

Mustakettu85

Oh, I thought I was the only DS user using -skymap in tdlmake! =D

You know, the "hardcore" 3Delight-specific questions (particularly those dealing with its utilities, and not just rendering stuff) are best asked at the 3Delight forums (or in the "laboratory" thread here where our "geek squad" generally hangs out) - after all, 3Delight is developed by a completely different team:

http://www.3delight.com/en/modules/forum/
www.daz3d.com/forums/discussion/21611/P960/

But when it comes to actual bugs in actual DAZ-developed software, DAZ are trying to do their best to minimise them. They just need to know about them.

FG3D

I apologize if I ask a question about such an old post, I hope there is someone who will give me an answer.
I tried following this tutorial and everything works perfectly except the known coordinate problem.
Uber Environment 2 also has the same problem which cannot be solved by the code because the source code is not available.
But envlight2.sl is available, so the question is:
How can I change (via code) the coordinates so that it avoids rotating the shader by setting x = -90 and then doing the horizontal flip of the map with a software like Photoshop? (this is the method I normally use when working with UberEnv2)
Thanks in advance
Maurizio

Sven Dullah

FG3D said:

I apologize if I ask a question about such an old post, I hope there is someone who will give me an answer.
I tried following this tutorial and everything works perfectly except the known coordinate problem.
Uber Environment 2 also has the same problem which cannot be solved by the code because the source code is not available.
But envlight2.sl is available, so the question is:
How can I change (via code) the coordinates so that it avoids rotating the shader by setting x = -90 and then doing the horizontal flip of the map with a software like Photoshop? (this is the method I normally use when working with UberEnv2)
Thanks in advance
Maurizio

You could try asking in this thread if you didn't find a solution already.

FG3D

Sven Dullah said:

You could try asking in this thread if you didn't find a solution already.

Thanks for the suggestion