Date   

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


Re: Compiling OpenShadingLanguage under Windows

Wormszer <worm...@...>
 

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


On Tue, Jan 19, 2010 at 10:34 AM, Larry Gritz <l...@...> wrote:
Sorry about joining this thread late.

I think that any files that need these functions should 

  #include <OpenImageIO/fmath.h>

where many of these symbols and some of the missing functions are defined.  See fmath.h circa line 70 for M_PI and the like, and circa line 690 for log2f.  If there are more missing functions, we should add them to fmath.h (inside the '#ifdef _WIN32' near where log2f is defined).

-- lg


On Jan 17, 2010, at 8:51 PM, Wormszer wrote:

My generated code issues were from VS having not rebuilt the files with the new flex.

So now I am just left with a bunch of missing math functions.
It looks likes visual studios implementation of math. or cmath is missing a lot of the functions.

Things like
log2f, logbf, truncf, etc
and defines like M_E, M_1_PI, M_PI_2 etc.

See if you run into the same thing and then im not sure where to go from here.

I guess we should get some feedback from others, maybe they are available somewhere else, or I could be missing something.

Jeremy


On Sun, Jan 17, 2010 at 11:29 PM, Wormszer <worm...@...> wrote:
Ok I was able to get
oslquery
oslinfo
oslcomp
oslc
all to build. I am still working on oslexec

Here is what I had to change to get it to build, see if these changes work for you or match what you figured out.


