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

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

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

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

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

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

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

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

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

(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

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

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

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

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

Meh, I just realized my ambiguous use of "integrator". In this case I meant "party integrating OSL into their system"... Regards, Daniel

Er, I'm not sure. I think this is exactly the kind of thing we will be working out over the next few weeks. When we actually implemented surface integrators, we discovered all sorts of issues we

Thanks so far for the answers, I'm looking forward to seeing OSL progress. Good stuff! Regards, Daniel

Hi all, I've been looking through the OSL source a little, and I'm interested to see that you're using runflags for the SIMD state. I know that's a really conventional solution, but there's an

Awesome, Chris. Would you believe we were just talking internally about this topic yesterday? We were considering the amount of waste if there were big gaps of "off" points in the middle. But I

Is there a good resource on this topic? I did some googling and didn't see what i was looking for. Where is the actual SIMD taking place? Is the compiler figuring it out from the loop and setting up