Date   

Re: Volume Shaders

Daniel <night-...@...>
 

On 21 Jan., 08:33, Larry Gritz <l...@...> wrote:
A "volume integrator" in the renderer is responsible for doing the actual ray marching, evaluating the closure for specific light directions, and accumulating the contributions along the viewing ray.
OK, that is how I interpreted the spec.
The volume integrator will, presumably, need some information about
the density of the volume, right? Do you already have ideas for
specifying that in OSL? Or will volume density information simply be
part of the scene description so integrators can choose to do this in
a way that fits their scene format?

Regards,
Daniel


Re: Volume Shaders

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

We're tackling the volume shaders fairly soon. The spec isn't very clear about them, but that will be beefed up as we implement it. Basically the idea is that it will be very analogous to surface shaders -- returning a closure that describes in a view-independent way what the scattering of the volume is at a particular point. A "volume integrator" in the renderer is responsible for doing the actual ray marching, evaluating the closure for specific light directions, and accumulating the contributions along the viewing ray.

This will all get fleshed out over the next few weeks, there's a pretty strong near-term deadline on our own shows to get this working.

-- lg


On Jan 20, 2010, at 12:29 AM, Daniel wrote:

Guys,

I just started looking into OSL. It certainly looks very interesting!
Did I miss something or is it true that volume shaders are currently
neither implemented, nor truly specified?
I see that you filed issue #3 about this. Can you already comment on
your plans for volume shaders? I'm curious... Which part of the
illumination will the shaders actually compute?

Regards,
Daniel
<ATT00001..txt>
--
Larry Gritz
l...@...


Re: Compiling OpenShadingLanguage under Windows

Wormszer <worm...@...>
 


I have mcpp integrated into the compiler now. Working like CPP and writing everything to stdout.

A few things, the binary available for download at least on windows doesn't support forcing an include file.
So i had to build it from source, luckily it wasn't to difficult to create a new project for it.

I built it as VS for VS. Now that I think about it I bet I could build it as VS for GCC so that it would support the same command line options.

Another weird issue was I guess the lexer doesn't support  c-style /* comments? These might not be defined in the osl language, and if so probably should be removed from the stdosl.h.
Its the only difference i could see, that could of been causing the error.

CL would remove the */ */ comments at the end of the math defines in stdosl.h even though i told it to preserve comments.

mcpp when i told it to leave comments would actually leave them in there(seems like correct behavior), and then the lexer would crash.

I am not sure why comments are needed really at this point, and i think i must of included them for my own debugging, i don't think CPP was set to output them.

Thanks for the suggestions on a easier solution to the pre-processor issue.

I looked real quick for the boost but mcpp seemed easier since i could just get a binary and set it in my path. (but then i had to rebuild it)

Well now to see if I can get anything to happen with my compiled shaders.

Jeremy


On Wed, Jan 20, 2010 at 9:03 PM, Wormszer <worm...@...> wrote:
I am fine with either one. I think having something embedded or buildable would be usefull.

Otherwise there maybe issues with different compilers and would probably need some kind of config or something that cmake would generate at least on windows with several versions of VS etc.

Will just have to see how Larry or the other devs feel about using one of those two for Linux builds as well. I would assume it would be wise to have all the preprocessing done with the same tool when possible.

I will look at both real quick but I might lean towards mcpp.


On Jan 20, 2010, at 8:14 PM, Chris Foster <chri...@...> wrote:

On Thu, Jan 21, 2010 at 11:02 AM, Blair Zajac <bl...@...> wrote:
The main annoyance with wave is that it causes the compiler to issue truly
horrendous error messages if you get things wrong (the wave internals make
heavy use of template metaprogramming).