oslquery
==============================================================
Add include lib path for tbb lib.
I had to change
class DLLPUBLIC OSLQuery {
to
class DLLEXPORT OSLQuery {
I was having an issue where the __declspec(dllimport) was not allowing nparams to be called from the OSOReaderQuery class. I think this possibly has something to do with dllimport and inline functions.
I have not used dllimport when not importing from a library and from some quick reading i didn't see anything that stuck out as a possible issue other than inlining.


oslinfo
==============================================================
Add include lib path for tbb lib.


oslcomp
==============================================================
Add include lib path for tbb lib.

I was having an issue with some const operator() calls.
Digging in to the code the fix i found was here in ustring.h located in the OIIO includes
I had to add a const version of the hash/comparison operator. The non const version could probably be removed.

class ustringHash
#ifdef _WIN32
    : public hash_compare<ustring>
#endif
{
public:
    size_t operator() (const ustring &s) const { return s.hash(); }
#ifdef _WIN32
    bool operator() (const ustring &a, const ustring &b) {
        return strcmp (a.c_str(), b.c_str()) < 0;
    }
    bool operator() (const ustring &a, const ustring &b) const {
        return strcmp (a.c_str(), b.c_str()) < 0;
    }

#endif
};

That should allow for oslcomp to build.
But there were no symbols being exported from the library, so no lib was being generated.
So I changed oslcomp.h to export the OSLCompiler class borrowing the exports.h from the other libraries.
And a lib file is now generated.

#ifndef OSLCOMP_H
#define OSLCOMP_H

#include "export.h"

#ifdef OSL_NAMESPACE
namespace OSL_NAMESPACE {
#endif

namespace OSL {


class DLLEXPORT OSLCompiler {
public:


oslc
==============================================================
export symbols from oslcomp library


<unistd>
==============================================================
I use the following <unistd> file for the projects that need it.

#ifndef __STRICT_ANSI__

#include <io.h>
#include <process.h>

#define    F_OK    0
#define    R_OK    4
#define    W_OK    2
#define    X_OK    1

#endif

CMAKE
==============================================================
And there were various other CMake tweaks i had to make as well to get it to generate the project correctly and find some of the libraries.
I think the only change i was unsure why i had to make was I had to change the libsxxxx projects from LIBRARY to ARCHIVE. I'm not sure why.

oslexec
==============================================================
I am getting a lot of errors relating to the generated code and a ton of missing math functions it looks like. I will dig into this project next.


And then to see if it works after all this.
Let me know where you get.

Jeremy



On Sun, Jan 17, 2010 at 7:18 PM, Wormszer <worm...@...> wrote:
Thanks Oleg,

I am using flex 2.5.35 and bison 2.3 in cygwin 1.7.

I am pretty sure that my flex version is newer even though the version number is earlier. But im not sure about bison.
I have the GNUwin32 versions as well and tried those before. Most of the issues I had were in the flexer.h.

Hmm, I had a issue with that version of bison or flex i don't remember which that it wouldn't work with spaces in the file path when it called m4 internally.
Also I had to make sure my environment variables were defined using slashes and not backslashes otherwise CMake gave some errors.

Did you have an nparams() error in olsquerry? I am getting a linking error saying it can't find it.
Even though its looks like it should be able to find it. I will have to look closer at it and see why.

Other linker errors I had after defining R_OK were a boost library being linked twice and a missing tbb.lib.
The library errors i think come from cmake rather than vs2008. I didn't see a obvious reference to the tbb.lib in the project settings I wonder if there is a #pragma somewhere asking for it.


The error I am getting on olscomp for hash_map is


1>        C:\Program Files (x86)\Microsoft Visual Studio 9.0\VC\include\xhash(648) : while compiling class template member function 'std::list<_Ty,_Ax>::_Const_iterator<_Secure_validation> stdext::_Hash<_Traits>::lower_bound(const ustring &) const'
1>        with
1>        [
1>            _Ty=std::pair<const ustring,OSL::pvt::Symbol *>,
1>            _Ax=std::allocator<std::pair<const ustring,OSL::pvt::Symbol *>>,
1>            _Secure_validation=true,
1>            _Traits=stdext::_Hmap_traits<ustring,OSL::pvt::Symbol *,ustringHash,std::allocator<std::pair<const ustring,OSL::pvt::Symbol *>>,false>
1>        ]
1>        C:\Program Files (x86)\Microsoft Visual Studio 9.0\VC\include\hash_map(88) : see reference to class template instantiation 'stdext::_Hash<_Traits>' being compiled
1>        with
1>        [
1>            _Traits=stdext::_Hmap_traits<ustring,OSL::pvt::Symbol *,ustringHash,std::allocator<std::pair<const ustring,OSL::pvt::Symbol *>>,false>
1>        ]
1>        d:\projects\graphics\oslproject\osl\src\liboslcomp\symtab.h(258) : see reference to class template instantiation 'stdext::hash_map<_Kty,_Ty,_Tr>' being compiled
1>        with
1>        [
1>            _Kty=ustring,
1>            _Ty=OSL::pvt::Symbol *,
1>            _Tr=ustringHash
1>        ]
1>C:\Program Files (x86)\Microsoft Visual Studio 9.0\VC\include\xhash(654) : error C3849: function-style call on an expression of type 'const ustringHash' would lose const and/or volatile qualifiers for all 2 available operator overloads

I was hoping SP1 might of corrected something in the stdext::hash_map but it didn't seem to help.

I haven't dug in really deep yet to track down exactly whats going on yet. I will probably try and do that later tonight.

I am running Windows 7 x64 and using the project files generated from CMake 2.8.0.

Jeremy

On Sun, Jan 17, 2010 at 5:39 PM, Oleg <ode...@...> wrote:
Hi Jeremy,

I'm using the following versions of flex/bison:

