OctaneRender® for 3ds max® v2.23.2 - 2.0 [OBSOLETE]

[Goldisart]

JimStar renew at least the camera clipping me on Monday the draft to pass, and I can't control the camera setting the clipping would have to lower the project to version 1.9

[guillerodriguezv]

Hi JimStar,

Please check the LiveDB panel, in some materials it does not import to the 3dsmax material windows slots... for example Fence netting material.

Thanks

Guillermo

[Jorgensen]

"......we are still deciding if we need to continue this branch at all. As the more users will be bitching about compatibility...."

i guess that we are a lot of users that don't complain / bitch, and who find it a joy to use octane render for 3ds max every day. so please - do not stop development. your effort is appreciated.

[JimStar]

i guess that we are a lot of users that don't complain / bitch, and who find it a joy to use octane render for 3ds max every day. so please - do not stop development. your effort is appreciated.

Just to be precise: there is no question about "stopping the development" - the development of 3ds Max plugin will go on in any case as any other plugin (it even has a little more priority due to bigger user-base). The speech was only about choosing between branches of 3ds Max plugin - if the proportion of complaining users is big enough, then there is no way to continue this testing branch as the main line of plugin development.

I don't like to drop it myself - as despite the fact the changes in this branch are painful for some artists, there is a big move forward in regard of future stability, future development efficiency, and ease of adding of new features (I even not talk about full MaxScript support in it). E.g. this really easy "Camera mapping" feature (which I quickly added to Maya plugin, and will easily add to Blender later) is really pain in the ass to add in 1.9 - as the plugin structure was thought out the way when Octane nodes were reflected automatically into Max properties ID address space (which is capable to hold only 8192 Octane IDs in worst case scenario), occupying if fully by random generation algorithm and not leaving the robust way to add the additional plugin-specific parameter between automatic parameters without the risk of collision at any time. So, any new feature requiring the plugin-specific parameters in Octane nodes - is the pain in the ass and almost impossible to implement efficiently and robust way in previous branch.
But exactly this refactoring together with refactoring added the MaxScript support - broke the compatibility significantly. This breakage happens on the level much lower than Octane plugin works on inside Max, so any old data is inaccessible to the plugin during old scene loading. This is the reason why only external "two stage" convertor working with two different scenes with different Octane plugin versions loaded is possible. This is too much of work that will stop other more important development of this and other plugins...
So, the only way here - either this brach will be accepted by the artists (as the "transfer-point" to new scene format and new features), or most of you will be conservative enough to return to the previous branch having no problems with compatibility but having no MaxScript support and no way to implement something like described above.
In addition - there is one more problem in the previous branch. This will unlikely happen, but it is still not impossible: if the Max SDK will change its random generator algorithm at some point in future - this will suddenly ruin the plugin, it will get the same state as the 2.0 in comparison to 1.9, all Octane nodes data will be lost and set to defaults. This is due to the fact the Max SDK random generator is used to reflect the Octane pins to Max parameters IDs address space. So: slightly changed random generator algorithm in next Max SDK - the totally different parameter IDs of all Octane parameters - old scenes become the same incompatible suddenly loosing all its parameters with data. So, it is one more reason to better change it right now, than waiting for disaster...

[mark0spasic]

JimStar thumb up go with this new version.

[Phil_RA]

To me, that's life. Programs evolve, and if you used an older version to start projects (some being commercial ones), there's no reason why you would have started those projects on the assumption that X features would be added later. So logically, any scene made in 1.9 can keep being made in 1.9, you don't need to upgrade. Eventually, if you feel that the need for the new features outweighs the fact that your old data won't be compatible anymore, you'll upgrade. It's not like your older version will stop working, so you have all the time in the world to decide when you will upgrade.

I would much prefer to see features that used to work continue to work from one version to another, than being backward compatible with old data, otherwise Octane won't get better over time, it will just change number.

Thanks for the hard work Jim

[oguzbir]

Well said both Jimstar and Phil_RA

I hate to continue the talk instead of bug reporting that because I have a huge time demanding job at hand and couldnt lay my hands on the new update as much. Once I'm done with the job I'll jump in work with the 2.0. Then I'll be able to report. I'm writing these words while waiting for the renders finish with 1.9 )

As far as I can see the main problem with people hesitating about the refactoring is,
People think Why on earth this, all of a sudden compatibility drop arises. Why do we have to loose our previous assets.
We were fine with 1.9 says the conservatives and the liberals tend to keep open minded to the future updates.

Jim explained more detailed in his last post. But I see the problem as a bit lack of PR here.
I have no intention to put Devs under any pressure. It is not their job to persuade people how the plugin should evolve.

The ongoing plugin had its 3ds max nativity problems from the start. Few of us mentioned this for literally years.
Now it's about come to a point where less features to be implemented. With v3 in the horizon, I say It is the perfect time to refactor it.

Yes, it's sad to loose backwards scene support. But we should get over with it and move on. You hold on to the 1.9 when you need it.

For me the one and only problem is that, there is no carrot here to sell and that would help some users to believe and understand that this move is the right way to go.
I believe there is a lot to be done in terms of plugin features apart from the standalone's plugin version adaptations.
A roadmap and a possible features list would be just awesome to see. The potential of this new refactoring might then sound clear to those who are understandably against at the first encounter.

And I quote

Thanks for the hard work Jim

But mind you Jim. Once you get the new code stable enough, we'll demand more and more.
Cheers,

[RobSteady]

Bug?
When clicking on the little arrow buttons in the render setup dialog (exposure, highlight compression, active layer ID...) the render viewport is affected but the numbers stay as they are and glitch out until you re-open the render setup dialog. Also, when typing in numbers nothing happens.

[RobSteady]

Render Layer Mask
Is it possible to render this at the same time and get render element outputs?

1. Beauty
2. Layer Mask 1
3. Layer Mask 2
4. Layer Mask 3

Also, it would be great if we could name the ID's in the Octane Object Properties (Layer ID1 = Brick, Layer ID2 = Metal...)
Or even better, if the Layer Element is named by the material.
This way we get a clear and traceable output.

Layered .exr will be available in 3.0?

[HHbomb]

HI Jim, make Octane in max the most robust possible for the future.
hope that the converter will be not to rough.