(Obviously this is only a problem when integrating wave into the project
source, and that's not really difficult at all.)

There's mcpp which is designed to be an embeddable C-preprocessor.

Ice, which we use at Sony Imageworks for all our middle-tier systems, uses
mcpp for it's own internal IDL type language, so I would recommend that.

mcpp looks nice.  In some sense, using wave would mean one less dependency
since OSL already relies on boost, but it does mean linking to libboost-wave,
so if you have a modular boost install the point may be moot...

~Chris

PS: Sorry to Blair for the duplicate message.  I intended to send it
to the list :-(
--
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: Compiling OpenShadingLanguage under Windows

Wormszer <worm...@...>
 

I am fine with either one. I think having something embedded or buildable would be usefull.

Otherwise there maybe issues with different compilers and would probably need some kind of config or something that cmake would generate at least on windows with several versions of VS etc.

Will just have to see how Larry or the other devs feel about using one of those two for Linux builds as well. I would assume it would be wise to have all the preprocessing done with the same tool when possible.

I will look at both real quick but I might lean towards mcpp.

On Jan 20, 2010, at 8:14 PM, Chris Foster <chri...@...> wrote:

On Thu, Jan 21, 2010 at 11:02 AM, Blair Zajac <bl...@...> wrote:
The main annoyance with wave is that it causes the compiler to issue truly
horrendous error messages if you get things wrong (the wave internals make
heavy use of template metaprogramming).
(Obviously this is only a problem when integrating wave into the project
source, and that's not really difficult at all.)

There's mcpp which is designed to be an embeddable C-preprocessor.

Ice, which we use at Sony Imageworks for all our middle-tier systems, uses
mcpp for it's own internal IDL type language, so I would recommend that.
mcpp looks nice. In some sense, using wave would mean one less dependency
since OSL already relies on boost, but it does mean linking to libboost-wave,
so if you have a modular boost install the point may be moot...

~Chris

PS: Sorry to Blair for the duplicate message. I intended to send it
to the list :-(
--
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: Compiling OpenShadingLanguage under Windows

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

On Thu, Jan 21, 2010 at 11:02 AM, Blair Zajac <bl...@...> wrote:
The main annoyance with wave is that it causes the compiler to issue truly
horrendous error messages if you get things wrong (the wave internals make
heavy use of template metaprogramming).
(Obviously this is only a problem when integrating wave into the project
source, and that's not really difficult at all.)

There's mcpp which is designed to be an embeddable C-preprocessor.

Ice, which we use at Sony Imageworks for all our middle-tier systems, uses
mcpp for it's own internal IDL type language, so I would recommend that.
mcpp looks nice. In some sense, using wave would mean one less dependency
since OSL already relies on boost, but it does mean linking to libboost-wave,
so if you have a modular boost install the point may be moot...

~Chris

PS: Sorry to Blair for the duplicate message. I intended to send it
to the list :-(


Re: Compiling OpenShadingLanguage under Windows

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

On 01/20/2010 03:11 PM, Chris Foster wrote:
On Thu, Jan 21, 2010 at 7:37 AM, Wormszer<worm...@...> wrote:
I have a solution but its not very elegant. The compiler is hard coded to
use linux CPP preprocessor. /usr/bin/CPP
Over at aqsis, we use the C preprecessor from boost called boost.wave. It's
been a good choice for us since it runs anywhere with a capable C++ compiler.

The main annoyance with wave is that it causes the compiler to issue truly
horrendous error messages if you get things wrong (the wave internals make
heavy use of template metaprogramming).
There's mcpp which is designed to be an embeddable C-preprocessor.

Ice, which we use at Sony Imageworks for all our middle-tier systems, uses mcpp for it's own internal IDL type language, so I would recommend that.

Regards,
Blair


Re: Compiling OpenShadingLanguage under Windows

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

On Thu, Jan 21, 2010 at 7:37 AM, Wormszer <worm...@...> wrote:
I have a solution but its not very elegant. The compiler is hard coded to
use linux CPP preprocessor. /usr/bin/CPP
Over at aqsis, we use the C preprecessor from boost called boost.wave. It's
been a good choice for us since it runs anywhere with a capable C++ compiler.

The main annoyance with wave is that it causes the compiler to issue truly
horrendous error messages if you get things wrong (the wave internals make
heavy use of template metaprogramming).

~Chris.


Re: Compiling OpenShadingLanguage under Windows

Oleg <ode...@...>
 

Nice debugging session... Thanks for the information :-)

Did you try to use the "ShellExecute()" function? Does the
"ShellExecute()" function setup the environment in the right way (or
just not modify the existing one)?

I will try to look into it in the next days.

Oleg

On 20 Jan., 22:37, Wormszer <wo...@...> wrote:
Hello Oleg,

That's probably a better solution. Will need to go back and make sure the
libraries export their classes rather than duplicating the source in the
projects.
I was trying to avoid adding to much to the code for windows, and I was
planning on after hopefully to get it all building, to then do a clean
checkout and do it again and make changes to submit as a patch.

I played around some and finally got a shader to compile.

I have a solution but its not very elegant. The compiler is hard coded to
use linux CPP preprocessor. /usr/bin/CPP
I was able to get it working using CL to do the pre-processing. But I had to
write it to a file and read it back in rather than using stdout.
Its only a few lines of code extra and passes the file handle from the
opened file to the parser instead of the _popen handle.

CL will output to stdout. When i was testing in in the debugger the issue
was that by default the build environment is not setup.
You typically have to run the vcvars32.bat to set it up and that was causing
some issues.

And then i am not positive if the stdout of CL parses correctly, it seems to
insert the filename at the begining, but the file output does.

So maybe we can figure out a better solution to get it working with cl using
stdout. It may work if you run oslc from a command prompt with the vs
variables setup already.
I will try that next, except im expecting the process spawned by _popen
won't have the environment setup correctly. And since it using stdout to
read from then anything you do can't output or it gets parsed.

If you mess with it the parameters to CL i used are /P /C /EP /X /nologo and
then /FI to force the include file. Remove /P if you want stdout instead of
file.

Jeremy

On Wed, Jan 20, 2010 at 4:07 PM, Oleg <od...@...> wrote:
Hi Jeremy,
Great,
Did you encounter the same linking issues i mentioned?
Yes, but I've solved them a bit different: just added export macros to
the corresponding classes and "implemented" the "Symbol::mangled ()"
method inline.
Let me know how it works out for you.
I didn't perform any tests so far.
Regards,
Oleg
I had tried compiling the shaders after making some changes to the
project
file for a path issues, but I didnt get any warnings or outputs from
inside
vs.
If I tried to run it from the command line, after finding all the
dependencies, it gave me a could not find file error. It didn't seem to
be a
dll error but something else.
I plan to look into it more now.
Jeremy
--
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...@...<osl-dev%2B...@...>
.
For more options, visit this group at
http://groups.google.com/group/osl-dev?hl=en.


Re: Compiling OpenShadingLanguage under Windows

Wormszer <worm...@...>
 

Hello Oleg,

That's probably a better solution. Will need to go back and make sure the libraries export their classes rather than duplicating the source in the projects.
I was trying to avoid adding to much to the code for windows, and I was planning on after hopefully to get it all building, to then do a clean checkout and do it again and make changes to submit as a patch.

I played around some and finally got a shader to compile.

I have a solution but its not very elegant. The compiler is hard coded to use linux CPP preprocessor. /usr/bin/CPP
I was able to get it working using CL to do the pre-processing. But I had to write it to a file and read it back in rather than using stdout.
Its only a few lines of code extra and passes the file handle from the opened file to the parser instead of the _popen handle.

CL will output to stdout. When i was testing in in the debugger the issue was that by default the build environment is not setup.
You typically have to run the vcvars32.bat to set it up and that was causing some issues.

And then i am not positive if the stdout of CL parses correctly, it seems to insert the filename at the begining, but the file output does.

So maybe we can figure out a better solution to get it working with cl using stdout. It may work if you run oslc from a command prompt with the vs variables setup already.
I will try that next, except im expecting the process spawned by _popen won't have the environment setup correctly. And since it using stdout to read from then anything you do can't output or it gets parsed.

If you mess with it the parameters to CL i used are /P /C /EP /X /nologo and then /FI to force the include file. Remove /P if you want stdout instead of file.

Jeremy


On Wed, Jan 20, 2010 at 4:07 PM, Oleg <ode...@...> wrote:
Hi Jeremy,

> Great,
>
> Did you encounter the same linking issues i mentioned?
>

Yes, but I've solved them a bit different: just added export macros to
the corresponding classes and "implemented" the "Symbol::mangled ()"
method inline.

> Let me know how it works out for you.

I didn't perform any tests so far.

Regards,
Oleg

>
> I had tried compiling the shaders after making some changes to the project
> file for a path issues, but I didnt get any warnings or outputs from inside
> vs.
> If I tried to run it from the command line, after finding all the
> dependencies, it gave me a could not find file error. It didn't seem to be a
> dll error but something else.
>
> I plan to look into it more now.
>
> Jeremy
>

--
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: Compiling OpenShadingLanguage under Windows

Oleg <ode...@...>
 

Hi Jeremy,

Great,

Did you encounter the same linking issues i mentioned?
Yes, but I've solved them a bit different: just added export macros to
the corresponding classes and "implemented" the "Symbol::mangled ()"
method inline.

Let me know how it works out for you.
I didn't perform any tests so far.

Regards,
Oleg


I had tried compiling the shaders after making some changes to the project
file for a path issues, but I didnt get any warnings or outputs from inside
vs.
If I tried to run it from the command line, after finding all the
dependencies, it gave me a could not find file error. It didn't seem to be a
dll error but something else.

I plan to look into it more now.

Jeremy


Review: raylevel and isshadowray

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

http://codereview.appspot.com/186244

This is the OSL-side change. On the renderer side, you still need to set the fields in the ShaderGlobals correctly.

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


Re: Compiling OpenShadingLanguage under Windows

Wormszer <worm...@...>
 

I agree, it was something I was going to suggest too after getting a windows version built and all the details worked out.
Its seems overkill having to install cygwin to just be able to parse a couple of files when doing a checkout and straight build.

Is anyone else trying to build OSL on windows besides Oleg and me?
I have a feeling its not a very common target in the movie business or for the current set of users.


Jeremy


On Wed, Jan 20, 2010 at 4:10 AM, Pierre Saunier <pierre...@...> wrote:
Dear all,

Isn't it possible to distribute the files produced by Flex and bison?
Normally, they should be independant from the system (they are produced on and they are
used on), and it will avoid a lot of trouble to build osl...
And if someone wants to recreate them, it is always possible!

When the doc about integrating OSL in an actual renderer will be available? At least some
sample code?

Regards,

Pierre

> Great,
>
> Did you encounter the same linking issues i mentioned?
>
> Let me know how it works out for you.
>
> I had tried compiling the shaders after making some changes to the project
> file for a path issues, but I didnt get any warnings or outputs from inside
> vs.
> If I tried to run it from the command line, after finding all the
> dependencies, it gave me a could not find file error. It didn't seem to be a
> dll error but something else.
>
> I plan to look into it more now.
>
> Jeremy
>
>
> On Tue, Jan 19, 2010 at 8:14 PM, Oleg <ode...@...> wrote:
>
> > Hi Jeremy,
> >
> > Using boost math functions, some definitions in fmath.h and the
> > following two implementations of my own
> >
> > inline float
> > logbf(float val) {
> >    // please see
> > http://www.kernel.org/doc/man-pages/online/pages/man3/logb.3.html
> >    return logf(val)/logf(FLT_RADIX);
> > }
> >
> > inline float
> > exp2f(float val) {
> >    // 2^val = e^(val*ln(2))
> >    return exp( val*log(2.0f) );
> > }
> >
> > I was able to compile it under Windows. It's not the best solution,
> > but probably better as nothing...
> >
> > It's time to test it :-)
> >
> > Regards,
> > Oleg
> >
> > On 19 Jan., 19:08, Wormszer <wo...@...> wrote:
> > > Thanks Larry,
> > >
> > > I was wondering where the best place would be to add the missing
> > > functionality.
> > > Currently I have used the boost C99 math libraries and the missing two
> > > functions logbf and exp2f i defined to 0.0f temporarily so I could see
> > what
> > > other issues I would run into when building.
> > > I will come back and try and work the missing math functions into
> > fmath.h.
> > >
> > > But I have run into a couple of other issues with the oslexec project and
> > > the TypeSpec class.
> > >
> > > It seems that some of its functions are implemented in Symtab.cpp instead
> > of
> > > TypeSpec.cpp specifically, c_str() and string(). I am not sure if this
> > was
> > > on purpose or not.
> > > On the oslexec project on windows this was causing linking issues. This
> > > project doesn't include symtab.cpp and they were not being exported from
> > the
> > > oslcomp library. Including Symtab.cpp raises other errors.
> > > So I moved these declarations into the TypeSpec.cpp file fixing the
> > linking
> > > errors.
> > >
> > > There is a similiar issue with Symbol::mangled () it was implemented in
> > > Symtab.cpp as well. I also moved this to TypeSpec.cpp to fix the errors
> > But
> > > I am not sure if that is best place since its not as obvious as the
> > TypeSpec
> > > functions.
> > >
> > > I can now build oslexec and it did not seem to effect oslcomp.
> > >
> > > Jeremy
> > >
> >
> > --
> > 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...@...<osl-dev%2B...@...>
> > .
> > For more options, visit this group at
> > http://groups.google.com/group/osl-dev?hl=en.
> >
> >
> >
> >
>

_________________________________________________________
Mail sent using root eSolutions Webmailer - www.root.lu



--
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: Compiling OpenShadingLanguage under Windows

"Pierre Saunier" <pierre...@...>
 

Dear all,

Isn't it possible to distribute the files produced by Flex and bison?
Normally, they should be independant from the system (they are produced on and they are
used on), and it will avoid a lot of trouble to build osl...
And if someone wants to recreate them, it is always possible!

When the doc about integrating OSL in an actual renderer will be available? At least some
sample code?

Regards,

Pierre

Great,

Did you encounter the same linking issues i mentioned?

Let me know how it works out for you.

I had tried compiling the shaders after making some changes to the project
file for a path issues, but I didnt get any warnings or outputs from inside
vs.
If I tried to run it from the command line, after finding all the
dependencies, it gave me a could not find file error. It didn't seem to be a
dll error but something else.

I plan to look into it more now.

Jeremy


On Tue, Jan 19, 2010 at 8:14 PM, Oleg <ode...@...> wrote:

Hi Jeremy,

Using boost math functions, some definitions in fmath.h and the
following two implementations of my own

inline float
logbf(float val) {
// please see
http://www.kernel.org/doc/man-pages/online/pages/man3/logb.3.html
return logf(val)/logf(FLT_RADIX);
}

inline float
exp2f(float val) {
// 2^val = e^(val*ln(2))
return exp( val*log(2.0f) );
}

I was able to compile it under Windows. It's not the best solution,
but probably better as nothing...

It's time to test it :-)

Regards,
Oleg

On 19 Jan., 19:08, Wormszer <wo...@...> wrote:
Thanks Larry,

I was wondering where the best place would be to add the missing
functionality.
Currently I have used the boost C99 math libraries and the missing two
functions logbf and exp2f i defined to 0.0f temporarily so I could see
what
other issues I would run into when building.
I will come back and try and work the missing math functions into
fmath.h.

But I have run into a couple of other issues with the oslexec project and
the TypeSpec class.

It seems that some of its functions are implemented in Symtab.cpp instead
of
TypeSpec.cpp specifically, c_str() and string(). I am not sure if this
was
on purpose or not.
On the oslexec project on windows this was causing linking issues. This
project doesn't include symtab.cpp and they were not being exported from
the
oslcomp library. Including Symtab.cpp raises other errors.
So I moved these declarations into the TypeSpec.cpp file fixing the
linking
errors.

There is a similiar issue with Symbol::mangled () it was implemented in
Symtab.cpp as well. I also moved this to TypeSpec.cpp to fix the errors
But
I am not sure if that is best place since its not as obvious as the
TypeSpec
functions.

I can now build oslexec and it did not seem to effect oslcomp.

Jeremy
--
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...@...<osl-dev%2B...@...>
.
For more options, visit this group at
http://groups.google.com/group/osl-dev?hl=en.



_________________________________________________________
Mail sent using root eSolutions Webmailer - www.root.lu


Volume Shaders

Daniel <night-...@...>
 

Guys,

I just started looking into OSL. It certainly looks very interesting!
Did I miss something or is it true that volume shaders are currently
neither implemented, nor truly specified?
I see that you filed issue #3 about this. Can you already comment on
your plans for volume shaders? I'm curious... Which part of the
illumination will the shaders actually compute?

Regards,
Daniel


Re: Compiling OpenShadingLanguage under Windows

Wormszer <worm...@...>
 

Great,

Did you encounter the same linking issues i mentioned?

Let me know how it works out for you.

I had tried compiling the shaders after making some changes to the project file for a path issues, but I didnt get any warnings or outputs from inside vs.
If I tried to run it from the command line, after finding all the dependencies, it gave me a could not find file error. It didn't seem to be a dll error but something else.

I plan to look into it more now.

Jeremy


On Tue, Jan 19, 2010 at 8:14 PM, Oleg <ode...@...> wrote:
Hi Jeremy,

Using boost math functions, some definitions in fmath.h and the
following two implementations of my own

inline float
logbf(float val) {
   // please see http://www.kernel.org/doc/man-pages/online/pages/man3/logb.3.html
   return logf(val)/logf(FLT_RADIX);
}

inline float
exp2f(float val) {
   // 2^val = e^(val*ln(2))
   return exp( val*log(2.0f) );
}

I was able to compile it under Windows. It's not the best solution,
but probably better as nothing...

It's time to test it :-)

Regards,
Oleg

On 19 Jan., 19:08, Wormszer <wo...@...> wrote:
> Thanks Larry,
>
> I was wondering where the best place would be to add the missing
> functionality.
> Currently I have used the boost C99 math libraries and the missing two
> functions logbf and exp2f i defined to 0.0f temporarily so I could see what
> other issues I would run into when building.
> I will come back and try and work the missing math functions into fmath.h.
>
> But I have run into a couple of other issues with the oslexec project and
> the TypeSpec class.
>
> It seems that some of its functions are implemented in Symtab.cpp instead of
> TypeSpec.cpp specifically, c_str() and string(). I am not sure if this was
> on purpose or not.
> On the oslexec project on windows this was causing linking issues. This
> project doesn't include symtab.cpp and they were not being exported from the
> oslcomp library. Including Symtab.cpp raises other errors.
> So I moved these declarations into the TypeSpec.cpp file fixing the linking
> errors.
>
> There is a similiar issue with Symbol::mangled () it was implemented in
> Symtab.cpp as well. I also moved this to TypeSpec.cpp to fix the errors But
> I am not sure if that is best place since its not as obvious as the TypeSpec
> functions.
>
> I can now build oslexec and it did not seem to effect oslcomp.
>
> Jeremy
>

--
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.





is OSL too memory intensive ?

mrafsan <raf...@...>
 

"Radiance Closure" is definitely very neat idea. The concept of not
executing the whole shader at once can be very powerful. From what I
understand , closures save some shader local variables and execute
the whole function only when the renderer requires them to. Assuming a
sample interacts with many shaders/materials/objects and not all of
the "closures" are fully computed , wouldn't the sample have too many
contextual closure data to deal with?
This can be a problem for a fully GPU-accelerated renderer that
supports OSL .


Re: Arbitrary derivatives

Bo Schwarzstein <bo.schw...@...>
 

Hello,

I'm clear now. The OSL as an independent shading language do not care
about how the user implement this feature on Raytracer (Arnold ?),
REYES renderer or GPU.

I will take a look at the AD, seems interesting.

Thanks for your replies.

On Jan 19, 11:24 pm, Larry Gritz <l...@...> wrote:
On Jan 19, 2010, at 12:52 AM, Bo Schwarzstein wrote:

Hello folks,
In specification, it sais "Arbitrary derivatives without grids or
extra shading points.", but I really confused how it works without
explicit grid. Does it like the GPU, compute the derivatives on screen
space ?
Thanks.
Let's separate the language specification, from the implementation in this library, from what a renderer is expected to do when using the OSL library.

The language spec just requires that an implementation can take derivatives of any quantity with respect to "x" and "y".  The definitions of x,y are purposely undefined, they are allowed to be anything convenient to the renderer as long as they are roughly perpendicular and that x and/or y change by approximately 1 from pixel to pixel (so derivatives can be used to estimate filter sizes).  Also, the language itself doesn't really care how Dx() and Dy() are implemented.

In the implementation of the OSL runtime library, we really wanted derivatives to work just as well for ray tracers that shade in arbitrary locations than for Reyes-like renderers that have grids.  We chose to use a kind of "automatic differentiation" based on dual arithmetic that tracks the differentials correctly for every calculation (read Dan Piponi's paper from JGT 2004 for a good introduction), so then the implementation of Dx() and Dy() is simply looking up the x and y partials of the variable in question.  The bottom line is that it does not require grids or extra shading points.

At SPI, our renderer is a pure ray tracer, so for us x and y are pixel coordinates and we use ray differentials when setting up shading batches (you need to pass things like dP/dx and dP/dy into OSL, then it handles all the rest). 

If a Reyes-like renderer (shading on grids) wanted to use our OSL implementation, there's no reason why a shading batch couldn't be arranged in a rectilinear grid, and if they wanted their derivatives to be aligned to the grids, they could still pass the initial values using x==u*du and y==v*dv and mimic what would usually happen for Reyes (even though our library would not actually be differencing grid points to find the derivatives).

Similarly, a pure GPU-based implementation of OSL would be allowed to have x,y aligned to screen space and use the funny/awful "alternating forward and backward differences" that GPUs do naturally.

Does that all make sense?

(Aside: at this moment, we use the dual arithmetic for everything, leading to quite a bit of wasted math.  Among other optimizations I'm currently working on is to use the dual arithmetic only for the subset of calculations that lead to expressions whose derivatives are actually used, this should eliminate most of the extra math, since so few derivatives are taken.  I've done some experiments that indicate that we can save somewhere near 30% when this is done.)

        -- lg

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


Re: Arbitrary derivatives

Bo Schwarzstein <bo.schw...@...>
 

Hello,

Yes, it's amazing, I did not hear the Automatic Differentiation
before, it seems like an ideal math method to handle this.

On Jan 19, 11:09 pm, Henri <henr...@...> wrote:
On 19 jan, 09:52, Bo Schwarzstein <bo.sc...@...> wrote:

Hello folks,
In specification, it sais "Arbitrary derivatives without grids or
extra shading points.", but I really confused how it works without
explicit grid. Does it like the GPU, compute the derivatives on screen
space ?
No, it does automatic differentiation.

The overall idea is that if your inputs know their derivatives ( for
instance, when raytracing a primitive, computing P, dP/dx and dP/dy is
easy )
and your shading library know how to differentiate all its operators,
you are able to maintain derivatives quantities while shading.

Look athttp://jgt.akpeters.com/papers/Piponi04/for a complete
reference.

 Hopes this helps

         Henri



Thanks.


Re: Compiling OpenShadingLanguage under Windows

Oleg <ode...@...>
 

Hi Jeremy,

Using boost math functions, some definitions in fmath.h and the
following two implementations of my own

inline float
logbf(float val) {
// please see http://www.kernel.org/doc/man-pages/online/pages/man3/logb.3.html
return logf(val)/logf(FLT_RADIX);
}

inline float
exp2f(float val) {
// 2^val = e^(val*ln(2))
return exp( val*log(2.0f) );
}

I was able to compile it under Windows. It's not the best solution,
but probably better as nothing...

It's time to test it :-)

Regards,
Oleg

On 19 Jan., 19:08, Wormszer <wo...@...> wrote:
Thanks Larry,

I was wondering where the best place would be to add the missing
functionality.
Currently I have used the boost C99 math libraries and the missing two
functions logbf and exp2f i defined to 0.0f temporarily so I could see what
other issues I would run into when building.
I will come back and try and work the missing math functions into fmath.h.

But I have run into a couple of other issues with the oslexec project and
the TypeSpec class.

It seems that some of its functions are implemented in Symtab.cpp instead of
TypeSpec.cpp specifically, c_str() and string(). I am not sure if this was
on purpose or not.
On the oslexec project on windows this was causing linking issues. This
project doesn't include symtab.cpp and they were not being exported from the
oslcomp library. Including Symtab.cpp raises other errors.
So I moved these declarations into the TypeSpec.cpp file fixing the linking
errors.

There is a similiar issue with Symbol::mangled () it was implemented in
Symtab.cpp as well. I also moved this to TypeSpec.cpp to fix the errors But
I am not sure if that is best place since its not as obvious as the TypeSpec
functions.

I can now build oslexec and it did not seem to effect oslcomp.

Jeremy


Re: shadertypes

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

Apologies for these discrepancies.

When I wrote the spec, "light" was anticipated to be a separate type, but eventually we realized it wasn't needed. I should remove it from the docs but keep it "reserved" in the grammar, in case we need it later.

"imager" is probably unnecessary, but also reserved. But we've done nothing to implement it.

The "integrator" is the part of the system that takes closures as input and figures out how much radiance really is going in a *particular* direction (given access to lights and ability to sample arbitrary directions). Currently, the integrator is a hard-coded part of the renderer, though we definitely intend to extend the language so that integrators may be written in OSL itself.

-- lg


On Jan 19, 2010, at 9:27 AM, BaiLong wrote:

Hi everyone,
I'm just a simpel student and totaly new to this stuff.
I read the specifications as soon as I could download it.
Hopefully I can make it to set up the developing environment soon,
because this stuff seems to be awesome! ;)

I hope it's ok if I post here such basic questions, because right now
there is not much help on this topic out there... ;)

The first question that puzzles me is the shadertypes.
Because in section 4. of the spec there are 4 - 5 types (depends if
you count the light shadertype).
But in the formal language Grammar section there are also imager and
integrator shaders listet.
I just try a shot in the dark and guess that the imager shader is
similar to the ones in RenderMan...
But what is an integrator? Is it an already included type or just a
reserved one for future use? If it already exists, what is it used
for?

Thanks for the help!

Cheers
--Markus
<ATT00001..txt>
--
Larry Gritz
l...@...

4921 - 4940 of 5014