 - flex,    GnuWin32 distribution, version 2.5.4
 - bison, GnuWin32 distribution, version 2.4.1

and having the same problems. I have simply commented out <unistd.h>
includes and compiled the corresponding files again. The another
problem is that this flex version cannot use slashes as path separator
for generated files, so I have replaced slashes by backslashes for
every flex file.

The "access" function is defined in "io.h" header file under Windows,
so I have changed the "oslquery.cpp" file as follows:

#ifdef __unix__
   #include <unistd.h>
   #define EXIST F_OK
   #define EXEC  X_OK
   #define WRITE W_OK
   #define READ  R_OK
#else
   #include <io.h>
   #define EXIST 00
   #define EXEC  01
   #define WRITE 02
   #define READ  04
#endif

The "hash_map" class is defined in "stdext" namespace under Windows/VS
2008. I think you can use it without SP1, but I'm not sure.

Regards,
Oleg


On 17 Jan., 22:52, wormszer <wo...@...> wrote:
> I too have been trying to build under windows and ran across the same
> problem with the t variable.
> Assuming gcc allows it for some reason, by default is_closure() is
> false so that is what i set it too.
>
> I am having trouble with some includes particulary
> #include <unistd.h>
>
> I have one error in oslquery a missing R_OK which is defined i believe
> through this file.
> I can dig it up and add it but I think i will run into more problems
> later on in the other projects.
>
> I am also getting a hash_map error when building oslcomp.
>
> What version of flex and bison are you using? I had found a gnuwin32
> builds of both but flex was pretty out of date.
> I have installed cygwin to use the latest versions from there to run
> flex and bison. Which generates files that have better includes
> <iostream> vs <iostream.h> etc.
>
> Hopefully we can get this figured out.
> I am using visual studio 2008 as well. I just realized i might not
> have sp1. I will update and see if that helps at all.
>
> Thanks
> 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.






<ATT00001..htm>

--
Larry Gritz




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



shadertypes

BaiLong <teneigh...@...>
 

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


Re: Compiling OpenShadingLanguage under Windows

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

Sorry about joining this thread late.

I think that any files that need these functions should 

