Date   

Re: Review: fix derivatives of mod()

Larry Gritz <l...@...>
 

On Jan 15, 2010, at 8:54 PM, Jonathan Gibbs wrote:
Well, I'm not sure what to think. The derivatives of mod(x,y) is the
same as x most of the time, but at the discontinuity? Not sure what
else you could really do since the function isn't continuous...

Well, there's "math" and then there's "what's useful in shaders." In the strict mathematical sense, the derivative is undefined at the discontinuity (x==d), though you could speak of the limit as you approach from x<d versus x>d. My guess is going to match at least one of those! I'm not sure what we can do that's any smarter or more useful in a case like this.

--
Larry Gritz
l...@...


Re: Review: fix derivatives of mod()

Jonathan Gibbs <jono...@...>
 

The mod() function was zeroing out derivs. I think it's pretty simple, mod(x,y)
has the same derivs as x, right?
Well, I'm not sure what to think. The derivatives of mod(x,y) is the
same as x most of the time, but at the discontinuity? Not sure what
else you could really do since the function isn't continuous...

--jono

On Fri, Jan 15, 2010 at 8:37 PM, Larry Gritz <l...@...> wrote:
Anybody?


On Jan 14, 2010, at 11:58 AM, Larry Gritz wrote:

http://codereview.appspot.com/189073

Ugh, still having trouble making it send all review emails to this list automatically.
--
Larry Gritz
l...@...





--
You received this message because you are subscribed to the Google Groups "OSL Developers" group.
To post to this group, send email to osl...@....
To unsubscribe from this group, send email to osl...@....
For more options, visit this group at http://groups.google.com/group/osl-dev?hl=en.




Re: Review: fix derivatives of mod()

Larry Gritz <l...@...>
 

Anybody?


On Jan 14, 2010, at 11:58 AM, Larry Gritz wrote:

http://codereview.appspot.com/189073

Ugh, still having trouble making it send all review emails to this list automatically.
--
Larry Gritz
l...@...


Re: Question about BSDFClosure functions

Alex Conty <aco...@...>
 

Great to hear from you, I had no idea you were involved in this
project.
Well, is Larry's baby. I'm in the group that makes the render using
OSL.


I incorrectly interpreted what would actually be given to the
renderer, I thought it would be a single bsdfclosure that somehow
included additions and multiplications, but looking at the source code
more closely, it's a weighted sum of different closures. That leaves
That's right.

importance sampling and other things more to the rendering engine, so
Yeah

that solves my question. I was assuming otherwise because this imposes
a limitation on how you can combine/manipulate closures, but I guess
there's still closures written in OSL that could be used to get around
the limitation.
That's more of a question for Larry. I know osl closures are in the
roadmap, but he is the one to talk to about this.

Alex


Re: Question about BSDFClosure functions

brecht <brechtv...@...>
 

Hey Alejandro!

Great to hear from you, I had no idea you were involved in this
project.

On Jan 14, 6:31 pm, Alex Conty <a...@...> wrote:
I have a question that I couldn't find an answer to in the
documentation or source code. The BSDFClosure has eval_reflect,
eval_transmit and sample functions. Some rendering engines have an
additional function to compute the average reflected or transmitted
color independent of the incoming light direction, by the integrating
the bsdf over the incoming light direction without any lights. In PBRT
for example this function is called rho.
I understand the main use for this is importance sampling. I'm afraid
I'm not allowed to say how we do things here at imageworks, but there
are other ways to do importance sampling. That function would make
things easier, of course, the problem is that not all BSDF's can be
easily integrated. The expensive method is not an option, it would be
overkill. So you need an analytical solution which is not always
available.
I incorrectly interpreted what would actually be given to the
renderer, I thought it would be a single bsdfclosure that somehow
included additions and multiplications, but looking at the source code
more closely, it's a weighted sum of different closures. That leaves
importance sampling and other things more to the rendering engine, so
that solves my question. I was assuming otherwise because this imposes
a limitation on how you can combine/manipulate closures, but I guess
there's still closures written in OSL that could be used to get around
the limitation.

Thanks,
Brecht.


Tickets not in mail list

Larry Gritz <l...@...>
 

In an effort to keep the mail list free of clutter, I think we're deciding NOT to CC the list on every ticket. Instead, those of you who want to follow the gory details of every ticket and every checkin should subscribe to the RSS feed for the project, which will have blurbs for every last ticket comment and checkin.

We're still feeling our way around how this should all work.

--
Larry Gritz
l...@...


Re: Issue 48 in openshadinglanguage: texture() should take optional param for missing texture

openshadi...@...
 

Comment #3 on issue 48 by larrygritz: texture() should take optional param for missing texture
http://code.google.com/p/openshadinglanguage/issues/detail?id=48

Agreed. After I posted that, I was convinced from internal discussion that it needed
to be a shader decision (example: you might want missing color texture to be a
different "average" than a missing displacement amount). And yes, I'm going to make
it a color.


