2 parameters one shader?

[athomas]

let's say I have a wooden fence, now I want to assign the same shader to each pole, but have each pole use different parameters.

Basically just like [mattr ....] in prman and Maya. Is there a way whereby I can create, lets say 'grain' parameter and have it vary with user input on a pole basis, or a string parameter whereby each pole gets a different texture map based on user specification.

I like to do this without creating seperate objects for each pole, keeping everything in one object.

Cheers

Andre

[AndrewVK]

You can overwrite any shader parameter with help of

AttributeCreate SOP.

Just set:

Name -> shader parameter name (!!!real name but not label!!!)

Class: Primitive

Type -> should match shader parameter type

Value: hmmm...something $PR based.

[AndrewVK]

for example...

1 shader -> 5 map

example.zip

[athomas]

Thanks for that, but not quite what I had in mind.

I know how I can randomly place texture, but what I want to achieve is, is say the first pole has texture #1, pole 2 has tex #5, pole 3 tex #2, and so on specified by the parameter in SOP's through user input.

Or lets say it's wood the first pole's ringfreq. should be 10 the next one 20, the third one 5, whatever the user specifies within the parameter.

The problem is when creating parameter 'ringfreq' in SOP's and passing this along to VEX I can not have different values for the same parameter unless it's applied to different objects (Object Level).

See the attached file as one example using ringfreq, it could also be a tex map.

Cheers

Andre

test.zip

[AndrewVK]

>>The problem is when creating parameter 'ringfreq' in SOP's and passing

>>this along to VEX I can not have different values for the same parameter

>>unless it's applied to different objects (Object Level).

Cannot get what is the problem .

sorry because my english is not so fluent.

Check attacment.

paramcontrol.zip

[athomas]

Can't step into your subnet?

I'm using 6.0, that maybe the problem

[AndrewVK]

Ooops. Sorry H6.1.200 file

[tallkien]

Why not use point instancing

Create a path (If its a pickety fence) with any number of point Attributes and use AttribCreate to define a custom vm_surface (pointAttrib) using the other attributes you created to control ringfreq or whatever. not sure how you'd create the custom control panel, subnet maybe

Your pole will just be geometry with uv's and should pick up the texture from the point

[Mario Marengo]

Thanks for that, but not quite what I had in mind.

I know how I can randomly place texture, but what I want to achieve is, is say the first pole has texture #1, pole 2 has tex #5, pole 3 tex #2, and so on specified by the parameter in SOP's through user input.

Or lets say it's wood the first pole's ringfreq. should be 10 the next one 20, the third one 5, whatever the user specifies within the parameter.

Hey Andre,

Couple of little "oops!"-kind'a things in your hip that might have been throwing you off:

1) You had placed the intended value of each attribute in the Size field of the AttribCreate sops. This field is used to define the size of the data type (i.e: vectors are size=3, floats are size=1, etc.). To set the actual value of the attribute use the Value field.

2) Your grids are polygonal. This means that the "raw" parametric values (st) will run [0-1] on each polygon -- not over the entire grid. To fix this, you can either change the grid geo to a parametric type (mesh, NURB, etc), or add your own UV mapping. I didn't want to change your geo so I added a couple of UVTexture sops for ortho UVs. And a "ShadingLayerParameter" VOP (what a name!) was added to bring them into your shop.

3) The Wood subnet has a "LightingModel" vop embedded. This means that in order to see anything you need to light it. Your light was placed directly above the two grids, which are themselves aligned to the XY plane -- meaning that you were getting exactly zero light intensity falling on their surface. So I moved the light to a place where it can light the grids.

Here's your hip with those fixes. You basically had all the bits right -- but, as usual, the devil is in the details

[Mario Marengo]

LOL!

I guess that, in keeping with the spirit of things, it's only appropriate that I would forget to add the attachment!

...and here's me trying to add an attachment to this message, and likely screwing it up... :

test_fix.zip

[athomas]

Thanks All and you especially Mario,

shall have a look at this ones finished with my SSS test. (Bloody details I tell ya)

BTW, just been going over your SSS implementation posts from the SESI board, have you done any more work on this.

I've started firstly using the bruteforce approach, gotta say some rather interesting results.

Do you know if the 'gather' and 'ray labelling' have been implemented in the last releases?

Cheers

Andre

[athomas]

Ok, just looked at your fix file and don't get anything, the grids aren't getting shaded at all.

What am I missing?

[Mario Marengo]

BTW, just been going over your SSS implementation posts from the SESI board, have you done any more work on this.

Yes... although at the stunning rate of about 1hr/week...

I'm doing the Jensen thang on my own time, and so I've gotten the green light from Axyz to post to the forums -- which is something I fully intend to do, in all it's gory detail!

