Behind the scenes: the Corona Renderer development process! | Chaos

Developing something as sophisticated and complex as a mature render engine is no easy task. We thought you would enjoy a look behind the scenes at some of what goes into it, and this time our focus is on how we choose what to work on next, and what kinds of things can affect our plans.

Users Come First

We wanted to say at the outset that you, our users, always come first. It’s you that have helped what make Corona Renderer is today, and shaped how it has developed and what features it includes; and when we think of a new feature that maybe no-one has requested, we do so from the point of view of considering what will benefit most users most often, with a primary (but not exclusive) focus on the daily workflows of arch-viz and product visualization as those are the backbone of what Corona Renderer is for.

With that in mind, let’s take a look at “how development happens” here on the Corona team. It’s a long article, because we take a lot of things into account!

Release of a Final Version

It may seem strange to start at the end, with a final release, but the development of the next version begins before the previous one is finished.

We are always keeping track of new algorithms, new approaches to solving rendering problems, what users are requesting, and of course ideas that we have on our own. You’ll find these on the Tentative Road Map (more on that later) as the “Pool of big ideas” list.

So, as development on one version is wrapping up, we’re already beginning to think about which of those items from the “Big Pool” of ideas are going to be in the next version – and thinking of things that might not be in that “Big Pool” which take priority.

Choosing What To Work On Next

As soon as one version of Corona Renderer is released, then it’s time to update the Tentative Road Map! This is where we take our thoughts as development was wrapping up on the previous version, and decide on the things we hope and plan to work on next. Here, we have to consider the immediate short term of the next release, but also factor in the longer term of the release after that and beyond (Corona Renderer is going to be around for a long time!)

This decision is always a hard one. There are a great many factors that come into play, and there’s no perfect answer on how to do this, but we do the best we can. Here are some of the things we consider when making the decision:

Bugs

These are always high priority. This means that an existing feature is not working properly, which could mean things like:

• An existing feature/existing code causes a crash. The highest priority of all!
• An existing feature does something unexpected that is not what users want or need
• An existing feature does not perform as quickly or smoothly as it should
• An existing feature has something missing that limits how useful it could be

As you can see, even here there is a great variety in how important something could be. We have to assess how much of an impact it has, how often that happens, and how much and how often that interferes with the workflow of our users.

Some of that will be informed by what users tell us, some of it we may have to assess for our ourselves to the best of our ability. For example, we may actually find a bug ourselves without any users reporting it – does that mean it isn’t happening for users since there have been no reports, or it’s happening so rarely that no-one realized it was a bug, or just that people have noticed but no-one has had the time to write it up and report it to us yet.

While a bug usually takes priority over new features, even that depends on our assessment of all those factors. Some are clear, such as crashes, but it may not be clear in other cases – perhaps the performance improvement that could be gained by fixing it is fairly minor, and a new feature would actually be more important for our users.

Weighing it all up

Now it’s time to weigh it all up, bugs and new features together, and decide what we want to work on (or even can work on).

As a formula it might look something like:

(How easy is it to code) x (how clear is the solution) x (how quickly can it be done) x (how many users it would benefit) x (how frequently would it benefit our users) x (how much time and manpower do we have)

Let’s take a deep dive into that.

• Is the fix or new feature easy or hard to implement? Is it just a few lines of code, or many hundreds of lines of code? Can it be done with minimal impact to other parts of the code because it’s fairly isolated, or does it have the potential to cause problems or need rework to other well-established parts of the code, UI, or functionality?
• Can the bug even be fixed, or feature added? The bug or feature may relate to something about how the host software works, which may limit what we can do. In the case of new features, there could be something about Corona’s code that limits what can be done too.
• Is it a hotfix, or can it wait for the next release? If the bug is severe, then it would need a hotfix (an update to the existing version of Corona). This takes priority over work on the next version, so any hotfixing means a pause to working on the new release. For more minor issues, because we have historically usually released two versions a year, we can wait for the next full release, with the bug fix going into the daily builds for those who want to use it in advance of the next release.

• Is there a clear algorithm or solution for that feature? Sometimes the solution is “out there” in principle in white papers and other research, and we “just” (!) have to implement it in our code; but sometimes we will we be “starting from scratch” in figuring out how to make it happen. Even existing algorithms or solutions have some variety though. It might be that it is just a research paper, so would need coding from scratch. Or it might be something that already has been coded in V-Ray for example, and so we can learn from actual pre-existing functioning code. It’s also important to note that sometimes an algorithm that seems revolutionary on paper turns out to work perfectly only in specific scenes or under certain conditions, and doesn’t provide a general solution that works well across all scenes like the ones you create in production. This either means the algorithm can’t be used, or that we have to spend extra time extending the algorithm so that it becomes suited for production use.
• How many people will the fix or feature affect? Just about every user, whether they are new or seasoned, believes that feature X or fix Y is the be-all-and-end-all from the perspective of their workflow and experience, and that’s even if they try to make their guess at how many others will run into the issue or benefit from the feature. That’s only natural. We have to have a global view and try to assess what it means for all of our customer base as a whole, and in general we have a better view of the customer base and how they use the software than any given user (don’t be offended, but it’s true!).