--
You received this message because you are listed in the owner
or CC fields of this issue, or because you starred this issue.
You may adjust your issue notification preferences at:
http://code.google.com/hosting/settings


Re: Issue 48 in openshadinglanguage: texture() should take optional param for missing texture

openshadi...@...
 

Comment #2 on issue 48 by jonogibbs: texture() should take optional param for missing texture
http://code.google.com/p/openshadinglanguage/issues/detail?id=48

I would want a separate color per shader, and would not like 2b. And "fill" is a
float, and I'd not always want the missing color to be greyscale. I would prefer (1).

--
You received this message because you are listed in the owner
or CC fields of this issue, or because you starred this issue.
You may adjust your issue notification preferences at:
http://code.google.com/hosting/settings


Patch crediting

Blair Zajac <bl...@...>
 

Now that OSL is open source (congrats!), I recommend using the following guide on crediting patches from non-core developers in log messages:

https://svn.apache.org/repos/asf/subversion/trunk/www/hacking.html#crediting

You can then use the Contribulyzer to analyze commits to see who you would like to promote to full committers:

http://www.red-bean.com/svnproject/contribulyzer/

See this chapter "Teams and Tools" from the "Beautiful Teams: Inspiring and Cautionary Tales from Veteran Team Leaders" book by Karl Fogel, one of the Subversion founders on the tool and the issues it sovles:

http://www.red-bean.com/kfogel/beautiful-teams/bt-chapter-21.html

Regards,
Blair


Re: Issue 48 in openshadinglanguage: texture() should take optional param for missing texture

openshadi...@...
 

Updates:
Cc: larrygritz
Labels: Type-Enhancement Priority-Medium Milestone-20100210

Comment #1 on issue 48 by larrygritz: texture() should take optional param for missing texture
http://code.google.com/p/openshadinglanguage/issues/detail?id=48