  #include <OpenImageIO/fmath.h>

where many of these symbols and some of the missing functions are defined.  See fmath.h circa line 70 for M_PI and the like, and circa line 690 for log2f.  If there are more missing functions, we should add them to fmath.h (inside the '#ifdef _WIN32' near where log2f is defined).

-- lg


On Jan 17, 2010, at 8:51 PM, Wormszer wrote:

My generated code issues were from VS having not rebuilt the files with the new flex.

So now I am just left with a bunch of missing math functions.
It looks likes visual studios implementation of math. or cmath is missing a lot of the functions.

Things like
log2f, logbf, truncf, etc
and defines like M_E, M_1_PI, M_PI_2 etc.

See if you run into the same thing and then im not sure where to go from here.

I guess we should get some feedback from others, maybe they are available somewhere else, or I could be missing something.

Jeremy


On Sun, Jan 17, 2010 at 11:29 PM, Wormszer <worm...@...> wrote:
Ok I was able to get
oslquery
oslinfo
oslcomp
oslc
all to build. I am still working on oslexec

Here is what I had to change to get it to build, see if these changes work for you or match what you figured out.


oslquery
==============================================================
Add include lib path for tbb lib.
I had to change
class DLLPUBLIC OSLQuery {
to
class DLLEXPORT OSLQuery {
I was having an issue where the __declspec(dllimport) was not allowing nparams to be called from the OSOReaderQuery class. I think this possibly has something to do with dllimport and inline functions.
I have not used dllimport when not importing from a library and from some quick reading i didn't see anything that stuck out as a possible issue other than inlining.


oslinfo
==============================================================
Add include lib path for tbb lib.


oslcomp
==============================================================
Add include lib path for tbb lib.

I was having an issue with some const operator() calls.
Digging in to the code the fix i found was here in ustring.h located in the OIIO includes
I had to add a const version of the hash/comparison operator. The non const version could probably be removed.

class ustringHash
#ifdef _WIN32
    : public hash_compare<ustring>
#endif
{
public:
    size_t operator() (const ustring &s) const { return s.hash(); }
#ifdef _WIN32
    bool operator() (const ustring &a, const ustring &b) {
        return strcmp (a.c_str(), b.c_str()) < 0;
    }
    bool operator() (const ustring &a, const ustring &b) const {
        return strcmp (a.c_str(), b.c_str()) < 0;
    }

#endif
};

That should allow for oslcomp to build.
But there were no symbols being exported from the library, so no lib was being generated.
So I changed oslcomp.h to export the OSLCompiler class borrowing the exports.h from the other libraries.
And a lib file is now generated.

#ifndef OSLCOMP_H
#define OSLCOMP_H

#include "export.h"

#ifdef OSL_NAMESPACE
namespace OSL_NAMESPACE {
#endif

namespace OSL {


class DLLEXPORT OSLCompiler {
public:


oslc
==============================================================
export symbols from oslcomp library


<unistd>
==============================================================
I use the following <unistd> file for the projects that need it.

#ifndef __STRICT_ANSI__

#include <io.h>
#include <process.h>

#define    F_OK    0
#define    R_OK    4
#define    W_OK    2
#define    X_OK    1

#endif

CMAKE
==============================================================
And there were various other CMake tweaks i had to make as well to get it to generate the project correctly and find some of the libraries.
I think the only change i was unsure why i had to make was I had to change the libsxxxx projects from LIBRARY to ARCHIVE. I'm not sure why.

oslexec
==============================================================
I am getting a lot of errors relating to the generated code and a ton of missing math functions it looks like. I will dig into this project next.


And then to see if it works after all this.
Let me know where you get.

Jeremy



On Sun, Jan 17, 2010 at 7:18 PM, Wormszer <worm...@...> wrote:
Thanks Oleg,

I am using flex 2.5.35 and bison 2.3 in cygwin 1.7.

I am pretty sure that my flex version is newer even though the version number is earlier. But im not sure about bison.
I have the GNUwin32 versions as well and tried those before. Most of the issues I had were in the flexer.h.

Hmm, I had a issue with that version of bison or flex i don't remember which that it wouldn't work with spaces in the file path when it called m4 internally.
Also I had to make sure my environment variables were defined using slashes and not backslashes otherwise CMake gave some errors.

Did you have an nparams() error in olsquerry? I am getting a linking error saying it can't find it.
Even though its looks like it should be able to find it. I will have to look closer at it and see why.

Other linker errors I had after defining R_OK were a boost library being linked twice and a missing tbb.lib.
The library errors i think come from cmake rather than vs2008. I didn't see a obvious reference to the tbb.lib in the project settings I wonder if there is a #pragma somewhere asking for it.


The error I am getting on olscomp for hash_map is


1>        C:\Program Files (x86)\Microsoft Visual Studio 9.0\VC\include\xhash(648) : while compiling class template member function 'std::list<_Ty,_Ax>::_Const_iterator<_Secure_validation> stdext::_Hash<_Traits>::lower_bound(const ustring &) const'
1>        with
1>        [
1>            _Ty=std::pair<const ustring,OSL::pvt::Symbol *>,
1>            _Ax=std::allocator<std::pair<const ustring,OSL::pvt::Symbol *>>,
1>            _Secure_validation=true,
1>            _Traits=stdext::_Hmap_traits<ustring,OSL::pvt::Symbol *,ustringHash,std::allocator<std::pair<const ustring,OSL::pvt::Symbol *>>,false>
1>        ]
1>        C:\Program Files (x86)\Microsoft Visual Studio 9.0\VC\include\hash_map(88) : see reference to class template instantiation 'stdext::_Hash<_Traits>' being compiled
1>        with
1>        [
1>            _Traits=stdext::_Hmap_traits<ustring,OSL::pvt::Symbol *,ustringHash,std::allocator<std::pair<const ustring,OSL::pvt::Symbol *>>,false>
1>        ]
1>        d:\projects\graphics\oslproject\osl\src\liboslcomp\symtab.h(258) : see reference to class template instantiation 'stdext::hash_map<_Kty,_Ty,_Tr>' being compiled
1>        with
1>        [
1>            _Kty=ustring,
1>            _Ty=OSL::pvt::Symbol *,
1>            _Tr=ustringHash
1>        ]
1>C:\Program Files (x86)\Microsoft Visual Studio 9.0\VC\include\xhash(654) : error C3849: function-style call on an expression of type 'const ustringHash' would lose const and/or volatile qualifiers for all 2 available operator overloads

I was hoping SP1 might of corrected something in the stdext::hash_map but it didn't seem to help.

I haven't dug in really deep yet to track down exactly whats going on yet. I will probably try and do that later tonight.

I am running Windows 7 x64 and using the project files generated from CMake 2.8.0.

Jeremy

On Sun, Jan 17, 2010 at 5:39 PM, Oleg <ode...@...> wrote:
Hi Jeremy,

I'm using the following versions of flex/bison:

 - flex,    GnuWin32 distribution, version 2.5.4
 - bison, GnuWin32 distribution, version 2.4.1

and having the same problems. I have simply commented out <unistd.h>
includes and compiled the corresponding files again. The another
problem is that this flex version cannot use slashes as path separator
for generated files, so I have replaced slashes by backslashes for
every flex file.

The "access" function is defined in "io.h" header file under Windows,
so I have changed the "oslquery.cpp" file as follows:

#ifdef __unix__
   #include <unistd.h>
   #define EXIST F_OK
   #define EXEC  X_OK
   #define WRITE W_OK
   #define READ  R_OK
#else
   #include <io.h>
   #define EXIST 00
   #define EXEC  01
   #define WRITE 02
   #define READ  04
#endif

The "hash_map" class is defined in "stdext" namespace under Windows/VS
2008. I think you can use it without SP1, but I'm not sure.

Regards,
Oleg


On 17 Jan., 22:52, wormszer <wo...@...> wrote:
> I too have been trying to build under windows and ran across the same
> problem with the t variable.
> Assuming gcc allows it for some reason, by default is_closure() is
> false so that is what i set it too.
>
> I am having trouble with some includes particulary
> #include <unistd.h>
>
> I have one error in oslquery a missing R_OK which is defined i believe
> through this file.
> I can dig it up and add it but I think i will run into more problems
> later on in the other projects.
>
> I am also getting a hash_map error when building oslcomp.
>
> What version of flex and bison are you using? I had found a gnuwin32
> builds of both but flex was pretty out of date.
> I have installed cygwin to use the latest versions from there to run
> flex and bison. Which generates files that have better includes
> <iostream> vs <iostream.h> etc.
>
> Hopefully we can get this figured out.
> I am using visual studio 2008 as well. I just realized i might not
> have sp1. I will update and see if that helps at all.
>
> Thanks
> 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.






<ATT00001..htm>

--
Larry Gritz




Re: Arbitrary derivatives

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

Well put, a very concise explanation of the basic idea.

-- lg


On Jan 19, 2010, at 7:09 AM, Henri wrote:

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 at http://jgt.akpeters.com/papers/Piponi04/ for a complete
reference.


Hopes this helps

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


Re: Arbitrary derivatives

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

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

Henri <henri...@...>
 

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 at http://jgt.akpeters.com/papers/Piponi04/ for a complete
reference.


Hopes this helps

Henri


Thanks.


Arbitrary derivatives

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

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.


Re: Compiling OpenShadingLanguage under Windows

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

You're quite right, Chris. I think this is just a bad cut-and-paste from the distant past and was never symptomatic, but definitely is wrong.

-- lg


On Jan 16, 2010, at 2:50 PM, Chris Foster wrote:
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?
--
Larry Gritz
l...@...


Re: Compiling OpenShadingLanguage under Windows

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

On Tue, Jan 19, 2010 at 2:48 PM, Wormszer <worm...@...> wrote:
For doing a gpu version of a shader this might work
A GPU only version is definitely interesting, but a very big job :)

but as a stand-in for
the C99 math i don't think it would be a good solution.
Heck no! Instead I imagine that most of the functions can be easily
implemented in terms of existing C89 functionality. For instance, AFAIK the
double version of log2 exists in C89, so

float log2f(float x) { return log2(x); }

even if I'm mistaken, natural log definitely exists, so you could use
something like

float log2f(float x)
{
// log2(x) = log(x)/log(2) ~= 1.4426950408889633 * log(x)
return 1.4426950408889633 * log(x);
}

~Chris.

4921 - 4940 of 5005