Non commercial renderman?

[koen vroeijenstijn]

Hey guys,

any plans to support this?

cheers,
Koen

[john haddon]

I don't think I can speak about Image Engine's rendering plans, but since we already have pretty thorough support for 3delight, there's already a very good springboard in place for supporting PRMan, should any enterprising individuals out there want to have a go…

Cheers…

John

[Vincent Olivier]

On Wednesday, March 25, 2015 at 7:18:35 AM UTC-4, john haddon wrote:

should any enterprising individuals out there want to have a go…

i would like to give it a try

where should I start ? any pointers ?

I tried (yesterday, quickly) to compile on Mac OS X 10.10.4 and it didn't work . Maybe I should start with that.

Any plan on a release based on Cortex 9 ?

Regards,

Vincent

[john haddon]

On Wednesday, July 22, 2015 at 8:06:29 PM UTC+1, Vincent Olivier wrote:

i would like to give it a try

Cool!

where should I start ? any pointers ?

The first thing to do is to compile Cortex, specifying RMAN_ROOT on the command line to point to where RenderMan is installed. I would recommend using my build scripts as a reference :

https://github.com/johnhaddon/gafferDependencies/tree/master/build

These run successfully on Linux and OS X (Only tested on 10.7 though) and are what we use in Gaffer's build process for preparing our binary releases. I wouldn't be surprised if you hit problems on OS X 10.10 - if you do please reply with the build commands you used and the exact error message you see.
 

Any plan on a release based on Cortex 9 ?

 All the most recent Gaffer releases have been using beta version of Cortex 9. The next release which should be available over the next couple of days will be built with the release version of Cortex 9.0.0.

Cheers...
John

[Vincent Olivier]

On Jul 23, 2015, at 2:48 PM, john haddon <thehad...@gmail.com> wrote:

The first thing to do is to compile Cortex, specifying RMAN_ROOT on the command line to point to where RenderMan is installed. I would recommend using my build scripts as a reference :

https://github.com/johnhaddon/gafferDependencies/tree/master/build

Looking at this, are the dependency versions important ? For instance could I use OpenEXR 2.2 ?

These run successfully on Linux and OS X (Only tested on 10.7 though) and are what we use in Gaffer's build process for preparing our binary releases. I wouldn't be surprised if you hit problems on OS X 10.10 - if you do please reply with the build commands you used and the exact error message you see.

I will see about it in the next couple of days.

Any plan on a release based on Cortex 9 ?

 All the most recent Gaffer releases have been using beta version of Cortex 9. The next release which should be available over the next couple of days will be built with the release version of Cortex 9.0.0.

Cool I’ll wait for that.

If my understanding is correct, RenderMan (I’m using 20.1) can only render deep images into its proprietary “dtex” format. There is some code available in the OpenEXR repository that relies on some deprecated REYES API for reading dtex and then converting to deep OpenEXR. I wasn’t able to compile this. Do you know if someone somewhere included support for the new RIS API RixDeepTexture into the Cortex/Gaffer RenderMan stack? Because I would probably want to start with that. Is Cortex RenderMan support based on writing RIB archives to disk or (and) does it support rendering via the RenderMan API. Ideally I would avoid rendering RIB and then DTEX altogether and just render via API and convert to OpenEXR in-memory. What do you think about that ?

Thanks!

V

[Andrew Kaufman]

On 07/24/2015 06:55 AM, Vincent Olivier wrote:

On Jul 23, 2015, at 2:48 PM, john haddon <thehad...@gmail.com> wrote:

The first thing to do is to compile Cortex, specifying RMAN_ROOT on the command line to point to where RenderMan is installed. I would recommend using my build scripts as a reference :

https://github.com/johnhaddon/gafferDependencies/tree/master/build

Looking at this, are the dependency versions important ? For instance could I use OpenEXR 2.2 ?

We've started using OpenEXR 2.2.0 at Image Engine, so Cortex/Gaffer should work fine with that version (tested on CentOS 7 with gcc 4.8.3 and 4.1.2).

Cheers,
Andrew

[john haddon]

On Friday, July 24, 2015 at 2:55:28 PM UTC+1, Vincent Olivier wrote:

If my understanding is correct, RenderMan (I’m using 20.1) can only render deep images into its proprietary “dtex” format. There is some code available in the OpenEXR repository that relies on some deprecated REYES API for reading dtex and then converting to deep OpenEXR. I wasn’t able to compile this. Do you know if someone somewhere included support for the new RIS API RixDeepTexture into the Cortex/Gaffer RenderMan stack?

There does appear to be an IECoreRI::DeepImageReader in Cortex using the Rix API already, and there's also an IECore::EXRDeepImageWriter. Andrew should know more about those I think if you have more specific questions.

Because I would probably want to start with that. Is Cortex RenderMan support based on writing RIB archives to disk or (and) does it support rendering via the RenderMan API. Ideally I would avoid rendering RIB and then DTEX altogether and just render via API and convert to OpenEXR in-memory. What do you think about that ?

Cortex does everything via the RenderMan API, whether that writes a RIB or does a render directly is determined by the argument you pass to the IECoreRI::Renderer constructor, which in turn controls the argument to RiBegin. In Gaffer, for batch rendering we write a small RIB containing the basics like cameras and coordinate systems and then use a procedural to generate the full scene at render time. For interactive rendering everything is done via the RenderMan API directly - there's no RIB.

I'm not sure what you mean by avoid rendering DTEX and convert to OpenEXR in-memory. My understanding of it is that OpenEXR is an API for reading/writing an on-disk format. I presume you could write your own display driver for PRMan if you wanted to render deep data to memory, and avoid all file generation at all. Gaffer uses a similar display driver for interactive rendering, but it doesn't support deep data (Gaffer in general has no support for deep images at present).

