Trying to use the option for multiple uvsets, but cant get it to read anything else than uvset 1. The exported alembic file works in max and maya, but not in octane. Anybody that has gotten this to work? I used "crate" for the alembic export.
(using 2.21.1 on linux, will try in 2.22.2 on win when i get home)
Included is a ball with 2 uvSets
OctaneRender™ Standalone 2.22.2
Forum rules
NOTE: The software in this forum is not %100 reliable, they are development builds and are meant for testing by experienced octane users. If you are a new octane user, we recommend to use the current stable release from the 'Commercial Product News & Releases' forum.
NOTE: The software in this forum is not %100 reliable, they are development builds and are meant for testing by experienced octane users. If you are a new octane user, we recommend to use the current stable release from the 'Commercial Product News & Releases' forum.
Thanks smicha, that's very kind. The next time I run into very long render times I'll drop you a PMsmicha wrote:In PT with proper settings you can get very good image for animation within minutes. If you don't mind sending orbx scene I can check how fast it is being rendered.darkline wrote:Abstrax, if you read the whole thread the point was clear. I was countering other posters claims who said only 100% accurate was good enough, and octane should not be trying to fake things to speed up. My point was that even top notch movies fudge effects and there was nothing shameful about it, as long as it looks good.
My guess is some of these people are producing stills and not minutes worth of animations.
My second point was that if materials had a fake blurry reflection option then people would see enormous speed increases in renderings.
You say you can't do any more faking blurry reflections than you already have done, I guess the way it works you cant simple replace a reflection property with a map. So it's pretty much a mute discussion anyway if that's the case.

I normally raise caustic blur and even drop the bounces to around 4 if there's no refraction in the scene. I even do very low sample renders and use neatvideo if time is short.
Windows 7 64bit/ Intel 3930K/ ASUS Rampage IV/ GTX980ti x 2/ 64GB system RAM
Hmm, don't take this the wrong way, but no, it doesn't make sense. What makes Octane unique is that it's an unbiased renderer and fast, probably the fastest out there right now. If you really want fast biased rendering you should take a look at Vray or Redshift. If you take Octane's unbiasedness away from it, you might as well just give up and start using those other renderers.darkline wrote:I get the need to keep it accurate, really do, but people have been creating photoreal renders for years without unbias rendering available, using all sorts of tricks to fake things and speed renders up.
This argument of octane keeping it all accurate doesn't stack up when it already has AO mode, diffuse and fake shadow materials. I actually think the reverse is true, what's the point of having AO and diffuse modes if they are still full of noise after an hour rendering? There should be other cheats to complement these kernels and get noise free renderings quickly. Otherwise we may all just have one path tracing button. Make sense?
This reminds me of the arguments made at the end of the 90's between people supporting scanline renderers and people supporting ray tracing renderers. At that time ray tracing was slow (I'm looking at you Bryce), and scanline renderers were fast. But in time ray tracing got much faster and, because it was a better algorithm, it became the new standard. Now again we have a better algorithm than ray tracing with monte carlo path tracing. It's more complete than ray tracing and because of that it's slow, but Octane makes it nice to use, even for animation.
I don't have any numbers, but I suspect that if you were to take a typical photograph and measure the amount of direct light and indirect light that hits the film. You would find that the indirect contribution will be greater in general. Ray tracers are very good at direct light, they are not so good with indirect light. Path tracers are good for both, so much so it makes GI stupid easy and almost free with the algorithm. In time unbiased renderers will just get faster and faster, until like ray tracing, it will become the new standard.
Unbiased renderers, pick any one, just have much better quality than biased renderers. <- this is my (un)biased opinion.

