Hiya,
Octane 3 needs to lend itself a little better to producing naturalistic looking landscapes. To do that, it needs dedicated tools that lend themselves to the task of creating a large and expansive natural landscape. Atmospheric effects are essential to the sense of scale, without it you scene will look like a miniature model placed in some studio instead of a landscape placed on a real planet.
Here area a few considerations I hope the Otoy team will take into account as they build these features
1. Globally applied and fully integrated Haze/ Fog field that thickens near the horizon and also thickens with distance from the camera via Raleigh scattering. Here's what I would like to see.
A. A fully integrated globally applied haze/fog field that does not require an inverted normal facing sphere workaround to function. Outdoor landscapes of any appreciable scale require haze to create the sense of size and distance. The current specular sphere work around doesn't have the proper behavior because it doesnt thicken near the horizon nor does it thicken with distance from the camera. From my own tests the current workaround obscures all items within the volume to the same degree not matter how close or far from the camera they may be. This simply will not be acceptable once Octane 3 ships.
B. We should have a Visibility control to determine the overall thickness of the haze/fog. In real life they use miles, so on a clear day visibility might extend for two or three miles but on a cloudy day it might only extend a half mile or so. The more control we have the better.
C. Because Octane already uses real world scaling, the altitude of the Haze/Fog field also needs to be taken into consideration. We should have a real world height control. And as mentioned, we should be able to manually control the exact manner in which the haze thickens as it descends toward the horizon.
D. Rayleigh Scattering needs to be applied so that we can achieve the natural spectral shifts that tends to occur near the horizon where the air column is thickest. You could look closely at e-ons Ozone software for an example of the type of haze/fog scattering standards professional users will demand. IT might even be wise to include parameters such as humidity and pollution to tweak the accuracy of the haze behavior.
2. All of the examples of volumes we've seen so far in the previews have been constructed from a single closed model, like a cube or sphere or teapot. But what I don't see is any example of volumetrics used in a landscape scenario. Here are some things to consider.
A. Individual clouds are nice for explosions and the like, but they are not ideal for full landscapes. For full cumulus cloud type scenes Octane 3 needs a Slab Primitive. The Slab is a unique primitive that understands that it is generating a procedural that extends over a very large area instead of being built around a single center point the way a single cloud would be. The user should be able to place the slab at say 35,000 feet, and know that they don't needs to create three hundred separate clouds to fill in the sly, they can use a single slab and this slab will generate clouds over the entire area of the sky.
B. And that brings us to things like Godrays. Once Octane 3 has an integrated Haze/fog field and true cumulus cloud slabs, Godrays will likely be an automatic result without any additional hacking from the user, which would be really really awesome. I assume there would be a "fake shadows" option so that one could avoid the Godrays if they didn't want them by turning fake shadows off or on.
If visual examples are necessry, please let me know.
Thanks Otoy team and great work on everything so far!!!
So to conclude....dont half bake these new features. If you're going to introduce volumetric rendering, make sure the tools re robust enough to be practical and useful for large scale environments. Let us use Octane for our next Avatar style scene, which will not happen if the atmosphere is not modeled with large landscapes in mind
Octane 3 Global Atmospheric Haze/Fog Model
Forum rules
Please add your OS and Hardware Configuration in your signature, it makes it easier for us to help you analyze problems. Example: Win 7 64 | Geforce GTX680 | i7 3770 | 16GB
Please add your OS and Hardware Configuration in your signature, it makes it easier for us to help you analyze problems. Example: Win 7 64 | Geforce GTX680 | i7 3770 | 16GB
We want Octane 3.x to support robust atmospheric rendering. We will be looking into the best approach to handle this during the 3.x release cycle, probably after 3.0 is out of alpha/beta.
There are going to be new avenues in Octane 3 that might make it possible for multiple 3rd parties, beyond just OTOY, to implement these features iteratively on top of the core rendering engine:
1) OSL shaders that support complex volumetric atmospheric scattering, each with different tradeoffs for render time vs. accuracy. These may already exist out in the wild. Our goal in making Octane 3 OSL based, is that we are no longer the gating factor in supporting new shaders and procedurals, especially given the amount of development that has been done in OSL. We imagine liveDB becoming even more powerful once OSL is supported, exposing more than just textures/materials, but new shading and BRDF resources as well.
2) To complement OSL shaders, we are also working on a new C plug-in API in 3.x (similar to Lua nodes/scripts in 2.x) that would connect to the render graph directly, and could be used either by us or 3rd parties to build powerful new features and extensions to the core engine. This might allow automated atmospheric rendering tools (beyond the shading support in OSL) like what you described, to be built on top of the core renderer, and work across SE, cloud and DCC plug-ins as robustly as first party code would.
We are still early in the process of vetting these features, so things may change, and we may have to rethink this approach. But, If all goes as planned, we hope the path 3.x is taking will provide a basis for very rapid iteration of features and tools both from us and the OR community.
There are going to be new avenues in Octane 3 that might make it possible for multiple 3rd parties, beyond just OTOY, to implement these features iteratively on top of the core rendering engine:
1) OSL shaders that support complex volumetric atmospheric scattering, each with different tradeoffs for render time vs. accuracy. These may already exist out in the wild. Our goal in making Octane 3 OSL based, is that we are no longer the gating factor in supporting new shaders and procedurals, especially given the amount of development that has been done in OSL. We imagine liveDB becoming even more powerful once OSL is supported, exposing more than just textures/materials, but new shading and BRDF resources as well.
2) To complement OSL shaders, we are also working on a new C plug-in API in 3.x (similar to Lua nodes/scripts in 2.x) that would connect to the render graph directly, and could be used either by us or 3rd parties to build powerful new features and extensions to the core engine. This might allow automated atmospheric rendering tools (beyond the shading support in OSL) like what you described, to be built on top of the core renderer, and work across SE, cloud and DCC plug-ins as robustly as first party code would.
We are still early in the process of vetting these features, so things may change, and we may have to rethink this approach. But, If all goes as planned, we hope the path 3.x is taking will provide a basis for very rapid iteration of features and tools both from us and the OR community.