Trace() Command? - Githubissues

Do we have a trace() command in OSL?
The documentation seems to suggest so: pages 59, 60 (Documentation Date: 28 
October, 2009)
But it's not mentioned explicitly anywhere.

Why do I need it?

The projection shader currently has a 'Projection_Self_Shadow' option which if 
ON does a quick self occlusion 
test via AiTraceProbe().
Imagine a torus getting an image projected from the side and the user gets a 
choice of whether the projection 
should only show on the outer surfce (i.e. first surface hit by projection) or 
on all consecutive surfaces within 
the projection frustrum (i.e. also show up in the 'hole').

The projection shader traces back from P to the projection origin and tests for 
'same object' (comparing sg-
>Op, sg->proc and sg->parent). Not foolproof but lacking a 'same shader' test 
via AiTraceProbe the second 
best option. Does the job mostly.

If trace() no longer exists do you have a suggestion on how to implement this 
feature in OSL?
(And perhaps remove all 'traces' from the documentation.)

11/03/09 16:39:40 changed by lg 

Yeah, that seems like a pretty compelling case, the equivalent of how we use 
volume shadows for ppaint.

<edit>

So I think we will need some kind of ray-traced occlusion check.

The trick is to try to use it very sparingly, because any kind of "immediate" 
ray tracing will be much more 
expensive than the tracing that we can batch up and reorder.

11/03/09 16:44:57 changed by jschlag 

why not use the closure mechanism? in the occlusion() case, certainly. for 
projections, the operation can still 
be postponed until closures are computed, yes?

11/03/09 16:47:02 changed by aconty 

Related to this, for things like aotumatic dirt, we can in fact think of 
occlusion tests that do not involve 
raytracing: Approximate ambient occlusion in blender

11/03/09 16:53:32 changed by lg 

...  we don't really support generalized closures, only linear combinations of 
lighting functions.

(follow-up: ↓ 9 ) 11/03/09 16:57:45 changed by lg 

The problem is that you have something like this:

    occ = occlusion (...);
    Ctex = mix (Cbase, texture(...), occ);
    Ci = Ctex*diffuse();
If occ is a closure, then so is Ctex, and then Ci is trying to multiply two 
closures together, which is not 
allowed.

(in reply to: ↑ 7 ; follow-up: ↓ 13 ) 11/03/09 17:01:26 changed by aconty 

Replying to lg:

If occ is a closure, then so is Ctex, and then Ci is trying to multiply two 
closures together, which is not 
allowed.

Yes, if you want to support that kind of shading we need tools for probing the 
environment. Not for light 
calculations of course. That should be done by the integrator. But it would 
make sense to get information 
about surounding objects, distances and so. With as less raytracing as possible.

(follow-up: ↓ 12 ) 11/03/09 17:02:57 changed by abauer 

The overall idea here really is to have a means to probe the environment so the 
shader can use the gathered 
information.

In the simplest case this could be just occlusion for e.g. a dirt shader.
But ultimately trace() should be able to gather any information from shaders of 
objects hit to allow to create 
tools/effects like e.g. 'ray painting' on Disney's Bolt.
http://www.awn.com/articles/production/digital-eye-how-ibolti-got-painterly

The use of trace() here is not about emitting light.

(in reply to: ↑ 10 ; follow-up: ↓ 15 ) 11/03/09 17:07:36 changed by lg 

Replying to abauer:

The use of trace() here is not about emitting light.

It certainly is, if its results change the amount of light leaving the surface.

(in reply to: ↑ 9 ) 11/03/09 17:09:19 changed by lg 

Replying to aconty:

Yes, if you want to support that kind of shading we need tools for probing the 
environment. Not for light 
calculations of course. That should be done by the integrator. But it would 
make sense to get information 
about surounding objects, distances and so. With as less raytracing as possible.

Yes, exactly. We need to have this (even with ray tracing). It's too useful. 
But we have to make it clear that it 
may be expensive.

The use of trace() here is not about emitting light.

It certainly is, if its results change the amount of light leaving the surface.

Well, but I think Andreas want to use it for something different. I wouldn't 
mind some responsible use of 
evironment information as long as it is not view dependant.

(in reply to: ↑ 15 ; follow-up: ↓ 22 ) 11/03/09 17:11:39 changed by lg 

Replying to aconty:

Well, but I think Andreas want to use it for something different. I wouldn't 
mind some responsible use of 
evironment information as long as it is not view dependant.