Jason
Linux Mint 21.3 x64 | Nvidia GTX 980 4GB (displays) RTX 2070 8GB| Intel I7 5820K 3.8 Ghz | 32Gb Memory | Nvidia Driver 535.171
gardeler, you have only one uv channel on sphere, in your example. during the export process, the second channel is lost. check it out in Map Channel Info.
r9 3900x/64Gb/2070s/2070/win10x64/3dsmax2021
A 2nd UV set is not a standard Alembic feature, some applications export those in different formats. We can add extra code to support a few common exporters, but due to these differences it's not possible to implement this reliably for files created by any exporter.gardeler wrote:Trying to use the option for multiple uvsets, but cant get it to read anything else than uvset 1. The exported alembic file works in max and maya, but not in octane. Anybody that has gotten this to work? I used "crate" for the alembic export.
(using 2.21.1 on linux, will try in 2.22.2 on win when i get home)
Included is a ball with 2 uvSets
--
Roeland
You make very good points Grimm, and of course Eventually gpus will be fast enough to path trace any scene in a fraction of a second. We're just not there yet. brigade was originally targeted as a realtime gpu renderer but now ported to a cloud only service because they can't clear up the noise with current gpu speeds. So faking has a place, and a use.
But once again I'm not asking for octane to turn into element 3d and have no options for hardcore realism, it just frustrates me to see environmental fog, shafts of light, blurry reflections take as long as they do. All these thing can be faked to look 90% as good as the real thing but take seconds instead of 20 mins per frame. Most renderers seem to get faster with each release but recently octane has been slowing down.
Corona for 3dsmax is running my old 4 year cpu and gets faster with each release.
But I'll leave it there, octane is great in many ways, and I wanted to chime in to say how I thought something could be faked with little impact on image quality. But it's been discussed to death so I'll leave it there. Hopefully octane 3 won't take another render speed hit.
But once again I'm not asking for octane to turn into element 3d and have no options for hardcore realism, it just frustrates me to see environmental fog, shafts of light, blurry reflections take as long as they do. All these thing can be faked to look 90% as good as the real thing but take seconds instead of 20 mins per frame. Most renderers seem to get faster with each release but recently octane has been slowing down.
Corona for 3dsmax is running my old 4 year cpu and gets faster with each release.
But I'll leave it there, octane is great in many ways, and I wanted to chime in to say how I thought something could be faked with little impact on image quality. But it's been discussed to death so I'll leave it there. Hopefully octane 3 won't take another render speed hit.
Windows 7 64bit/ Intel 3930K/ ASUS Rampage IV/ GTX980ti x 2/ 64GB system RAM
This question about blurry reflections is an interesting one. It's a paradox often encountered when rendering, and not unique to reflections. You see the same issue when rendering motion blur and depth-of-field. Although we are blurring our image in some way, and thus reducing detail, the result is that you need to render much longer to get an image with low noise.
The underlying issue is that it's difficult to calculate the correct blurred value with ray tracing. In the reflection case, when there is a perfect specular reflection, the ray tracer only needs to calculate light coming from one direction. If you introduce blur however, now we need a bunch of rays covering the area where most of the reflection comes from, which will take more time. Usually in case of these reflections the noise will clear up relatively quickly, compared to other noise in eg. indirect light.
There are exceptions though: one is where you have a shallow depth of field and a highly specular material which is out of focus. Another one is if you see an object with a low roughness in a reflection of another object with low roughness. There is currently no workaround in Octane for those cases other than to avoid them.
--
Roeland
The underlying issue is that it's difficult to calculate the correct blurred value with ray tracing. In the reflection case, when there is a perfect specular reflection, the ray tracer only needs to calculate light coming from one direction. If you introduce blur however, now we need a bunch of rays covering the area where most of the reflection comes from, which will take more time. Usually in case of these reflections the noise will clear up relatively quickly, compared to other noise in eg. indirect light.
There are exceptions though: one is where you have a shallow depth of field and a highly specular material which is out of focus. Another one is if you see an object with a low roughness in a reflection of another object with low roughness. There is currently no workaround in Octane for those cases other than to avoid them.
We hope so too, and this is a reason to be conservative about adding new features. It's often difficult to add new features without compromising speed.Hopefully octane 3 won't take another render speed hit.
--
Roeland
What happened to compile features/kernel at render time based only on the features used? This should speed things up if people don’t use SSS, Volumetrics, Specular, Hair, opensubdiv and other stuff.
We can't compile the kernels at runtime. That's not practical. The plan was originally to compile a whole set of different combinations, but we are currently developing a different approach which will allow us to have minimized kernels in a different way.00Ghz wrote:What happened to compile features/kernel at render time based only on the features used? This should speed things up if people don’t use SSS, Volumetrics, Specular, Hair, opensubdiv and other stuff.
In theory there is no difference between theory and practice. In practice there is. - Yogi Berra
Awesome! There are a lot of product/engi`s that seriously just need speed and realism. Hair, fur and even renderpasses, all the more complex features are being used 0% of their time.
Would love to see something like an Octane lite edition that renders even faster but has 50% of the features, even at the same price that would be logical.
Would love to see something like an Octane lite edition that renders even faster but has 50% of the features, even at the same price that would be logical.
Octane 2022.1.1 nv535.98
x201t - gtx580 - egpu ec
Dell G5 - 16GB - dgpu GTX1060 - TB3 egpu @ 1060 / RTX 4090
Octane Render experiments - ♩ ♪ ♫ ♬
x201t - gtx580 - egpu ec
Dell G5 - 16GB - dgpu GTX1060 - TB3 egpu @ 1060 / RTX 4090
Octane Render experiments - ♩ ♪ ♫ ♬