Is there a release date? sorry I didn’t watch the video yet.
They said they will follow v24. Beta planed for Dec. And release next year. But they did not specify behyond that.
1 Like
Really looking forward to this…i used the previous version for blender & found the feeling of the renderman renders had a quality i really liked…yay.
1 Like
is there a link where we can watch the presentation ?
1 Like
You can watch Pablo commenting on the presentation here … https://www.youtube.com/watch?v=7eCViM4NYK4&list=LLU3ZuvCIb1F8oO_Rdw5AnMg&index=11&t=0s
Here is the original link to the stream … https://app.livestorm.co/pixar-animation-studios/new-bridge-tool?utm_source=Livestorm+company+page
3 Likes
Renderman 24 info to whet your appetite. Presentations in English.
3 Likes
Hi Ian!!! Thank you so much for all your hard work! It looks super well integrated. Very impressive. I’m really curious how you’re getting data in and out between RenderMan and Blender without having to save files? Are you using Sockets?
I watched the video that covers what’s now in RM24. Looks nice definitely. They talk about XPU which turns out to be GPU/CPU agnostic rendering. It’ll be nice to see that up and running.
One of the interesting things I noticed was about ILMs’ layered shading system that’s been implemented in RM24. I have a feeling that Blender people are going to look at it and think, “This is like old-school Cycles nodes.” LAMA is a collection of BXDF nodes that you can string together to make your own shaders. Should familiar? They call it layering but since it’s in the node graph and you’re using similar Mix and Add nodes, it’s very similar to Cycles. I’m sure ILM didn’t steal the idea from Blender (great minds think alike and all) but its fun to see that Blender was always on the right track to begin with. 
One side note about the Blender integration that was not mentioned in the Specific Blender video was that it will be available for Blender 2.8.3 but he let slip that it will also work with 2.9. Since Blender changes so regularly, I feel like it’s important to not get to locked into a single version but be able to more easily roll with the changes.
Brian did a really great job with the previous incarnation of RenderMan for Blender and now Ian is taking up the mantle. Both of these guys are very talented so we should count ourselves lucky that it’s happened more than once and each time with the full support of the Pixar team. 
Thanks guys!
3 Likes
I’m watching Pablo’s commentary on the release video. One thing strikes out at me: Pablo comments on how the new RenderMan had a feature to lower the render resolution in the viewport without changing the size of the window. He says, “Oh man, that a feature that I never new I wanted!” and continues to comment on how cool that feature it. HOWEVER… I suddenly question, could it be that Pablo has never heard of a little feature in Blender called “Pixel Size” under the viewport rollout in the Cycles render panel? It’s usually set to automatic but you can set it for 1x, 2x, 4x, and 8x. This should probably be moved into the viewport so it’s more discoverable. Actually, now that I think about it, wouldn’t it be cool to have a bunch of commonly used Cycles and Eevee parameters in a dropdown up next to the overlays? Hmmmm.
So there you go. A feature you didn’t even know you needed nor did you know you already had it. 
6 Likes
I know this is a blender centric forum but Cycles really wasn’t the first renderer too have node based shading and mixing of bsdfs… So no, ILM didn’t steal the idea from cycles
That said LAMA does look very interesting. Most users may still be more happy using simpled Disney or Principled shaders. LAMA to me looks like a modern and more powerful way to layer bsdfs and maintain physical correctness (which cycles mix and add nodes do not do out of the box).
EDIT: I could be wrong about this but I think SLIM was one of the first tools to do this style of node based shaders: https://renderman.pixar.com/resources/RenderMan_20/slimGettingStarted.html
BTW all the appreciation for Ian is more than warranted. He’s a great guy and seeing this taken up again is heartwarming.
regarding the viewport resolution, we do something with ProRender which is kinda interesting and might be worth visiting for cycles or renderman or whoever. We adaptively change the resolution to match a given “iterations per second” kinda like a FPS target for games. It seems to work quite well.
5 Likes
Hi Brian! Actually I think you need to go back and re-read my comment. I actually said the opposite:
The key word here is ‘Didn’t’.
And yes, node-based shading has been around for ages. Long before Blender ever had it. Obviously I wasn’t suggesting that ILM stole “Node-based Shading” from Cycles. My point was that Cycles nodes are very similar in basic concept to LAMA which is to allow you to assemble your own shaders using the basic components of shading. Mix a Diffuse with a Glossy using a fresnel curve as the mix value and you have a basic BRDF.
While node-based shading has been around for a long time, this idea of this “Component-based Shading” alone is the novel approach I was talking about. Right now, LAMA is seen as being unique because of this but I was merely pointing out that Cycles was originally built that way too. I’m sure LAMA is much more advanced, physically correct, and thorough.
And, I’m sure you know all this too but I just wanted to be clear so other people reading this don’t misunderstand.
That’s awesome! I’d love to see that feature in Cycles too!
While there is that similarity in UI, my suspicion is that LAMA is doing something fundamentally different under the hood, perhaps along the lines of https://lc.fie.umich.mx/~legg/complexlayered.php
Mix a Diffuse with a Glossy using a fresnel curve as the mix value and you have a basic BRDF.
This is actually a really good example of where a simple node mixing approach (what Cycles does) and a physically-based layering approach (possibly what LAMA is doing) will give very different results.
If the glossy component has any roughness to it, mixing between that and the diffuse component via an external fresnel node will give noticably wrong results–increasingly so the rougher the glossy is. Whereas a physically-based material layering system will handle it correctly and give physically plausible results in all cases.
Calling the two systems similar just because of how the user interacts with them is a bit like calling Eevee and Cycles similar because you create models and textures for them the same way. Which is to say, you’re not wrong–there are similarities. But there are also significant meaningful differences, which make the two technologies notably different.
(Having said all of that… I actually don’t know much about LAMA, so I’m largely speculating here. Maybe it’s not actually physically based, in which case none of what I’ve written is relevant.)
2 Likes
Hey, thanks for the tip, I did not know of this feature! It’s especially useful for a 4k monitor.
1 Like
Thanks, Brian! The code that you left behind was a great basis to start with.
Sorry if it wasn’t clear in the presentation. In RenderMan 22 we introduced a new scene graph API that allows us to feed RenderMan from Blender without having to go to disk. The API also allows us to write out to disk (RIB) when needed for debugging and batch rendering purposes.
I also watched Pablo’s video. Yeah, the pixel size sounds like the same thing. I also didn’t realize that the render region could also be used during viewport renders, during the section where I was showing the crop window. He is correct that if I had rotated the view with the camera, the pixels outside of the viewport would not have updated. I’m looking into whether or not I can address that. I think one advantage of our crop window function is that we can move and resize the window after its drawn; this is similar to how the crop window function in our “it” frambuffer works.
I’m hoping the Blender community can help with things like this, so I don’t reinvent the wheel. I’m still relatively new when it comes to Blender, so I don’t know what’s already available.
Ian
12 Likes
Ha! actually, sorry I wasn’t more clear. I understood what you said in the video. I was asking a more technical question. Due to Blender’s licensing, it was my understanding that in order for compiled C code to access Blender’s memory, it needs to be open source too. RenderMan is obviously not open source. I know that there are various ways around this like handing off through Python (which I thought was too slow), making a custom build (like Vray), or communicating through Sockets. I saw a presentation by the RedShift guys who pointed out that it was such a pain that they had to put it on hold.
So, that’s why I was asking about Sockets.
That would have been so funny if you had done a reaction video to his reaction video! 
This is odd to me that you say that because that’s the way it works with Cycles too. If you draw a render region in Blender, only the pixels inside the box get rendered. That’s the way I would expect it to work. I’m not sure why you would want it to do a full-screen refresh just because the camera moved. It’s seems like unintended behavior and I think most people would think that was a bug.
I think what Pablo was referring to when he said, “I wanna see him move the camera.” was more about seeing how fast it refreshes with a complex scene. In that demo, you were basically just changing parameters which is easy enough (relatively). But rotating the camera or scrolling through frames is always more impressive.
EDIT: Lots of typos!
I can’t even install Renderman 23.4 in my Ubuntu-Studio 20.04 machine, I have AMD hardware with proprietary drivers (amdgpu-pro 20.30) and Blender 2.83.4LTS. When I first heard about Pixar taking a look at Blender again I immediately downloaded their latest version, they have a .rpm package instead of a more mainstream .deb, but anyway…After converting the .rpm file to a .deb with alien I got this:
sudo dpkg -i renderman-installerncr_23.4.02090532-1_amd64.deb
[sudo] password for administrador:
(Reading database ... 473501 files and directories currently installed.)
Preparing to unpack renderman-installerncr_23.4.02090532-1_amd64.deb ...
Unpacking renderman-installerncr (23.4.02090532-1) over (23.4.02090532-1) ...
Setting up renderman-installerncr (23.4.02090532-1) ...
Processing triggers for libc-bin (2.31-0ubuntu9) ...
and then stops…
Extracting the .rpm file to a place an the executing the installer from ~/Public/opt/pixar/RenderMan-Installer-ncr-23.4/bin$ I got this:
sudo ./RenderManInstaller
[sudo] password for administrador:
RenderMan Installer[136948]: RenderMan Installer Warning: QSslSocket: cannot call unresolved function CRYPTO_num_locks
RenderMan Installer[136948]: RenderMan Installer Warning: QSslSocket: cannot call unresolved function CRYPTO_set_id_callback
RenderMan Installer[136948]: RenderMan Installer Warning: QSslSocket: cannot call unresolved function CRYPTO_set_locking_callback
RenderMan Installer[136948]: RenderMan Installer Warning: QSslSocket: cannot call unresolved function ERR_free_strings
On some forums they suggested to link some files but that didnt worked either; and now someone said earlier on this forum that Pixar may have plans to launch a v24 beta on December end then an official release next year… So I guess I’ll just have to wait, it is a pain to make it work on Linux ATM 
but I’m really looking forward to try this new version.
So Renderman non-commercial has not software limitation(i.e. render resolution)? You just can’t use it for commercial projects?
Yes, that’s correct.
1 Like
The good thing is that Renderman Commercial License is only marginally more expensive than Redshift. $595 for first year and $250 maintenance.
I only ever got as far as using 3Delight in C4D with its 2 core limitation for rendering point clouds, it was too limited to bother with, an unrestricted demo will allow me to really kick the tyres and see if Renderman is right for my needs.
The excellent Gridmarkets cloud rendering service will support Blender and Renderman so it’s good to know when a project exceeds local processing it can be done in the cloud.
This happens every time with Renderman on Ubuntu. You indeed need to make links for some libaries, since 20.04 the system libraries won’t work though, so I’m using libraries that are shipped with Houdini 17.5.
sudo ln -s /opt/hfs17.5.460/dsolib/libssl.so.1.0.0 /opt/pixar/RenderMan-Installer-ncr-23.4/lib/3rdparty/Qt-5.6.1/lib/libssl.so
sudo ln -s /opt/hfs17.5.460/dsolib/libcrypto.so.1.0.0 /opt/pixar/RenderMan-Installer-ncr-23.4/lib/3rdparty/Qt-5.6.1/lib/libcrypto.so
This fixes the error. It’s might be a bit OT here though, so I’d go to Renderman forums if that still doesn’t work.
1 Like