Problem with texture filtering and calling shader

[corey]

Hi Guys,

I writing a shader for the purpose of blending 2 objects together (hair cards in this instance).
It works by sending a single probe ray in the reverse normal direction and then grabs the normals and uvs from the surface it hits then calls the material.

This is all working fine, except in the case where I have a texture with filtering enabled. It ends up blurring the texture more then it should and I'm having trouble figuring out how to correct it.

Attached is a image to demonstrate the issue, as you can see, it works fine with filtering disabled.

example.jpg

[bart]

How are you grabbing the info off of the bg element? Filtering should affect the texture, not the uvs.

And if you pull the texture info during the call to the bg material, make sure all the screen projection related state is set up correctly. Ie, for the bg object, not the fg object.

For debugging this, have you turned off filtering on your fg object while it is still on in your bg object? Or is there no lookup, just a transfer of info from the bg object?

[corey]

Here's the code for what I'm doing currently, as you said there's probably some screen related state that I'm not setting up correctly, but I'm unsure what that might be. The bg object is just a simple shader with a color texture, and the fg object is executing the following:

//Copy uv coordinates
state->tex_list[0] = state->child->tex_list[0];

//Call child material
miTag orig_mat = state->material;
state->material = state->child->material;
mi_call_material(&mat_result, state);
state->material = orig_mat;

There is only the 1 texture on the bg object.

[bart]

ok, you are calling the material as if it is at your fg intersection, rather than as if it is at your bg intersection.Ie, you are putting this material into, and using, the state at this fg intersection.

Wouldn't you rather want to call the material at the bg intersection point, and then use that color?

Somewhere in this forum is an example of how to setup to call a child shader correctly, perhaps a zap post.

As I think through it more, I need to know more about what exactly is attached to the bg object material? How much more than just a texture lookup.

[corey]

ok, you are calling the material as if it is at your fg intersection, rather than as if it is at your bg intersection.Ie, you are putting this material into, and using, the state at this fg intersection.

Wouldn't you rather want to call the material at the bg intersection point, and then use that color?

I don't think so, the purpose of this shader is just to make it look like these hair planes are smoothly extruding off the surface below. They still cast shadows and ao etc, but it just needs to blend the shader below, with another shader - in this case its just black. So it should just be a case of modifying the uvs and normals - which is working aside from the filtering.

Somewhere in this forum is an example of how to setup to call a child shader correctly, perhaps a zap post.

As I think through it more, I need to know more about what exactly is attached to the bg object material? How much more than just a texture lookup.

Its just a basic material shader with a colour texture at the moment. But I've found something interesting, if I scale the uv's of the fg object to match the scale in relation to the bg object, the filtering looks correct. How can this be since I am overwriting the uvs anyway?

[corey]

Just to note - I get the same issue if I attach the bg material to my shader and call it using mi_call_shader_x

[bart]

Have you tried to use mi_call_shader_x on the child state? ie state->child

The uvs are the interpolated uvs for the interesection point. But a lot more than that is required for understanding how to filter a texture. The filter size depends on how much uvs move across the geometry as projected in screen space.

Again, which texture lookup are you using?

[bart]

And make sure to re-read the doc for mi_trace_probe for setting up a shader call at hit point. Noting specifically, "..., that the state→child data returned from mi_trace_probe may be incomplete, it does not contain any interpolated vectors for tex_list,bump_x_list, bump_y_list, and derivs."

That means the tex_list has to be set up using mi_tri_vectors to interpolate for the hit point.

[bart]

Actually, mi_tri_vectors is now deprecated, and instead there are now mi_query calls. In the doc, under mi_query, which I find easiest to locate by using the Index, under the mi_* calls index, look for miQ_pri_* query codes.

Texture filtering using ray differentials relies on state->pri for its lookup of positions and texture coordinates. So that has to be set to point to the correct object you wish to use for texture filtering. You cannot override state->pri, so you need to ensure you are using the correct state corresponding to the intersection point, whether that is your initial point or the one the probe ray hits, in state->child which would use state->child->pri.

[gunter]

Corey, we could take a look if you could send us the scene + shaders. The setup in your picture looks
ok, it should work in principle.