Fwd: Pixar removed Reyes and RSL from Renderman 21!

[Hradec]

Hi guys.. 

not sure if you guys are aware, but pixar removed rsl and reyes from prman 21!!

https://rmanwiki.pixar.com/display/REN/RenderMan+21.0#RenderMan21.0-ReyesRenderingisRemoved

As you can guess, Cortex won't build since it can't find all the SLO related headers. 

just a heads up! 

I'll be investigating and trying to fix cortex build as time permits, but any pointers you guys can give is greatly appreciated!

cheers...

-H

[Andrew Kaufman]

Haha, I guess they didn't consider the impact to Cortex when they removed it... Presumably you'll need to patch the SConstruct like we do for the other conditional features and use the newly defined IECORERI_WITH_RSL to #ifdef a few files.

Andrew

--
--
You received this message because you are subscribed to the "cortexdev" group.
To post to this group, send email to cort...@googlegroups.com
To unsubscribe from this group, send email to cortexdev-unsubscribe@googlegroups.com
For more options, visit this group at http://groups.google.com/group/cortexdev?hl=en
---
You received this message because you are subscribed to the Google Groups "cortexdev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to cortexdev+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--

Andrew Kaufman - R&D Lead

Image Engine

studio: +1 (604) 874-5634 | and...@image-engine.com | www.image-engine.com



15 West 5th Avenue, Vancouver, BC, V5Y 1H4, Canada

If you are not the intended recipient, disclosure, copying, distribution and use of this email is prohibited. Please notify us immediately and delete this email from your systems. You may contact us at in...@image-engine.com if you do not wish to receive further commercial electronic messages. We may still send you messages for which we do not require consent.

[John Haddon]

Hi Hradec,

Thanks for bringing this up. It's an interesting time, because 3delight is actually moving away from the RenderMan API, and using a new NSI API they've cooked up. And PRMan is moving so far away from the RiSpec that it's not really a shared API any more anyway. And at the same time, as part of Gaffer development we've also defined a replacement for the IECore::Renderer backend API which we intend will replace the old one you're used to, so that we can better support IPR and threading.

Here's the current situation in Gaffer :

Arnold : Using new Gaffer backend

Appleseed : Using new Gaffer backend

3delight : Using legacy Cortex backend, need a new backend going to NSI

PRMan : Could almost use legacy Cortex backend, but really needs new backend dedicated to PRMan.

So, going forward I see IECoreRI becoming purely about supporting PRMan, and a new IECoreDelight supporting 3delight. Right now only the Arnold and Appleseed backends are under active development though...

Cheers...

John

[John Haddon]

So, what I was really trying to say was that depending on your level of interest and available time, it might be more beneficial to develop a new PRMan-specific backend for Gaffer...

[Hradec]

Haha, I guess they didn't consider the impact to Cortex when they removed it... Presumably you'll need to patch the SConstruct like we do for the other conditional features and use the newly defined IECORERI_WITH_RSL to #ifdef a few files.

Yeah... how inconsiderable of then!! :P lol

I'll do that!! thanks Andrew!!

 

[Hradec]

hummm... that's unfortunate... essentially Cortex is kinda "dropping" support to prman since no-one currently uses then together!

We are currently using renderman, but we didn't commit 100% to it yet. 

Maybe I should start looking at Appleseed more seriously, since I'm not sure I'll have the bandwidth to commit on support a prman backend by myself. 

[Andrew Kaufman]

Brave man. We've got Appleseed running here, and used it to lookdev that Gaffer robot (in the gaffer doc tutorial), but we've never run a full show with it.

Another route could be to mention to the software vendor that last thought about committing to PRMan or not... and mention that if they added Gaffer support you'd be more inclined to commit.

Just a thought...

--
--
You received this message because you are subscribed to the "cortexdev" group.
To post to this group, send email to cort...@googlegroups.com
To unsubscribe from this group, send email to cortexdev-unsubscribe@googlegroups.com
For more options, visit this group at http://groups.google.com/group/cortexdev?hl=en
---
You received this message because you are subscribed to the Google Groups "cortexdev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to cortexdev+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[John Haddon]

