OctaneRender™ Standalone 3.00 alpha 3

[grimm]

Unless I'm missing something, loading this MTL file works as expected...

There are no image textures described in this MTL file (via directives map_ka, map_kd, map_ks, map_ns,, map_bump, bump, map_d). The 2 materials are identical and Octane correctly creates a glossy material for them using:

• Kd 0.640000 0.640000 0.640000 -> diffuse RGB texture with value (0.64, 0.64, 0.64).
• Ks 0.500000 0.500000 0.500000 -> specular RGB texture with value (0.5, 0.5, 0.5).

cheers,
Thomas

Thanks for looking at this too Thomas, It looks like a problem on Blender's side then. Both textures should have come in as diffuse with no textures, just color. Could this be an issue with the plugin as the materials were Octane nodes and I was using it?

Jason

Don't understand that last sentence. I think the obj exporting is done by Blender itself and has nothing to do with the plugin.

I looked into it some more and it looks to be a Blender issue, Blender can't effectively convert material (Cycles) nodes to the mtl format. This would affect the plugin too as it also uses the node support system for building Octane materials. I understand the issue better now, about the only way to really get it to work right would be to bake every texture and export it the way mtl can support.

Thinking a bit more about this, it might work well for when you guys get OSL working. Once you finalize your scene, you could bake all the textures down to simple diffuse, spec, normal, etc. Save them and then do a final render which might be faster than having to calculate a complex series of nodes, etc. Would probably really help with animations?

Thanks again Thomas.

Jason

[Seekerfinder]

Wow Notius. Thanks (I think)! You must have Tutor as your "thoroughness"... tutor.

Of all the issues listed it's the following observation that worries me most.

4 - getting 20-40 % slowdown in OR3 compared to OR2.24 on simple demo scene

I have not tested this and I don't know if it's verified. But if true it would be at least the 3rd time that we're losing significant speed (including the fermi-kepler transition) since Octane 1 (we got some speed restored with the PT kernel in 2 which is great). The focus seems to be all on features. Great. We need them. But it's like original focus of what Octane was all about is being lost as a priority. By all accounts GPU programming seems to be real hard and a lot of what's being developed sounds great (looking forward to PS & UE4 integration). But all those 15-25% slowdowns add up. Does feature partity with a CPU renderer like Maxwell eventually lead to speed parity with those renderers as well?

I know there's no simple answer here and I still love Octane. But I'd love to see an Octane (not Otoy) mission statement...

Best,
Seeker

The mission statement is the same is has always been: Our priorities are stability, performance and features. In that order. Please do your own tests first and don't jump on stuff like "Octane is getting 20-40 % slowdown" without testing yourself.

That's not true until proven. As I have written and discussed multiple times already, in simple scenes you have to bump up the parallel sample count and max samples per tile settings. Yes it requires more VRAM, but simple scenes don't require a lot of VRAM themselves so it doesn't matter. Anything non-trivial is most of the times faster than v2 (not always, but that's just the nature of software development). Sometimes even up to 1.5-2x faster. Most of the production scenes that have arrived in support were far from simple and usually improve in render speed compared to v2.

And no, we haven't continuously lost performance. During the v2 cycle we actually gained performance in many scenes due to the introduction of better sampling and the coherent mode/ratio. So please check your facts first, before you make statements like these.

EDIT: And in v2 we added additional options to clamp fireflies (GI clamp) and to soften caustics (caustic blur) which both help you to achieve cleaner renders faster...

Gee relax Marcus,
I did not claim that v3 is 20-40% slower - someone else did. And I said that I did not know if it was verified. So I don't need to check my facts because I did not claim any facts. And there have been times when significant speed losses were experienced because of new features. It would be interesting to see a benchmark graph of the demo scene of Octane 1 on Fermi and Octane 3 on Maxwell.

We use Octane a lot in the office and we have both money and time invested in the product. So we care very much where it is going and when announcements are made at events like GTC or Siggraph and then dropped or not delivered it makes us wonder what the vision is - usually expressed by companies in a mission statement.

Our priorities are stability, performance and features.

Thanks. Those are your priorities - they're great! Not sure it's a mission statement for the product though.

Seeker

[smicha]

In other words: This problem should only occur when face and vertex normals are not aligned, i.e. don't match, which indicates incorrect import settings and shouldn't happen in the first place. You can control the polygon normal import using the winding order option in the mesh node and it should be set in a way that the polygon normals align with the vertex normals.

Marcus,

So helpful! I don't know how but I had the polygon winding order in the obj import settings in the preferences set to counterclockwise instead of clockwise. Thank you so much again.

BTW is the new improved version for faster responsive nodes where there are massive amount of instances to appear in alpha 4 or later?

[Notiusweb]