Hope that helps…

Cheers…

John

[Alex Fuller]

Hi,

I've somewhat started RIS support to IECoreRI, more specifically I'm just jotting down on a notepad what needs to be done. I've added 2 new shader types 'bxdf' and 'pattern' with the right calls to RI with plans to rig this up into Gaffer somehow. Also lights need special treatment as they're now just 'Geometry' area lights, need to look into that further if it needs more API love.

The standalone server release actually supplies a whole bunch of XML files called 'args' so naturally if you make some xml parser these could be made to automatically create the nodes and the correct plugs/attributes in Gaffer, as well as the settings RIS needs like what integrator to use. I'm not too sure if this parser should live in IECoreRI though next to SLOReader, and what it should be implemented in (I think boost has some property tree header for this, or I'll drop in rapidxml or be lazy and just use some Python module). Thoughts?

To get it compiling out of the box using PRman I needed to do a bit of patching, I guess that code path has gone stale with 3Delight being the focus... :) I think I needed to de-const cast a bunch of stuff that interfaces with ri.h like some c strings and implement a quick and dirty callback for freeing procedurals or something. (I'm learning this whole Renderman spec as I go). Also there's a bunch of hard-coded strings to '.sdl' shaders which are 3Delight-specific, not too sure if that's a problem yet I'm guessing it is, if you want to use the Reyes path with PRman...

[john haddon]

On Wednesday, July 29, 2015 at 2:22:08 AM UTC+1, Alex Fuller wrote:

I've somewhat started RIS support to IECoreRI, more specifically I'm just jotting down on a notepad what needs to be done. I've added 2 new shader types 'bxdf' and 'pattern' with the right calls to RI with plans to rig this up into Gaffer somehow.

Cool! That definitely sounds like the right approach. Feel free to send us a pull request as soon as you think that first component is ready.

 

The standalone server release actually supplies a whole bunch of XML files called 'args' so naturally if you make some xml parser these could be made to automatically create the nodes and the correct plugs/attributes in Gaffer, as well as the settings RIS needs like what integrator to use. I'm not too sure if this parser should live in IECoreRI though next to SLOReader, and what it should be implemented in (I think boost has some property tree header for this, or I'll drop in rapidxml or be lazy and just use some Python module). Thoughts?

XML? Ugh! So there's no equivalent to the SLO API for the new RIS shaders? Assuming XML is the only way, those are very good questions you raise. As you say, IECoreRI provides an intermediate loading step via the SLOReader, which is used in Gaffer to load shaders onto the RenderManShader node. In the past it's been very useful to use SLOReader on its own in various scripted bits of pipeline, but going forward I see Cortex being used less and less in this direct way, and see it becoming used primarily through Gaffer. The ArnoldShader node actually loads Arnold shaders directly anyway, so there is precedent for a more direct approach, and unless anyone else has a strong use case for an intermediate RISShaderReader I'm inclined to keep things simple and do the loading direct in the shader node. Although I'm ignorant of the details, my initial feeling is that the loading should be done in C++ using boost property trees as you suggest. Although loading isn't terribly speed critical, converting Gaffer graphs into shading networks at render time can be, so we need at least that part of the shader node to be C++. So it just seems cleaner to keep the loading in C++ too.

On a slightly wider note, what are folks' opinions on GafferRenderMan now that RIS is here? I had originally hoped that nodes like RenderManAttributes would provide the core set of attributes from the RenderMan spec, and then nodes like PRManAttributes and 3DelightAttributes would add on renderer specifics. But it feels like it might make sense to have a clean break, with RISAttributes and RISOptions existing totally separately. Since both 3delight and PRMan seem to be diverging, is there much benefit to shared nodes any more? And is REYES even worth supporting? Should there be separate GafferPRMan and GafferDelight modules?

To get it compiling out of the box using PRman I needed to do a bit of patching, I guess that code path has gone stale with 3Delight being the focus... :) I think I needed to de-const cast a bunch of stuff that interfaces with ri.h like some c strings and implement a quick and dirty callback for freeing procedurals or something. (I'm learning this whole Renderman spec as I go). Also there's a bunch of hard-coded strings to '.sdl' shaders which are 3Delight-specific, not too sure if that's a problem yet I'm guessing it is, if you want to use the Reyes path with PRman...

I'm aware of some hardcoded use of 3delight stuff in the test cases, but hopefully not in the library itself. In any case, please feel free to drip feed these small fixes to us as you come across them.  

 

Thanks for showing an interest in this - RIS support is definitely something that would be very cool to have in Gaffer…

Cheers…

John

[Alex Fuller]

Here's the info on them:

http://renderman.pixar.com/resources/current/RenderMan/rmsArgsFormat.html

I'm not at work but I think I'm just creating the shaders like Arnold/Appleseed but filling in their parameters would need to be sourced from somewhere to pick the right Bxdf/Pattern shared lib to use eg. "PxrDisney" or "PxrTexture", which would be filled into _handle as a c-string like this:

https://github.com/ImageEngine/cortex/blob/master/src/IECoreRI/RendererImplementation.cpp#L1368

There might be some function in a header to query them though instead of relying on the XML.

Cool! That definitely sounds like the right approach. Feel free to send us a pull request as soon as you think that first component is ready.

As for sending patches back I had issues with github from work but I'll look into it, I'll push at least the trivial fixes like the de-consting casts as they're just made so that it would compile. I'll see if I can run some test to see if that freeing of a procedural is the right thing, passing some void pointer to C's free function feels iffy to me...

Cheers

[Vincent Olivier]

I hope I will be able to look at it later this month because I am still strugling to install Renderman 20.2 on non-RPM Linux machines (with Arch Linux as a distro).

Regards (and sorry for the delay, but you know this being non-commercial and all),

Vincent