hummm... that's unfortunate... essentially Cortex is kinda "dropping" support to prman since no-one currently uses then together!

While we're on the subject, a lot is changing about the way we use Cortex at Image Engine. We haven't used a Cortex procedural for a long time now, since all our scene generation has been done through Gaffer. We're also transitioning away from much of Cortex's image/color code in favour of an OIIO/OCIO/Gaffer combo. This does mean that some parts of Cortex will become essentially unmaintained (or even be removed) unless someone else wants to step up and take some ownership.

It's hard to know how best to approach this, because we're somewhat in the dark as to where and how Cortex is used outside of Image Engine. We don't want to leave anyone in the lurch, but at the same time, we're overdue an overhaul to reflect Cortex's changing role and the appearance of other open source libraries that undoubtedly supercede it in certain areas.

If you have any thoughts on this, I'd love to hear them.

Cheers...

John

[Est]

Maybe I should start looking at Appleseed more seriously, since I'm not sure I'll have the bandwidth to commit on support a prman backend by myself.

Please do. Appleseed is far from being a replacement for renderman and I don't think that's even in our plans for the project.

But depending on what you want to do appleseed might work for you or can be adapted to what you need to do without much effort.

Est.

[Hradec]

Brave man. We've got Appleseed running here, and used it to lookdev that Gaffer robot (in the gaffer doc tutorial), but we've never run a full show with it.

HAHAHAHA... I was going to ask if you guys used it production!! thansk for asnwering! :)

 

Another route could be to mention to the software vendor that last thought about committing to PRMan or not... and mention that if they added Gaffer support you'd be more inclined to commit.

 

Hummm.. that's a good idea, but considering we're a very small studio in Brazil, I don't think our license requirements would "pay" for that... But doesn't hurt to ask! :)

To be fair, although renderman has dropped support to SLO/RSL, their 21.0 API seems to be pretty consistent with the old 20 and 19 api!

Our current use of Cortex is being mostly on rendering procedurals from maya, so for that we're covered. I'll probably have to do some work on replacing the SLO reading by a RIS bxdf/pattern reading of .so to make it work again. 

About this new Gaffer render backend for Arnold/Applesed:

1. are you guys changing IECore::Rendering? 

2. or is there a new Gaffer specific class that implements the new backend, and IECore::Rendering will keep on going, holding the old cortex backend?

[John Haddon]

On 11 December 2016 at 20:17, Hradec <hra...@gmail.com> wrote:

1. are you guys changing IECore::Rendering? 

2. or is there a new Gaffer specific class that implements the new backend, and IECore::Rendering will keep on going, holding the old cortex backend?

At present, we use IECore::Renderer for the RenderMan support in Gaffer, but use a new IECoreScenePreview::Renderer class for the Appleseed and Arnold support. Our intention is to move this second class to Cortex to replace the first one at some point, and reimplement separate PRMan/3delight subclasses for it.

If this is going to cause a problem for you (or anyone else), we should talk about ways of supporting the old procedural workflow temporarily while still allowing the necessary Gaffer support work to be done on Cortex.

Cheers...

John

 

[Hradec]

While we're on the subject, a lot is changing about the way we use Cortex at Image Engine. We haven't used a Cortex procedural for a long time now, since all our scene generation has been done through Gaffer. We're also transitioning away from much of Cortex's image/color code in favour of an OIIO/OCIO/Gaffer combo. This does mean that some parts of Cortex will become essentially unmaintained (or even be removed) unless someone else wants to step up and take some ownership.

I totally understand! The only thing that concerns me is the "be removed" part!  As long as unmaintained goes, that's make sense. If someone is using an unmaintained component, they will HAVE to take ownership to make changes or fix things if they want to keep using. 

But the removing part is concerning, since that would mean people would have to branch cortex to maintain the removed bits...  

 