Postby Seekerfinder » Tue Jan 19, 2016 12:12 pm
It would be interesting to see a benchmark graph of the demo scene of Octane 1 on Fermi and Octane 3 on Maxwell.

Seekerfinder is right. There is only one person who is truly qualified to judge a speed comparison between V2 and V3. And that person's name is Octane Bench.

Lets get the same bench scenes running with the V3 engine...That would be hard data right there...
We could make it like Fast and Furious...If your best V3 rig beats my V2 then you keep my rig

abstrax wrote:
... Sometimes I really wonder what you guys are smoking...

Yeah! that's what I'm talking about!....Only smoking the best baby!.....WOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOO!!!!!!!!!
(some snorting too...)

[BorisGoreta]

I found out that Octane 3 gives bright white hot pixels when having bright reflection spots in the scene, and rays reflecting from some normal materials hit them. Octane 2 didn't have that. I will send the scene soon.

is it possible that GI clamp was clamping this before and now it doesn't ?

I know about the hot pixel removal tool but in this scene with Octane 2 I didn't have to use it at all because there were no hot pixels.

[abstrax]

I found out that Octane 3 gives bright white hot pixels when having bright reflection spots in the scene, and rays reflecting from some normal materials hit them. Octane 2 didn't have that. I will send the scene soon.

previewImage.jpg

is it possible that GI clamp was clamping this before and now it doesn't ?

I know about the hot pixel removal tool but in this scene with Octane 2 I didn't have to use it at all because there were no hot pixels.

Yes, if you could send the scene to us we can have a look and hopefully fix it. Thank you.

[BorisGoreta]

Octane 2:

Octane 3:

In Octane 3 hot pixels are very pronounced. Both stopped at 1000 samples. In Octane 2 hot pixels disappear if I let it cook more but in Octane 3 they are still there.

The scene is included.

[tigher]

Will there be an openCL version for alpha and beta testing for octane v3? I only have an AMD card running right now and I'd like to try using the new alpha builds. If there is a separate alpha 3 build testing openCL integration could someone please let me know. Thanks.

[abstrax]

Octane 2:

The attachment Capture.PNG is no longer available

Octane 3:

The attachment Capture2.PNG is no longer available

In Octane 3 hot pixels are very pronounced. Both stopped at 1000 samples. In Octane 2 hot pixels disappear if I let it cook more but in Octane 3 they are still there.

The scene is included.

I had a look at your scene and they actually render the same in 2.24.2 and 3.00 alpha 2. The issue is that you probably render on many GPUs, I assume 12. In v2, the render results of the various GPUs got blended after tone mapping while in v3 we accumulate samples from the various GPUs in one film buffer and then execute the tone mapping with that one buffer, i.e. blending is done before tone mapping. In most cases there are no big differences, but in some situations there are. Your scene is one of those cases. Those glints in the floor are reflections of the reflection of the sun off the tower. GI clamp doesn't apply here, since it's a reflection of the sun via two mirrors. Due to the bump on the surface this happens fairly rarely, but when that happens its contribution is fairly large.

This is your scene rendered in 2.24.2 on 1 GPU with 2000spp:

and on 4 GPUs with 2000spp:

What happens here is that the 4 results of the 4 GPUs get tone mapped and with that clamped at 1. Then they get averaged. If one of the GPUs has a big contribution for a pixel, tone mapping will clamped it at 1 regardless how large it was. The other GPUs most likely don't have a big contribution at the same pixel and will have the normal floor value. Then they get mixed together and the pixel won't be much brighter than the floor, i.e. <<1.

In version 3 we have only one film buffer and if one GPU throws in a large contributions the average will become quite large, too, and will stay large after tone mapping.

This is your scene rendered with 3.00 alpha 2 on 1 GPU with 2000spp:

and on 4 GPUs with 2000spp:

So what can you do about it? Depends on what you want to do. If you don't want specular reflections on the floor, then make it a diffuse material. If you don't want the bump remove the bump. Or make the glossy material rougher. Also fix the IOR, which is currently 6 and doesn't make any sense. You basically have to fix your scene here.

PS: You might have noticed that I'm talking of alpha 2 all the time, that's because a bug sneaked into alpha 3 which broke the cosine mix material:

It will be fixed with the next release.

[BorisGoreta]

I was testing the scene on 7 GPUs since I wanted to exclude network nodes not knowing what the actual problem was.

Thanks for clarifying this, I understand what is going on now. Why wouldn't we have Reflection clamp as we have GI clamp ? Is that something that would help in such cases or it doesn't make sense at all. ( i.e. it's a stupid idea )

Hot pixels are also visible on metal structure around glass which has to be glossy so I can't fix all the problems by changing materials.

The way it worked in Octane 2 with multiple GPUs was quite convenient in averaging those hot pixels.

Is there an architectural change which doesn't allow tone mapping to happen on each GPU separately any more or could it be possible to have both ?