OTOY Forums

Hi all,

This is just to let you know, that you can download a demo version of 2.00 from the OctaneRender downloads sections in case you would like to try it out.

Cheers,
Marcus

EDIT (13/6/2014): I uploaded a new build, that fixes these three problems:

• Switched default render priority from "low" to "high".
• Alembic files larger than 2GB are now loaded correctly on Windows.
• Made the Windows builds run on Windows XP again.

wow, that's great news for those who interested in Octane's new features! =)

not the stable
freezes
the displaysment isn't regulated

I did a quick benchmark from demo scenes. PT kernel:
1.55 - 6.1 Ms/sec
2.0 - 3.4 Ms/sec

Done on single GTX 780.

Why there is almost 50% slowdown?

bbeepp wrote:I did a quick benchmark from demo scenes. PT kernel:
1.55 - 6.1 Ms/sec
2.0 - 3.4 Ms/sec

Done on single GTX 780.

Why there is almost 50% slowdown?

When I run the demo scene on 1 690 GPU, I get these speeds:
1.55: 3.74 Ms/s
2.00: 2.77 Ms/s
That's a slow-down of ~25%. It's not great, but not 45%. I really don't understand how you got to your numbers.

Just to make sure that we are rendering the same thing, that's how the trench looks like, when opened untouched in 1.55:

You may notice that the sun position has changed

To the why: We had to make a lot of changes in the ray-tracing and geometry code, to make displacement, motion blur, hair and rounded edges work. They introduce more complexity and therefor slow-down ray-tracing.

I can't tell you exactly why it's so much slower, because you can't profile CUDA kernels easily, but my running theory is: Since this particular scene mostly tests ray-tracing only (since the textures are trivial), it gets affected more by the slow-down in ray-tracing than scenes with more complex materials. We also had to modify the geometry compilation, so it's possible that we introduced a bug here.

All I can say is that we are currently investigating the performance issues. Unfortunately I can't make any promises that we can solve them very quickly.

Thanks a lot for this demo, I've tried it with an Alembic scene exported from Maya and the displacement mapping and motion blur are fast as hell. Lots of fun so far, it's just crazy to see everything update in realtime!

I did some speed comparisons (on a GTX 780) with a forest scene and a car scene between this demo and the 1.5 demo and this is what I found:

Forest scene:
- 1.5 PT: 8.43 Ms/s
- 2.0 PT: 7.92 Ms/s
--> 6% speed difference

Car scene:
- 1.5 PT: 15.36 Ms/s
- 2.0 PT: 14.59 Ms/s
--> 5% speed difference

Off to more testing...

One more test, this time an architectural exterior scene from Evermotion

GTX 780, PT kernel:

1.5 demo: 12.83 Ms/s
2.0 demo: 12.14 Ms/s

speed difference: ~5%

abstrax wrote:

bbeepp wrote:I did a quick benchmark from demo scenes. PT kernel:
1.55 - 6.1 Ms/sec
2.0 - 3.4 Ms/sec

Done on single GTX 780.

Why there is almost 50% slowdown?

When I run the demo scene on 1 690 GPU, I get these speeds:
1.55: 3.74 Ms/s
2.00: 2.77 Ms/s
That's a slow-down of ~25%. It's not great, but not 45%. I really don't understand how you got to your numbers.
....
To the why: We had to make a lot of changes in the ray-tracing and geometry code, to make displacement, motion blur, hair and rounded edges work. They introduce more complexity and therefor slow-down ray-tracing.

I can't tell you exactly why it's so much slower, because you can't profile CUDA kernels easily, but my running theory is: Since this particular scene mostly tests ray-tracing only (since the textures are trivial), it gets affected more by the slow-down in ray-tracing than scenes with more complex materials. We also had to modify the geometry compilation, so it's possible that we introduced a bug here.

All I can say is that we are currently investigating the performance issues. Unfortunately I can't make any promises that we can solve them very quickly.

Hi, and thanks for explanation. I'll investigate it more closely later. I compared the same scene and I didn't change anything in it. Maybe it's the the demo issue. I haven't upgraded yet to full 2.00 version.

bbeepp wrote:Hi, and thanks for explanation. I'll investigate it more closely later. I compared the same scene and I didn't change anything in it. Maybe it's the the demo issue. I haven't upgraded yet to full 2.00 version.

I think the slow-down you experienced is because of the render priority. See here and here.

Just a heads up: I also updated the demo builds. You can find the changes in the opening post.