• How often do people run into needing the fix or feature? This factor multiplies with the previous: something that doesn’t happen often but happens for most of our users has to be compared with something that happens often but only for a select few users in specific cases. Again, we have to do our best to come up with a fair assessment of that – here too, for particular users a feature may seem like a must, but for others it would be irrelevant. We could pick supporting foam in Phoenix FD as an example – many people don’t use Phoenix FD at all; some use it but rarely; some use Phoenix FD but still have no need for foam in their projects; some use it more often, and would indeed benefit from foam support. It’s our job to compare that with something else completely different, say “making rendering faster when using HDRIs”, which would benefit all our users as its something everyone does at some point. Even though, not everyone is as concerned with rendering speed, so even there that needs careful consideration. And then factor in when we have thought on something new ourselves – no-one is requesting it yet because it doesn’t exist anywhere else, and we have to assess how many users will find it invaluable and how often once they get their hands on it.
• How many people are reporting the bug, or requesting the feature? Sometimes there is good information for this, which makes it easier to assess “How many people will it affect”, but even when widely reported/requested, this is still only part of everything we have to account for.

• How many people do we have in the team? While we are always looking for new developers, it is hard to find good developers, which means the team is always smaller than we would like (the day that changes, our ad for C++ Developers will disappear from our Jobs page – but don’t hold your breath!) We also place a high priority on work/life balance, and don’t want to overload our developers and make them miserable, and want to avoid the kind of “crunch” that other software development industries (here’s looking at you, video games!) are known for. All that adds up to this – we only have so many people, with so many hours in the day, and that is often a major deciding factor in just how much we can fit in to any given release.

That’s a long list, and to complicate things, many of these factors are tangled together, which means there is no 100% guaranteed, perfect, way of assessing them and prioritizing between them.

However hard it is to assess and weigh up all those, the driving force behind our decisions is always what will be of the most benefit to the most users.

The Dreaded Unexpected

It’s nice to think with code itself being inherently founded on logic, nothing unexpected will ever come up. This is only true while code is very simple, though.

It’s impossible to cover all the ways that plans can change, so perhaps the best way to describe how plans can change is to give some examples of what that might look like:

Example 1 – We start with a rough outline of features which we think would be most useful and that can be done within the release cycle. Then there is a process of re-evaluation as we go, based on things such as user feedback and what we uncover during development. Sometimes that leads to some changes, in order to deliver the best match of features to user needs at release (rather than how things looked at the time of pre-release planning).

Example 2 – Partway through the development cycle, we learn of some new feature. It turns out that this should be fairly easy to implement, and would be a frequent benefit to many users. This gets added into the development cycle, which may or may not mean other features move back until later.

A good example here is our Rendathon event, where for one week developers from the V-Ray and Corona teams get together to compare code and implementations, and then work together to see how feasible it is and start creating the code to do that. This happened in the Rendathon meeting between Feb 24th to 28th in 2020, where the brainstorming and coding uncovered that it looked possible to:

• Include Phoenix FD foam support in Corona
• Add V-Ray’s improved bloom & glare into Corona
• Add the new secondary cache from V-Ray for improved rendering times and reduced potential issues in animation

Since these had proven viable and had clear frequent benefits for a majority of our users, and because the coding work had already started and test results were being produced after only a week, these were added in to our plans for Corona Renderer 6.

And to show how complex things get and how things are always changing, during development it then turned out that the new secondary cache performed as expected in some cases, but in others it was worse than the UHD Cache – so the feature did make it into the release, but was not made the new default as expected and left as an experimental option if users wanted to try it. Of course, this was also after extended development time to see if we could fix those cases where it didn’t work before Corona 6 came out too.

Example 3 – A user (or maybe more than one user, or maybe ourselves!) discover a serious bug in the previously released version. Resolving this takes a higher priority, and as a result of the time and manpower needed to fix it, we have to move something out of the current development cycle.

In Conclusion

That was a lot of reading – and really, only just scratches the surface of it all. Bug fixing and prioritizing new features is complicated, and there is no perfect answer, or even a perfect process for coming up with an answer. It’s part science, part art, and what’s most important is the spirit in which it is approached – for us, that’s always “what will benefit most of our users most often”.

Which does not mean we always get it right (we don’t, whether that’s in picking features, or estimating how long things take). What we can say is this though – even when we get it wrong, our heart was in the right place!

The article mentions how important user feedback is, so here’s how you can become part of the process! Keep up-to-date with the Changelogs in the daily builds sections of the forum:

Corona for 3ds Max Daily Builds Corona for Cinema 4D Daily Builds

The Changelog posts in those sections detail what is in each daily build, giving you a chance to test new features well before release. Then you can give us your feedback in the discussion/reporting threads there too, where we welcome suggestions for those new features, as well as any reports of problems using them.

Thanks for reading, and we hope you’ve found this an interesting and enlightening look into how we run things during the development of our software and products. The next article will be an update on what is going on with Corona 7.

All the best, The Corona Renderer Team

Useful Links

Want to request a feature? Feature requests – 3ds Max Feature requests – Cinema 4D

Want to tell us about a bug: How to report issues – 3ds Max How to report issues – Cinema 4D