We're on the same page on this. I'm just saying, "it's not used for light" 
doesn't make the problem go away, in 
no small part because we still are talking about using it to change the way 
light leaves the surface, thus if it 
were a closure you'd get into various semantic troubles.

But back on topic:

Is environment probing something OSL won't support?

And are there any good ideas on how I could implement the feature in the 
current version of OSL?
Or is the consensus that this feature from the projection shader will have to 
be dropped from the OSL 
version?

(in reply to: ↑ 18 ) 11/03/09 19:22:13 changed by lg 

Replying to abauer:

Which is why I always copy/paste the text into another text document for 
safekeeping, before I cut my ties, 
and then copy/paste back from the safekeeping document.
An extra step, and hence even more pain, but all worth it in the end!

Good tip. Indeed, sometimes I remember to open an edit window, paste in there 
for safe keeping. But 90% of 
the time all works just fine, so I often forget the extra step. It's always the 
one time I forget that all my work 
gets lost! And it's always when I've written a long, detailed explanation, 
never a one-liner!

(in reply to: ↑ 19 ) 11/03/09 19:23:24 changed by lg 

Replying to abauer:

But back on topic: Is environment probing something OSL won't support? And are 
there any good ideas on 
how I could implement the feature in the current version of OSL?
Or is the consensus that this feature from the projection shader will have to 
be dropped from the OSL 
version?

No, I think the gist of this thread is that we will at the very least support 
some kind of occlusion probing. 
Certainly for what the projection shader needs, we should be able to 
accommodate you.

(in reply to: ↑ 16 ) 11/04/09 08:54:06 changed by aconty 

Replying to lg:

We're on the same page on this. I'm just saying, "it's not used for light" 
doesn't make the problem go away, in 
no small part because we still are talking about using it to change the way 
light leaves the surface, thus if it 
were a closure you'd get into various semantic troubles.

Not a closure of course. Just an occlusion check function like

  float occlusion(point P, vector N)
That can then be used to modulate a texture that later is used for weighting a 
closure. Would that make 
sense?

11/04/09 09:38:19 changed by abauer 

The projection shader needs to test for self-occlusion, not occlusion in 
general.
It needs information back from the hit object. Ideally a 'shader ID' to compare 
against its own shader ID.

In lack of that a way to identify 'same object' as the ray originating object.
This is the method currently used comparing sg->Op, sg->proc and sg->parent of 
originating and hit 
object.

As a last resort mere occlusion could be sufficient if it provides a 
'maxdistance' option for the ray length plus 
an 'angle' option to narrow the probing occlusion 'hemisphere' to just N itself.

In the example from Bolt I mentioned above the probing rays returned the 
opacity from the objects hit.
What's ultimately desired is to query any output or input parameter value from 
the shader on the hit object.

11/04/09 09:44:23 changed by aconty 

Of course, for the projection thing you need something specific. The occlusion 
I was suggesting was for 
different issues. Just as an example of environment probing we may need.

11/13/09 15:33:43 changed by lg 

milestone changed from lookdev first look to lookdev start / open source 
release.
11/13/09 15:54:52 changed by jschlag 

i encourage us to keep to the high road here as long as possible. the real 
issue is ray scheduling. closures() 
are a partial implementation of that concept, but not the whole deal. i suggest 
a clarification to the 
terminology along the lines of "a closure is a special case of an X", where X 
is "deferred operator" or some 
such.

that being said, the particular case of projection shaders is solvable in 
different ways.

ppaint, e.g., cannot rely on ray-tracing for this operation because the 
geometry on which the projection was 
set up may not be available. Ptex / animating / deforming geometry all make 
this difficult or impossible. sad 
to say, the solution is depth maps.

interestingly, this intersects with the tactic of ray packets. if you're 
shading a packet of rays, and a trace() 
shadeop chucks a packet's worth of rays towards the map projector, that *is* a 
trivial form of ray scheduling. 
but probably not the best you could do.

another way to look at it is, provide the trace() op, but what it means is: 
you're making a request that rays be 
chucked *at* the surface (not *from* the surface) from the projector, to be 
made available at the time the 
shader runs, along with the incident rays. this leaves scheduling entirely in 
the hands of the renderer. what we 
do not want is people chucking rays about whenever, and dragging back into 
80's-era r-t.

sorry to blather a bit. my interest is in seeing us with the most outrageously 
fast and capable renderer in the 
biz.
Original issue reported on code.google.com by rene.lim...@gmail.com on 11 Jan 2010 at 6:40
h3rb / openshadinglanguage

Trace() Command? #21
