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

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

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

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,

"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

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,

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

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

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

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

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

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

Well put, a very concise explanation of the basic idea. -- lg -- Larry Gritz l...@...

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

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

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

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 -- Larry Gritz l...@...

A GPU only version is definitely interesting, but a very big job :) Heck no! Instead I imagine that most of the functions can be easily implemented in terms of existing C89 functionality. For

Oh yes, I've written AA'd versions of many of these at various times. "aastep" (aka "filterstep" in RMan-land) is there mostly for historical reasons. Other aa functions are a little trickier and

Yes, exactly. It's in the road map to eventually allow closure primitive functions and integrators to be written in OSL. But for now, both are built into the renderer. -- Larry