It's hard to know how best to approach this, because we're somewhat in the dark as to where and how Cortex is used outside of Image Engine. We don't want to leave anyone in the lurch, but at the same time, we're overdue an overhaul to reflect Cortex's changing role and the appearance of other open source libraries that undoubtedly supercede it in certain areas.

I can see that... but again, I think the biggest issue is removing parts of it. 

1. If you're going to replace a feature in cortex by a newer mechanism, that's ok as long it offer the same functionality in a different way. People would just have to "fix" they code to work in the new mechanism!
   
   
2. if you want to replace a cortex part by another open source library that does the same but better, again, people only have to "fix" they code. 
   
   
3. but removing an unmaintained piece of code which has no other replacement, it's a big problem for the code which depends on that. 
   

One example is the IECore::Renderer and the IECoreScenePreview::Renderer. 

I known very little about the SceneCache mechanism at this point, so I can't say if I could use the IECoreScenePreview::Renderer to "fix" our procedurals. 

Maybe running our procedurals in a pre-rendering step to generate a SceneCache, and use that sceneCache for rendering? 

Or maybe we could even run our procedurals at rendertime using a Live SceneCache?

Another question from the top of my mind would be: Can I sceneCache particle caches? I saw methods for geometry, transform and attributes, but nothing for point geometry. (maybe the writeObject does it... can't say since I didn't had much success exporting a scene from maya yet!!)

In this case, the ultimate question is: Does IECoreScenePreview::Renderer offers the same functionality (in a different way) as  IECore::Renderer, so it could be used in a procedural? (which falls into the "1." category)

make sense? 

just to conclude, as long as you guys avoid from removing unmaintened code, you should be good. 

If removing is definitely necessary, maybe a "contrib" mechanism would be a good fit here, so all unmaintened code that needs to be removed could go into a "legacy" folder which people can choose to build together with cortex in the same way contrib is done. 

So whoever needs the "legacy" code, would be responsible to make sure it compiles, and maintain it if they need! That way we avoid the branching!?

my 2 cents.. 

cheers...

-H

[John Haddon]

I totally understand! The only thing that concerns me is the "be removed" part!  As long as unmaintained goes, that's make sense. If someone is using an unmaintained component, they will HAVE to take ownership to make changes or fix things if they want to keep using. 

But the removing part is concerning, since that would mean people would have to branch cortex to maintain the removed bits...  

In the "removing" scenario, I think the most likely approach would be that we'd manage a maintenance branch for Cortex 9, so for those wanting to stick with the old version, there would be very little burden. The big changes would be made on the master branch, and the burden would be on the core developers to backport critical fixes back to the maintenance version where requested. So I probably made it sound a little more drastic than I needed to.

One example is the IECore::Renderer and the IECoreScenePreview::Renderer. 

I known very little about the SceneCache mechanism at this point, so I can't say if I could use the IECoreScenePreview::Renderer to "fix" our procedurals. 

The IECoreScenePreview::Renderer and the SceneCache mechanism are totally different things - one doesn't require the other. In principle there's no reason we can't make Python procedurals work with the new renderer backends, but I would encourage you to consider building procedurals as Gaffer graphs instead - they provide vastly improved performance and can be made much more user-friendly than a Cortex procedural. I'm aware of one studio experimenting quite successfully with Gaffer as a lookdev engine, but then exporting those setups to be used as procedurals in a more traditional Maya lighting environment, so it can definitely be done.

 

Another question from the top of my mind would be: Can I sceneCache particle caches?

Yes, you can write any Object subclass into a SceneCache.

 

If removing is definitely necessary, maybe a "contrib" mechanism would be a good fit here, so all unmaintened code that needs to be removed could go into a "legacy" folder which people can choose to build together with cortex in the same way contrib is done. 

So whoever needs the "legacy" code, would be responsible to make sure it compiles, and maintain it if they need! That way we avoid the branching!?

I suspect that the overhead of managing a maintenance branch might well be lower than that of trying to keep the contrib/legacy stuff working on the master branch. It's the model used in projects like OIIO and OSL, and they seem to be making it work pretty well...

Cheers...

John