In a perfect world, artists and technicians would be just psychic enough to never need help, but in reality we could all use some support time to time. This document will help you decide the best source for your support and how to make the most of it.
Users in the non-commercial forum rely on community support. While RenderMan support and engineers may visit the forum to help out as part of the RenderMan community, support is not provided to non-commercial license holders.
Commercial users of RenderMan with paid maintenance have access to the commercial support forums. Site licenses and special projects may have their own forum to discuss NDA-protected content.
An administrator will be given login credentials for this forum, other users can be added at their request. We encourage studios to provide the right amount of users with access but not too many to prevent duplicate requests and general noise. Please help us keep this user list current to protect your content and value. Should you use a central login and password, know that users no longer at your facility may still access the forums with that information.
If you have a problem we suggest you begin with the documentation. You can complete a search for topics, node descriptions, and more. If your question is not answered here, please come to the forum and take a look. Maybe someone else has had this issue. Don't see it? Ask away! It may be that we can add the general solution to the documentation for you.
Once on the forum there are some helpful things to provide to us so that we can get you the best help the most quickly.
There may be some overlap in your topics, if we feel it may be better served in another area we may move the post for you or suggest you make another post somewhere else to further refine a problem.
Our forum is designed to tie into our triage and ticketing system. Even if you were to email us, we will likely request you create a forum thread anyway. This way we can track a problem, compare it, and share it with engineers more easily than forwarding a mess of emails.
Of course not! We handle multiple requests at a time and triage these based on several criteria (we'll get to that shortly). This may mean you won't see an immediate reply, but rest assured we take time to go through the forums and look at each and every commercial forum thread. We then create tickets to follow up and investigate issues. There are ways to speed up this process that will be described below.
There are a few categories that your request will probably fall into and this will determine the type of support and requested materials.
We understand that extracting examples and scenes from a pipeline to deliver to support can be time consuming, especially for complex scenes, but we recommend that you attempt to do so. Without a reproducible example we'll be making guesses and that's not good for your production. Of course it goes without saying we need a useful description of the problem. Below are some hints on how to get the best service:
After looking at this list and example issues, you may be able to get away with more or less data based on your problem and we always encourage you to create an example using the least amount of objects at a time. If you can show us the problem with a sphere on a plane then that's great! If not, then we understand, it just may take us some more time and a little back and forth to be sure we have the right issue reproduced.
Problems that are easy to reproduce, visualize, and share will typically get you the quickest response. We understand that in production you might feel compelled to go fishing on the forum by asking, "Has anyone seen this...?" hoping for a quick solution but this is reasonably rare for most cases and you may end up trying multiple suggestions to no effect which may waste valuable production time and frustrate the artist.
Once you've posted to the forums, we go through a triage process. You may wonder what this is like so here's a simple explanation:
At scheduled times we will go through the commercial forums, every new thread, and either answer a thread immediately if the answer is known to us already or assign it a ticket to evaluate the problem. If you've described the problem with enough detail and have added the necessary files to identify and reproduce the problem, it typically goes right to an engineer to diagnose. This process may take some time based on the complexity of the problem, the current log of issues, and more. Even if we can identify a problem immediately, we may spend time trying to find the best response. We are interested in correctly engineering a solution rather than a quick patch to a hole somewhere. In some cases we may need to work with you if the fix requires a behavior change of the renderer or an API change.
We may also ask for more files or data as we progress. The ticket will be put on wait until we hear back from you. You may have been given this ticket number or you may request it. This is so you can reference the problem in our system later if you need to. However, the forum will track the issue with the thread itself, having the ticket is a convenience for you later should you need to revisit the problem in the future.
Once we have a solution we should follow up with you on when you should see this, usually the next point release for most fixes. For complex issues with a current solution or workaround we may move the final solution to a major version, such an example is something that requires an API change.
Once in awhile a problem arises at the worst possible time. Do you have a delivery 20 minutes ago? We understand what this is like. Please tell us that this issue is a showstopper and rate the critical nature of the issue. This helps us re-prioritize your support and possibly look at other solutions as a stopgap to get your project complete on time. This may involve some unsavory temporary hacks, but we will alert you to the nature of our temporary solution and its drawbacks. We can then implement a true solution for your problem in the near future but you will be able to deliver.
Please don't delay in seeking help for persistent problems! While we expect you will troubleshoot on your own (maybe 15 minutes of massaging a scene solves it instead of 4 days of forum exploration) some issues may be too complex for you to solve and we have no interest in seeing users suffer. Internally you should triage your issues and decide what it most important and what you cannot solve on your own. Even if you suspect user error but cannot verify it, we may be able to help you determine the cause. In the event it is user error, maybe we can clarify the correct workflow in the documentation to avoid this in the future.
Maybe you're a version or two behind and want to see if something you're struggling with was addressed recently, head on over to the release notes and see!
Support That Matters
At the end of each day we hope you can go home on time and look forward to another day of creating, solving artistic challenges, and knowing the tools are there to support you and your goals. We're excited to see the amazing work you produce using RenderMan and the awards and accolades our customers have earned over the last 30 years inspires us to continue to do more–with our customers.
-The RenderMan Team
For those of you wondering about this development process from Pixar to you, maybe this fun beer example will help (because beer always helps)
Imagine you've made the best automatic beer delivery system for your home. At the touch of a button a machine brings you a frosty bottle from the fridge to the livingroom. I think you can agree that such an invention would be in high demand! Well, sure enough your friends come over to visit and they get to see it in action. Wow! Can they get one too?!
Sure, you say. You'll get started on that.
But wait, one of your friends buys beer in a can, not a bottle. Can you make that work?
Another friend has his seating area upstiars, can this deliver beer up a flight of steps?
A different friend has a side by side fridge, so his beer is on a different shelf, what about that?
A friend of a friend doesn't drink beer, can it deliver milk?
Oh, well...ok that gets kind of complicated doesn't it? What's happened is you've gone from a very specific pipeline problem (your fridge to your couch) to needing a general solution (whatever beverage to whatever area in houses of different sizes and arrangements). This requires much more research and development to come up with a useful and robust solution to as many scenarios as you can imagine! So many options, so many details, so many requests! This may give you a bit of insight into the world of software development. If you're an artist you may be able to use this example to understand how our partnership can help provide the best overall solutions for artists everywhere and the complexity involved. But we love the challenge!