Hi Jeremy, I have installed the latest cygwin version and was able to process all flex/bison files. The cygwin flex version can handle "/" as path separator, too :-) Apart from that I had the same

I tried the first link you mention but i end up with a different set of errors. What did you do to get it working? I will play with it some more and see. I got the defines enabled by defining the

After looking at ATI's open cl I think its a little bit overkill. From initial look i think we would have to create kernels for each math function we wanted as well as create an open cl context to

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

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

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

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

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

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

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

Well put, a very concise explanation of the basic idea. -- lg -- 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

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

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

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

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

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

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,

"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

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,