Sample comment (I'm just testing the email)

--
You received this message because you are listed in the owner
or CC fields of this issue, or because you starred this issue.
You may adjust your issue notification preferences at:
http://code.google.com/hosting/settings


Issue 48 in openshadinglanguage: texture() should take optional param for missing texture

openshadi...@...
 

Status: New
Owner: larrygritz
CC: os...@...

New issue 48 by larrygritz: texture() should take optional param for missing texture
http://code.google.com/p/openshadinglanguage/issues/detail?id=48

Currently, texture() lookups to nonexistent textures are an error (that
propagates up to the renderer). The shader team has suggested that it
would solve some awkwardness if there was an optional argument to texture,
somewhat similar to "fill", that gives a color value to use for entirely
missing textures (and it is not an error for this to occur). If the arg is
not supplied, it's an error to ask for texture that is not found.

I can think of a couple ways to do this:

(1) a separate "missing" color that is analogous to "fill" (fill is used
for missing channels in a present texture). Also a "missingalpha" for the
alpha case?

(2) just a bool that means whether or not a missing texture is an error.
(2a) just use the fill value when missing?
(2b) use a global value for missing texture value? (via
shadingsys->attribute) Do you need a different color on a shader-by-shader
basis?

Opinions?



--
You received this message because you are listed in the owner
or CC fields of this issue, or because you starred this issue.
You may adjust your issue notification preferences at:
http://code.google.com/hosting/settings


Review: fix derivatives of mod()

Larry Gritz <l...@...>
 

http://codereview.appspot.com/189073

Ugh, still having trouble making it send all review emails to this list automatically.

--
Larry Gritz
l...@...


Our code development

Larry Gritz <larry...@...>
 

I hope you all can see from the traffic in the last few days that
Imageworks is not merely planning to occasionally snapshot OSL and
release it, but rather we are committed to developing the whole thing
in public, warts and all. (This is not just my idea, but indeed is
the explicit directive from management.)

The google code SVN *is* our development trunk, we are trying to do
all our code reviews over this mail list and codereview.appspot.com,
and use the google-hosted bug tickets for our actual issue tracking
(except for cases specific to our in-house renderer or that discuss
unreleased films).

So you'll see everything, be it good, bad, ugly, or irrelevant. But
you'll also see the steady daily progress, maybe learn something about
our development process, and some of you, I hope, will be inspired to
participate.

-- lg


Re: Question about BSDFClosure functions

Larry Gritz <l...@...>
 

On Jan 14, 2010, at 9:31 AM, Alex Conty wrote:

Apparently I can't post here from my work address, so resending. Sorry
if somebody gets a duplicate.

If it's just a case of the message bouncing because it doesn't know you (at work) are a member of the group, try signing up for a second googlegroups membership, using your work address, and check the box that says "web participation only, no email". That will make it accept emails from you but not send you duplicate emails to both your work mail and your gmail account.

I have to say, one of my main annoyances with google code hosting is that so many things require "google credentials" rather than one's normal home or work email and userid.

--
Larry Gritz
l...@...


Re: Question about BSDFClosure functions

Alex Conty <aco...@...>
 

Apparently I can't post here from my work address, so resending. Sorry
if somebody gets a duplicate.

Hi Brecht, I'm Alejandro Conty (jandro in the old blender days), we
met
several times at the Blender conference. Nice hearing from you about
this.


I have a question that I couldn't find an answer to in the
documentation or source code. The BSDFClosure has eval_reflect,
eval_transmit and sample functions. Some rendering engines have an
additional function to compute the average reflected or transmitted
color independent of the incoming light direction, by the integrating
the bsdf over the incoming light direction without any lights. In PBRT
for example this function is called rho.

I understand the main use for this is importance sampling. I'm afraid
I'm not allowed to say how we do things here at imageworks, but there
are other ways to do importance sampling. That function would make
things easier, of course, the problem is that not all BSDF's can be
easily integrated. The expensive method is not an option, it would be
overkill. So you need an analytical solution which is not always
available.

There is also a practical issue too. We have this sample function
that
has to return a normalized PDF and so. It turns out that people find
it
very hard to implement it in some cases. Even when the PDF doesn't
have
to match the BSDF exactly. So adding that extra function could be
asking
for too much. But the discussion is open and you are wellcome in.

Let's see what the other guys think about this ...

Alex


Question about BSDFClosure functions

brecht <brechtv...@...>
 

Hi,

First, let me say thanks for releasing this as open source, it's
looking very impressive. I'm working on the shading system in Blender
and was looking into how this design compares to what I'm planning and
how I could make my implementation compatible such that OSL could be
plugged in at a later time.

I have a question that I couldn't find an answer to in the
documentation or source code. The BSDFClosure has eval_reflect,
eval_transmit and sample functions. Some rendering engines have an
additional function to compute the average reflected or transmitted
color independent of the incoming light direction, by the integrating
the bsdf over the incoming light direction without any lights. In PBRT
for example this function is called rho.

There are a number of uses for this:
* Compute surface albedo, i.e. "unshaded color", to output as a pass
for example.
* Compute surface opacity (by doing this for transmission), useful as
a pass for compositing, rasterization with alpha or transparent
shadows.
* Importance sampling by picking one of two blended bsdf's
proportional to this.

It would be possible to compute this value by doing the integration
each time, calling the sample function a number of times, but this is
not as efficient as it could be. Or these values could be manually
provided by the shader writer. Maybe there is another way to do this
that I'm missing, or perhaps it was left out intentionally, or not
implemented yet, ..?

Thanks,
Brecht.


Review: bug fix with compound initializers

Larry Gritz <l...@...>
 

http://codereview.appspot.com/189060

Sorry, I can't quite seem to get the review comments to automatically get sent to this list. Do we care? Would you guys like to see every review-related email, or just the initial "there is a review for Foo at http://blah"?

--
Larry Gritz
l...@...


Re: Bug fix with compound initializers (issue189060)

cku...@...
 


Bug fix with compound initializers (issue189060)

larry...@...
 

Reviewers: ,

Message:
Review at http://codereview.appspot.com/189060

Description:
Bug introduced with r507 when I overhauled compound initializers in
ASTvariable_declaration. Forgot one place where they needed to be
handled.


Please review this at http://codereview.appspot.com/189060

Affected files:
M src/liboslcomp/codegen.cpp
M src/liboslcomp/oslcomp.cpp


Index: src/liboslcomp/codegen.cpp
===================================================================
--- src/liboslcomp/codegen.cpp (revision 517)
+++ src/liboslcomp/codegen.cpp (working copy)
@@ -515,7 +515,14 @@

if (init() && sym->fieldid() < 0) {
// Normal vars with initializers -- generate them
- for (ASTNode::ref i = init(); i; i = i->next()) {
+
+ // If it's a compound initializer, look at the individual pieces
+ ref init = this->init();
+ if (init->nodetype() == compound_initializer_node) {
+ init = ((ASTcompound_initializer *)init.get())->initlist();
+ }
+
+ for (ASTNode::ref i = init; i; i = i->next()) {
completed &= param_one_default_literal (sym, i.get(), out);
}
} else {
Index: src/liboslcomp/oslcomp.cpp
===================================================================
--- src/liboslcomp/oslcomp.cpp (revision 517)
+++ src/liboslcomp/oslcomp.cpp (working copy)
@@ -601,7 +601,7 @@
}

if (m_ircode.size() == 0) // If no code, still need a code marker
- oso ("code main\n");
+ oso ("code ___main___\n");

oso ("\tend\n");


Review: message passing of closures, and bug fixes

Larry Gritz <l...@...>
 

We're big fans of code reviews BEFORE committing into the trunk, and at SPI used ReviewBoard religiously while developing OSL. We're still trying to figure out how to do reviews the way we prefer, now that we're on google code; their native tool is set up for post-commit reviews.

So here's our first try at using codereview.appspot.com, a google web app that lets you make code reviews for local changes that haven't been committed, against a public repository. Let's see how well it goes. Apologies if it's clunky until we figure out the logistics.

There will probably be a duplicate email to the group, since I specified osl...@... as a CC on the review app.


http://codereview.appspot.com/186135


--
Larry Gritz
l...@...

4961 - 4980 of 5005