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.
Who gets support?
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.
Ok, What Do I Do First?
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.
Which Forum Do I Use?
- RenderMan ProServer: This forum is for questions and problems involving RenderMan features, performance, etc. Typically users running a render farm or rendering RIBs may have questions here.
- RenderMan Plug In Development: RenderMan is flexible and allows for the creation of plugins for custom solutions, pipeline tools, and more. For software developers writing these solutions, we encourage you to use this forum for questions about the API, implementation, and general troubleshooting.
- RenderMan for Houdini: This forum is for users seeking help using RenderMan through Houdini
- RenderMan for Maya: This forum is for users seeking help using RenderMan through Maya
- RenderMan for Katana: This forum is for users seeking help using RenderMan through Katana
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.
Can't I Just Email You?
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.
Does My Thread Go Into Purgatory?
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.
How Is My Problem Classified?
There are a few categories that your request will probably fall into and this will determine the type of support and requested materials.
- A bug: This is something that doesn't work as it should, creates garbage results, or simply fails to work.
- An artifact: This may be a visual result of a bug or possibly a misuse of a parameter or option. We can help you determine which.
- A performance problem: Maybe you updated recently and older scenes are suddenly performing poorly, or a feature you've used before is not working as well as you'd expect. This can be the result of a bug, misuse of a parameter, a regression, sub-optimal choices in a plugin, or deprecation of a feature you might have missed.
- A feature request: Please note that we do track and collect feature requests. Making the software better relies on listening to the user! If you require a feature then this may be the place to begin the discussion but note that feature changes and additions are based on the feedback we get from all our customers and that custom solutions fall into the category of consultation and not support. Please contact us directly for these projects, maybe we can work on a solution with you or maybe we have one nearly ready we can refine with your help!
How Can I Get the Fastest Response?
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:
- Describe the problem to us:
- Looking at the above classifications, what type of issue are you having?
- Is it deterministic? (Does it happen every time without exception?) Or is it random but consistent enough to try and isolate the workflow? ("It crashes about 15% of the time")
- What steps do you take to reproduce the problem?
- Can you attach an image to show the artifact? A simplified image is best but if you cannot do that and the image is under NDA, please contact us on the forum to get a secure FTP login.
- Is the performance problem on a non-trivial scene? (Something that takes quite a few minutes to render.) What was the performance you expected? What was the historical result you've had before?
- Details about your environment are also useful, is this Linux? Windows? What version of the Operating System are you using? What other tools? The version of RenderMan and the plugin used to generate the file? Did you try a different or newer version?
- Common files we may request (in no particular order)
- A RIB file: This exported file should be renderable from a self-contained package if at all possible. You may use "find and replace" in a text editor to create relative file paths in the ASCII RIB file and then .zip it up. We can then extract the archive and simply render to see what you're seeing.
- A file from the bridge product: Maybe you have a UI error in Maya or a connection seems to fail to export in Katana. A simplified example from the product with the needed parts to reproduce it will help us find the problem.
- A render log: You may increase the verbosity settings for rendering and render again, you can then provide us with this report. Please note that stack traces are nice but a reproducible example is typically required.
- The .xml render stats: Especially for performance issues, this might help us further refine the problem areas and expected results.
- Any additional files we may ask for later if in our investigation we find we're missing something useful like a particular python tool, OpenVDB assets, or plugin code you own.
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.
Ok, You Have My Files, Now What?
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.
The Producer Is At My Door With a Pitchfork and I Can Hear Clients Gathering
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.
How Can I Check What's Been Fixed or Changed?
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!