Date   

problem building on macos

Nick Porcino <nick....@...>
 

I'm having some difficulty building OpenImageIO on macos (Snow
Leopard), as a required pre-requisite for building OSL. The build of
the external packages fails because libtiff doesn't build. Everything
else does.

I simply did a clean pull from the repository and followed the
instructions (and I've built dozens of open source things before, so
the issue is not unfamiliarity with make systems or anything like
that).

I've done all the usual sorts of troubleshooting, but nothing strikes
me as obviously wrong with the set up. Before I dig in seriously to
work out why the build is failing, I thought I would potentially save
some time by asking here first if anyone has successfully built on
macos after a fresh pull of OIIO and OSL, and if not, what issues and
resolutions might have got things working.

Thanks


Re: Compiling OpenShadingLanguage under Windows

Chris Foster <chri...@...>
 

On Sun, Jan 17, 2010 at 8:25 AM, Oleg <ode...@...> wrote:
| simple_typename IDENTIFIER arrayspec initializer_list
                {
                    TypeDesc simple = lextype ($1);
                    simple.arraylen = $3;
                    TypeSpec t (simple, t.is_closure
());                                        // <--- LINE 274
                    ASTvariable_declaration *var;
                    var = new ASTvariable_declaration (oslcompiler,
t,
                                     ustring ($2), $4, false,
                                     true /* ismeata */, false /
*output */,
                                     true /* initializer list */);
                    $$ = var;
                }
        ;

I'm not familiar with bison... Any help is welcome :-)
The chunk of code between the '{' and '}' is just C++ (mostly, except for the
$ markers of course). Looking at this, the line

TypeSpec t (simple, t.is_closure());

doesn't make any sense to me, since it appears to use t before it's constructed.
(Why does this even compile elsewhere? Maybe there's another variable t in the
scope?)

To me it seems this should be

TypeSpec t (simple, false);

since the metadata can never be a closure. I'm not an expert though (not by
any means!); does this sound right guys?

~Chris


Compiling OpenShadingLanguage under Windows

Oleg <ode...@...>
 

Hi All,

I'm trying to compile the OpenShadingLanguage library under Windows
using VisualStudio 2008. I was able to compile the following projects
so
far:
- oslquery
- oslinfo

There is a problem compiling the "oslgram.cpp" file generated by
bison.
The compiler complains that "TypeSpec" type used in "oslgram.y", line
274, is unknown:

Error 22 error C2065: 't' : undeclared identifier D:\Src
\OpenShadingLanguage\src\liboslcomp\oslgram.y 274

Error 23 error C2228: left of '.is_closure' must have class/
struct/union D:\Src\OpenShadingLanguage\src\liboslcomp\oslgram.y
274


Here is the corresponding code in "oslgram.y":

| simple_typename IDENTIFIER arrayspec initializer_list
{
TypeDesc simple = lextype ($1);
simple.arraylen = $3;
TypeSpec t (simple, t.is_closure
()); // <--- LINE 274
ASTvariable_declaration *var;
var = new ASTvariable_declaration (oslcompiler,
t,
ustring ($2), $4, false,
true /* ismeata */, false /
*output */,
true /* initializer list */);
$$ = var;
}
;

I'm not familiar with bison... Any help is welcome :-)

Regards,
Oleg


P.S.: It's great that Sony Pictures ImageWorks shares this technology!


Re: Review: fix derivatives of mod()

Chris Foster <chri...@...>
 

Hi guys,

On Sat, Jan 16, 2010 at 4:15 PM, Larry Gritz <l...@...> wrote:
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.
After quite some thought I agree that

d/dx mod(x,a) == 1

is about about the best you can do, even though it doesn't make sense at
the discontinuity.

It is possible to make sense of the derivative of mod() using the Dirac
delta distribution, but that's definitely a "math" thing rather than a
"what's useful in shaders" thing :-)


I had a think about alternatives, and ended up concluding that the only
other possiblity is analytical antialiasing of the derivative at the
discontinuity. However, that doesn't seem to be right because
1) It only makes sense when mod() is being used in certian ways for
pattern generation.
2) It means that mod needs to take derivatives of its arguments which
presumably makes things less efficient.
3) Surely if the derivative is being antialiased, the function value
itself should be?


That leads me to idly wonder if there's any call for an antialiased
version of mod (or more likely, floor(), since the user can then
trivially construct their own antialiased version of mod)? I notice
that you've included an aastep(), but that's arguably more useful than
aafloor() and easier to implement too...


By the way, I very much like what you're doing here with OSL. I think
the use of dual arithmetic for derivatives is particularly neat. I've
toyed with the idea before, but you guys have done all the hard work to
actually implement it, wow!

~Chris


Re: Review: fix derivatives of mod()

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

Well, there's "math" and then there's "what's useful in shaders."
Agreed. You answer seems the most useful one.

--jono


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

4961 - 4980 of 5010