Displacement mapping – Used to give objects depth and detail, displacement mapping allows the height of points on a surface to be adjusted based on an image value.
Object motion blur – The blurring effect that simulates motion of inanimate objects in a rendered scene is supported and can be applied independently of camera movement.
Vertex motion blur – The blurring effect associated with geometry deformations, such as movement of a character’s arms or legs.
Hair and fur – An optimized hair render primitive is now available to allow rendering of hair or fur while reducing memory usage by 20 times compared to previous processes. OctaneRender™ 2 also simulates the distribution and fluidity of movement of those primitives.
OpenSubDiv surfaces – Pixar’s powerful library for fast refinement of subdivision surfaces is integrated in OctaneRender™, a feature that’s most useful for animation of objects.
Rounded edges – Artists have the ability to easily and efficiently round the sharp edges of geometric objects without modifying and reloading the geometry. The process is done during rendering by special shader algorithms that recalculate normals near the sharp edges and corners to make them appear smooth allowing for the tuning of edge sharpness in real-time throughout rendering.
Random color texture for instances – Useful for easily modifying the colors of instances which otherwise have the same material.
Improved sky rendering – Using HDRI + Sun, OctaneRender™ 2 enables the use of textures as sky backgrounds and ensures that objects in the scene accurately reflect the loaded sky texture.
Local DB – OctaneRender™ 2 sports a cleaner, more organized workspace with a new folder structure that allows users to create packages of nodes, node graphs, and node trees, and organize them in folders along with thumbnails for easy identification.
Region rendering – To save time on test renders, this feature allows users to specify a region in the scene and partially preview rendered results in real-time.
Network rendering – The rendering process can be made faster than ever by leveraging remote GPUs on render slaves connected via the network.
New stereo rendering modes – Rendering modes such as off-axis and parallel camera placement in combination with left/right/split screen/anaglyphic output options to allow improved stereo rendering.
Compatibility with Brigade – OctaneRender™ 2 features expanded integration with Brigade, OTOY’s cloud rendering technology for photorealistic next-generation games. Within Brigade, users can now open scenes created in OctaneRender™ and walk through those scenes in real-time over the cloud.
Upgrade cost is 99 € for the standalone and 39 € for the plugins. But if you upgrade the standalone, you can choose one plugin and get the upgrade for that for free. Mind you, though, that until now only the plugins for 3ds Max and MODO are available in 2.0 compatible versions.
New standalone price is 299€ (100€ more than before), and 99€ is the price for an upgrade from a 1.x license.
Also I find it funny that a handful of people (~5 at the time of writing), complain about severe performance drops (up to 50%). Looks like Octane also fights with a bigger GPU kernel.
(Reference: http://render.otoy.com/forum/viewtopic.php?p=188592#p188592)
Adding all this stuff has also its drawbacks, i always found a bit ironic that feature incomplete engines claim to be “the fastest”, indeed now there is a 25 to 50% slowdown.
This is the price of all new feature. Unfortunately every new feature slows down gpu code even if it is not used. Not sure we can improve the speed anytime soon.’
‘We have seen a slow down in the range 10-20% compared to 1.5, maybe 25%,…’
'On a simple interior scene, 8000 Maxsamples PathTracing
1.5 : 7.5 MSamples/s almost 17 min
2.0 : 4.35 MSamples/s almost 31 min’
Are AOVs been added btw? Can’t find.
EDIT: DingTo faster than me by 25% he posted without motion blur enabled
I guess it’s a good thing that Cycles can also use CPU-specific code for sophisticated optimization techniques (like that one for faces using transparent textures), because you eventually might see a number of situations where the CPU ends up coming on top (have fun with your power-hungry space heaters if this becomes the norm)
Though it does look to me like Otoy’s struggles highlights a serious weakness in the use of GPU’s as a rendering device, which unfortunately may have to be something that needs to be fixed through more sophisticated compute units and architectures on the hardware itself (the ball being now in Nvidia’s court).
I think that the slowdown is highly scene dependant, at least, that is what I’m seeing in my tests. In fact one of my scenes, that uses displacement, got a little bit faster (0.85 Ms/sec to 1.03 Ms/sec). I’m also wondering if it’s a problem with Kepler again as my Fermi cards don’t appear to have slowed down that much. Unless you really crank the displacement high, then it starts to slow down. But that is to be expected because it adds a ton of new geometry. Now I’m just waiting for the 2.0 version of the Blender plugin to come out.
The slow downs are something they will be fixing as time goes by. It’s not like they’re just going to let the engine keep slowing down. That would lose it’s selling point. Needless to say, I already upgraded to the 2.0 engine and I’m waiting for the blender plugin to do so also. In another year we shall see where the engine goes and if it doesn’t improve it’s speed and add some extra features before 3.0 than you know they’re struggling.
Something tells me they will get passed this though and there will be big improvements in the next couple of months in terms of speeds and possibly some new features.
There seems to be evidence coming up that points to the possibility of GPU coding limitations getting in the way of future optimizations for sampling and speed.
Remember that big speedup Brecht committed that involves tracing a ray through transparent surfaces and then shading the points all at once (ie, doing the shading after the ray is terminated)? That’s something that, to my knowledge, you can’t really do with today’s GPU’s. Overall, the optimization possibilities remain far higher when writing code for the CPU (GPU-based rendering mostly having to rely on Moore’s law meaning you need to get successive generations of cards for your speedups).
I for one am very happy that Brecht and co. chose not to delay the introduction of features because of these facts, it seems like Cycles is now doing the same thing as happening with Indigo, Thea, and Vray, that is slowly expanding the GPU-compatible feature set as the technology permits.
Hi, 2.0 is about 10-15 % slower compare to 1.55, there is now only one file send to the devs with 50% slowdown.
The Octane team call it a bug and investigate it.
Keep in mind that change Cycles to Cuda toolkit 6.0 from 5 slows Cycles down about 10-15% in 2.71.
We have a slowdown of 20-30% compare to 2.69.
New features, bigger kernel slows down rendering performance in Octane and Cycles too.
This is the GPU render business.
Improvements are always possible but to promise something to your customer is always a dangerous thing.
Well that doesn’t mean there can’t be at all. I’m hoping that there won’t be a lot more speed drops in the future - Doesn’t seem like I will be bothering to update past 2.0 unless they put a lot of stuff into 3. Besides, I read on the forum they are working on speeding it up, so you never know what may happen in a year or 2.
- Doesn’t seem like I will be bothering to update past 2.0 unless they put a lot of stuff into 3. Besides, I read on the forum they are working on speeding it up, so you never know what may happen in a year or 2.