However; work-and-life-in-general (that's one word, btw) have slowed things down a *lot*. Coupled with the fact that to do it properly, there are a lot of little details to deal with (the devil again ) -- it's a long way from what Hery has made public (including the last Siggraph notes) to an actual ready-for-production version.

Having said that, I'm about 98% of the way there, and the C++ stuff needed to support some of the table-generation has grown to a few dozen files.... a little more time, and it will all be at a forum near you

One thing I'm debating is whether I should do a full techie write-up going over all the implementation details, or just put it up and "have a nice day"? Would there be people interested in the guts of it all?

Do you know if the 'gather' and 'ray labelling' have been implemented in the last releases?

Not as far as I know.... must check on that !

[athomas]

Hey Mario,

Would there be people interested in the guts of it all?

Well I can't speak for everybody, but I'm certainly would be more then interested.

Well got to go now, (Friday night, beer and family are waiting)

Andre

PS. For the SSS transfer I've used the trace call instead of gather and getraylevel for my rayinfo.

I know its not perfect, but is a step closer.

[Mario Marengo]

Ok, just looked at your fix file and don't get anything, the grids aren't getting shaded at all.

What am I missing?

Huh?!

Here's what I see:

... and I downloaded the hip from the attachment in my post... [H 6.1.200]

version problems?

PS. For the SSS transfer I've used the trace call instead of gather and getraylevel for my rayinfo.

I know its not perfect, but is a step closer.

Interesting; would love to hear more about that

I decided to implement the shadowmap approach fully and work out all the math in that mode first; then hopefully move on to the "point-cloud" approach.

Although, I gotta tell ya, the shadowmap thing works well for single scatter, but not so good for multiple scatter. It also ends up doing *tonnes* of redundant calculations... I'm convinced that "point-cloud" is the way to go there; but, I want to finish the shadowmap version first....

Cheers!

[athomas]

Mario,

Yep version problems, we're on 6.0 at the moment.

As for my SSS aproach, well I basically started of with the prman notes and used the first (brute_force) approach. I've only substituted raylabel with getraylevel so I can test the current depth.

Next I used trace instead of gather, other then that just the normal RSL - VEX conversion, well it's certainly working. Now I'm trying to take it from here to optimize the shader and try to come up with a solution that doesn't include raytracing. Haven't started yet on Hery's paper.

Cheers

Andre

[Mario Marengo]

Hey Andre,

Mario,

Yep version problems, we're on 6.0 at the moment.

Ah.. then maybe just change those things I mentioned, and hopefully all should be fine.

As for my SSS aproach, well I basically started of with the prman notes and used the first (brute_force) approach. I've only substituted raylabel with getraylevel so I can test the current depth.

Next I used trace instead of gather, other then that just the normal RSL - VEX conversion, well it's certainly working. Now I'm trying to take it from here to optimize the shader and try to come up with a solution that doesn't include raytracing. Haven't started yet on Hery's paper.

I'm glad to hear that the trace() function is working for you. I haven't used it yet (or its rayhittest() cousin), and had the feeling I might run into weird space problems

I'm guessing you'd need a lot of rays for highly translucent materials -- how's the speed?

Hery's approach is not without problems -- most notably the fact that the underlying assumption is that surfaces are convex. Jensen's approximation *is* a lot faster than a brute-force gather, though; and if you manage to get the sampling right...(!)....can also be artifact-free at all scales. ..."Aye... ere's the rub!"

Of all the time I've spent working on this thing so far, I'd say 95% of it has gone into the land of "importance sampling" and all things to do with Monte Carlo integration.... things that I probably wouldn't need to worry about if using the point-cloud method -- but then I'd probably be worrying about how to get an irradiance cache with all the bits I need in there.... Oh well; it's all good fun, and I'm learning tonnes!

Cheers!

Mario.

[athomas]

Hey Mario,

Ah, speed you ask? Perhaps watching the grass grow might be more interesting, its very slow (even with just 256 samples), but you would expect that.

I'd say 95% of it has gone into the land of "importance sampling"

I know what you mean, same here. Unfortunately I have not been able to achieve visually and speed acceptable results.

but then I'd probably be worrying about how to get an irradiance cache with all the bits I need in there

yes, because of the above mentioned problems I've started looking into this, using Jensen's paper from last year, and I have exactly these worries/problems.

Any tips you may be able to give me?

Cheers

Andre

[Mario Marengo]

Any tips you may be able to give me?

Well; since I've only really looked at the shadowmap (Hery) method, I can only talk about the sampling issues for that approach.

For the single-scatter pass, things are not so bad. You need to cover the volume of the projected patch as evenly as possible. So you need two distributions, one along the 2D patch (dPdu/dPdv), and one along Wo' (the refracted projection into the object). The importance sampling on the depth-projection is "built-in" since you're already using the inverse CDF to get the distance ( -log(RN)/sigma_t ). And along the dPdu[dv] plane you can use just about anything that is even -- I've tried a few different approaches there: halton, sobol, poisson-disk, and stratified.

The important thing there is that you want a somewhat static (deterministic) distribution that doesn't exhibit artifacts (grid-like patterns or "bands") when things get *really* translucent and you start undersampling. So far, I'm gravitating towards a jittered stratified dist for the plane and a sot-of "shifted" halton for the depth (the sequence progressively shifts on every sample).

For the diffuse scatter, Hery uses a Mitchell distribution, which is perfectly fine..... except ...

In the form of a lookup table (which it *has* to be since it's so slow to compute) and after the inv-CDF weighing, you end up with a table that's really good for a *very* narrow set of material parameters and object scales. So; good for showing the method, but nowhere near good enough for actual production implementation. Again; lot's of things I've tried (am trying) here; and to be honest, haven't come up with a "best" choice yet. My best candidate so far is to keep the *unweighted* Mitchell dist as a table and do the ICDF weighing in the shader (it's cheap if you use yet another table). Then I couple this with splitting the Mitchell dist into multiple concentric "bands" of equal area, which I then access in "center-out" order and so impose a kind of stratified sampling of the Mitchell dist. All of which can then be rescaled (adapt) to maximize the number of "hits" according to the scattering coefficients (the "translucency " of the material)..... details, details

Cheers!

Mario.