OctaneRender™ 2020.1.2 [superseded by 2020.1.3]

[divasoft]

This build slave node can't define videocards. 2020.1 rc4 worsk well. Please fix it, i can't work.

Have you tried using 2020.1? There's an issue other users reported which we are already looking into that could be causing this problem. Please never use non production builds for production work as they all expire after a period of time.

Yes, I tried with the current "production builds" version. Why did you disable all previous versions if there is a problem in your "production builds" version?

[funk]

I'm not sure what you mean by disabled? You can still use previous builds. Here is the original 2020.1:
viewtopic.php?f=24&t=74586

[divasoft]

I'm not sure what you mean by disabled? You can still use previous builds. Here is the original 2020.1:
viewtopic.php?f=24&t=74586

Yes, but how should I have guessed and figured out this heap of versions (RC4, RC5, R7)?
This build is not even in the official downloads section.
In addition to the fact that 2020.1 works 2 times slower than 2020.1 RC4
How could it be possible to block old versions if the final production had such a big problem with video cards?

[mojave]

I'm not sure what you mean by disabled? You can still use previous builds. Here is the original 2020.1:
viewtopic.php?f=24&t=74586

Yes, but how should I have guessed and figured out this heap of versions (RC4, RC5, R7)?
This build is not even in the official downloads section.
In addition to the fact that 2020.1 works 2 times slower than 2020.1 RC4
How could it be possible to block old versions if the final production had such a big problem with video cards?

All experimental and release candidate versions are published in the development builds section on the forum with their respective changelists and references to previous builds and those that superseded them. You can't find those versions in the downloads sections because just production builds can be found there.

If there are any performance regressions between 2020.1 RC4 and 2020.1 it would be useful if you could share a repo scene we can use to reproduce the issue, as we have not received any reports yet in that respect.

[funk]

In addition to the fact that 2020.1 works 2 times slower than 2020.1 RC4

I havent noticed a 2x slow down. You should report it and get a scene to OTOY

[divasoft]

In addition to the fact that 2020.1 works 2 times slower than 2020.1 RC4

I havent noticed a 2x slow down. You should report it and get a scene to OTOY

expired build (RC4) render 1 frame for ~2:30, 2020.1 render time ~3:40.
I honestly don’t see the point of sending something to the otoy developers, without sarcasm. The previous time I wanted to create a project in the octane, I started getting random crashes in the final render every 3-5-10 frames. I turned to Ahmet and he said that to simulate particles (x-particles) to check my bug report is too long and there are more important things to do. as a result, a month passed and of course Ahmet did not check anything. Thus, it was not possible to make the final render of the project and I had to completely recreate the project with redshift. And about the same thing happened with my other reports over the course of all 10 years. In more or less degree. Dozens of my colleagues in the industry are experiencing the same problems, and gradually switch to other renders, disappointed in the octane, although they love it. I apologize for my sharp emotional reaction in my posts, but when everything stops working for you, and the project needs to be handed over and there is no time to check dozens of combinations of integration and slave nodes to find a working one, you will be in a panic as me.
In turn, the guys from the redshift were as attentive as possible to my bugreports and did a particle simulation if the test required it.

[mojave]

We continually improve the software and do look into all reports we get.

We are sorry to hear you had that experience with this specific plugin but it would still be worth if you could share your scene so we can confirm the issue and look into it as speed regressions are usually an Octane core issue. As an Octane subscriber support is something you are entitled with so please help us do our best.

[Notiusweb]

In addition to the fact that 2020.1 works 2 times slower than 2020.1 RC4

I havent noticed a 2x slow down. You should report it and get a scene to OTOY

expired build (RC4) render 1 frame for ~2:30, 2020.1 render time ~3:40.
I honestly don’t see the point of sending something to the otoy developers, without sarcasm. The previous time I wanted to create a project in the octane, I started getting random crashes in the final render every 3-5-10 frames. I turned to Ahmet and he said that to simulate particles (x-particles) to check my bug report is too long and there are more important things to do. as a result, a month passed and of course Ahmet did not check anything. Thus, it was not possible to make the final render of the project and I had to completely recreate the project with redshift. And about the same thing happened with my other reports over the course of all 10 years. In more or less degree. Dozens of my colleagues in the industry are experiencing the same problems, and gradually switch to other renders, disappointed in the octane, although they love it. I apologize for my sharp emotional reaction in my posts, but when everything stops working for you, and the project needs to be handed over and there is no time to check dozens of combinations of integration and slave nodes to find a working one, you will be in a panic as me.
In turn, the guys from the redshift were as attentive as possible to my bugreports and did a particle simulation if the test required it.

Diva - I feel you on this. What I would recommend is making a very simple scene that gives you the issues, and allow them to troubleshoot it with you where an issue lies. Use a very minimal scene to showcase your issue, as opposed to a full fledged scene you put work into, that way the problem is able to be isolated faster without other variables compounding anything. I have also found, using this technique, that I often stumble upon workarounds too, so it can be a double-good approach. Other than that, I always enjoy and learn from your posts, so thanks for pushing these things forward.

Oh yeah - also shout-out to Funk. He obliterates new bugs.

[funk]

I apologize for my sharp emotional reaction in my posts, but when everything stops working for you, and the project needs to be handed over and there is no time to check dozens of combinations of integration and slave nodes to find a working one, you will be in a panic as me.

Hey Divasoft, I'm sorry you had a bad experience and genuinely hope your problem is sorted out.

I've had a pretty good experience reporting bugs to OTOY. Many of my reports are fixed within the next few builds.

As Notiusweb mentioned, its best to give them a minimal scene that reproduces the issue.

[mojave]

Version 2020.1.2: Now working correctly with EXR DWAA & DWAB lossy compression and Cryptomatte passes. Those passes are now lossless ZIP compressed inside the same EXR file.

<- Can we add this to the list of bugfixes please mojave?

The following info passes still are still breaking. They also need to be stored as lossless ZIP as well:

- Position
- UV coordinates
- Z-depth

Hi Padi,

Sorry for the delay answering your request, are you referring to the render passes export dialog not saving those passes using ZIP compression even though the ZIP format is selected?

I could not reproduce it that way, would you be able to share some more instructions of what you are doing and what you expect vs what you get?

Thank you.