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

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

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

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

(Obviously this is only a problem when integrating wave into the project source, and that's not really difficult at all.) mcpp looks nice. In some sense, using wave would mean one less

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

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

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

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

Hi Jeremy, Yes, but I've solved them a bit different: just added export macros to the corresponding classes and "implemented" the "Symbol::mangled ()" method inline. I didn't perform any tests so

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

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