OTOY Forums

Hi Jim,
Here is a bug question for you.

I've attached a sample scene, where there is a point cached simple object with motion blur.
The problem is all motion blur settings are not updated instantly on the live view.
To update the new setting you have to move the timeline. Wonder why that is the case.

Motion blur duration, motion blur steps (in obj.prop. menu) all do not take effect instantly while the octane render viewport is on...

In addition to that.
I wrote a shortcut script for max earlier and shared on the forum. Where you can change few octane setting with a single click on the fly.
I also managed to add Motion Blur steps settings to the script. But this also doesnt let the scene update on the fly. But it does change the object property on the fly. The problem is coming from the octane plugin it self.

On the other hand Octane obj. properties menu isnt working on the fly. It's locked window. you have to close it in order to see that effect. And if you changed the motion blur steps there. it still doent update instantly, you have to advance the timeline to see the effect.

Lastly, I don't know how many times I asked for this. And there were no replies to this matter.
But maxscript compatibility doesn't work at it's best.
For starters there is no maxscript connectivity with octane render settings.
This has to be solved at some point. I simply cannot tell the benefits of maxscript conenctivity
Now the Octane v3 is on the way I or others like me do not know if it's on the pipeline.

oguzbir wrote:Lastly, I don't know how many times I asked for this. And there were no replies to this matter.
But maxscript compatibility doesn't work at it's best.
For starters there is no maxscript connectivity with octane render settings.
This has to be solved at some point. I simply cannot tell the benefits of maxscript conenctivity

I've seen this in code.
And this is the real problem: this plugin from the beginning was designed this way, not using the standard Max properties for Octane render settings and instead reading/writing their values directly to/from scene file. I can fix this, but this will totally break the scene-files compatibility with previous plugin versions. That means - all properties will become default values for all the Octane objects if some old scene will be opened in any version of plugin older than the version where it was fixed... "On the fly" conversion will be impossible to implement, as the way how the information is stored inside the scene will be changed dramatically in this case.
Moreover, there are a lot of other things which need to be improved/fixed that require the compatibility breakage. So, if the Octane render settings MaxScript compatibility will be fixed, it must be done together with a lot of these other fixes that break the compatibility too... I even see these other things more important...

But, at least so far - I'm still thinking if this should be changed at all... As I just can imagine what for amount of crying from a lot of artists will be heard after that... Or should we do this the "Apple way"?..

Hi Jim,
The things you've just said had been has been demanded for years mate. You might not have noticed but the max people did threw in the towel after many many evasive answers like " we're now on the 1.2 release these demands maybe dealt with the next release" or " we're working full time to manage finalize stable version of the core". I kid you not, this has been over and over years literally. I do not know how many users will arouse their feelings about it.
The thing about breaking the older scene compatibility is a major haul. People might be against it if they just hear about that.
But the benefits must be put on the table as well.

I'm not comfortable putting this all on you. Since you've been here not for long. And like you've said they were designed this way from the begining.
But it would be wonderful if you can solve all this

But what you're saying is big I know that.
Users like me demanding for more compatibility from the very beginning, knew that we would face these issues any time in the near future.
That's simply why now it's hard to implement new features in max. Other than that no new max plugin's are easily be used with octane or cannot be debugged or implemented.
Cause there is no connection to it.

A simplest example would be a simple multi texture plugin where you can assign a folder of textures to many objects randomly. (say, floorboards)
In max native environment, it's not necessary for the renderer plugin to support all things. If you're native the purchased plugins or written scripts can do those and add more to the system. Octane would then would be more used. We all know current state is problematic.

I do not know if you have discussed this with other devs.
If you're up for it. Then there are things to sort out beforehand. This is major thing. There has to be a rock solid roadmap that would point all the issues to be solved with that.
I know there are very good people on the forum they might help you with this. Even though these can be discussed through other channels like PM or mails via beta testing.

I do like the way you approach and handle the issues so far. Thank you for all that again.
I'm not sure but there could be a voting system for this. But all the pros and cons must have been told in detail to the users.

As for the crying from a lot of artist.
Many has cried very much to this day about these problems and many with no solutions or even no responses at all.
In my defense about the Apple way ... yeah sure but it might be more meaningful if otoy can also admit it's wrongdoing about implementing max plugin on its own way without interactivity with max's core. That is a way to go surely. But not a great decision after all.
I know it's apples and oranges but people in vray community are enjoying the quick responses from the devs.
Honestly we're starting to see that with you now. That is why I stopped working and writing to you.

I really would love to talk this through and I know max users will benefit from this so will Otoy.
It would be wonderful if we all could have a major topic about this, controlled by you maybe. Without all the +1 + 10000's.

Best,

Interesting revelations, I had suspected as much. Perhaps the most logical time to break backwards compatibility should be at version 3.0, after input/debate from the max community. Cant please everyone all the time.

If it is important enough, (which some of the fixes required are), a step sideways is needed to go forwards. We all need to consider the benefits and the longer term development ability and potential for the plugin.

Creating a list of bugs and issues that are difficult to resolve or fix either because they can't or are hacked workarounds might allow a more enlightened view of breaking backwards compatibility.