Unification of server versions Tweet

[Andreas_Resch]

Alongside the issue of converting old files and having to run/activate old server programs, there's another issue that's bugging me for a long time. The lack of flexibility in the server apps. With every new release a dedicated server app is required to be able to talk to the host application. Of course that eventually leads to a lot of clutter and chaos.

It would be so much better if the server app was backwards compatible or we could at least chose between server iterations from with the server app. On top of that it would be much better if the server app would update itself and we would not need to manually uninstall/install server versions with every release. This would take a lot of burden off of the user and lead to much less confusions about the individual server version on would have to run.

[linograndiotoy]

That would be cool, but I don't think it's something possible. Each server is dedicated to a defined version, with its well defined code,exactly as we have several Standalone versions.

I'm keeping several OctaneBlender versions installed, each one with the relative Server, accurately named. Many users are doing exactly the same.

Auto-update would put old projects at risk.

[Andreas_Resch]

Well. It's worth to pitch it and I don't see why it should not be possible. Of course it's a bit of work.

What does the server app actually do? Just checking the license or is the app that actually renders the images?

[linograndiotoy]

Well. It's worth to pitch it and I don't see why it should not be possible. Of course it's a bit of work.

What does the server app actually do? Just checking the license or is the app that actually renders the images?

It's the render engine, of course.

[Andreas_Resch]

Then therein lies the root of the problem and makes the whole app infrastructure much harder to handle. Still possible but with the render servers not being backwards compatible this is a bit of work. This was probably planned wrong from the head start.

[linograndiotoy]

Then therein lies the root of the problem and makes the whole app infrastructure much harder to handle. Still possible but with the render servers not being backwards compatible this is a bit of work. This was probably planned wrong from the head start.

If you take a look to any other Octane integration, you'll notice how we have dedicated builds for specific versions of the software. It works like that for Cinema, LightWave, Modo, Houdini...basically all of them.

Not to mention that Blender adds more complexity to it, due to its license and the important changes happening in each new version. Any Octane addon needs to deal with it, not just Octane.

The addon version is going to solve the important issue of needing a custom build, and it's also "back compatible" already.
But about the Octane Server, well, I don't see any chance to make it back compatible.

I have several versions of Blender and the relative Octane Servers installed on my system, in properly named folders.

Any 3D artist working on personal or commercial productions needs to be sure to be able to open some "old" project using the version used at the time it was worked on, because newest version can give different results.

That's a common issue anyone needs to deal with, whatever software is used.

An improvement I can see doable would be to make so the installers could include the version number in the folder name used for both the custom build and Octane Server installation. That would help users putting some order.

[Andreas_Resch]

I'm on 28.5 (addon) still and that one isn't backward compatible. But it's good to hear that the newer addon versions are. Because when I look at an old file, I have not clue in which version of Octane it was saved. And as I mentioned before, there were some compatibility breaks already and as of now, I can't confidently open older files. Which isn't too bad as they are basically just test scenes. But it gives me some anxiety about what's to come if such occurrences become "normal". As of nor I don't feel comfortable to create a material of object library because I have no clue if it will work properly 2 or 3 versions from now. I've already had to update my Octane material libraries twice and I've put it on hold for now until I feel more safe about the future of Octane and the addon development. It's too chaotic and brute force as it is of now.

So basically my interest in Octane is on hold for now. For one the irrational studio/prime version release cycle is not only annoying but also confusing. And then there are too many big bugs in there (for quite a while now) that have to be solved first. So it's back for me to observing the releases. I'm still hopeful though. Although Cycles is catching up a bit it's not really there yet and the other alternatives aren't any more enthusiastic either.