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

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

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

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

Thanks Chris, I got the defines included but after searching around and trying some various things I have been unable to find a solution to the missing math functions. The closest I got was to using

These are all C99 math functions, not available on windows I guess... I had a look in boost (they implement some of the C99 functions there) but unfortunately these ones aren't implemented yet

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

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

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

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

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

aaa))))that is sooooo cool))thx) http://gwy.in/jokesoffice

I do a most of my day-to-day development on Snow Leopard, so I know this can be made to work. Are you building OIIO by checking out the "external" project and trying to build the whole thing? If so,

Hi Chris, Thank you very much for your reply. It works! Here comes the next problem compiling the "osllex.cpp" file generated by flex from "osllex.l"