Octane standalone is dead?

[ephdot]

If I'm getting this, then it seems that the fastest path forward might be to do the following:

1) Modify Lionel's exporter so that it can successfully export the OBJ and MTL files with the latest Blender.

2) Modify Lionel's exporter so that it builds a Lua script file that we pass to Octane.exe. The Lua script would also have the settings that would not make it into an OBJ (Camera, etc). Likewise, it would contain the code necessary to load the OBJ and MTL files we created.

3) Modify Lionel's script to invoke Octane.exe with the script file as a parameter. Upon invocation, the script file would see if there is an associated OCS file. If not, it will create it. The Blender UI could additionally have an option to overwrite the OCS if it exists.

When we invoke the exporter within blender the above steps occur and it finishes with an instance of Octane running with all of our items loaded. From there we would do as we always have done within Octane (tweak, render, save, etc).

For animations would it make sense to modify Lionel's as well where it runs as an iteration for all frames or would it make sense to make it work with alembic? If the latter is possible, it would be ideal as there would not be the need to export all for each frame.

[steveps3]

Well I'm making progress. I now having it working how I want it. This has been through a process of hacking / trial / more hacking / error.

I now have it so that the .obj is regenerated and Octane called. This results in new geometry being generated and all existing materials being unaffected.

Obviously the code is now just hacked and I really don't understand a lot of what I have done. There appears to be a lot of code repeated over and over but I assume this might be because single frames and animation have been coded separately.

I can certainly post a version of "my" script but it is certainly nowhere near complete. I did give it a quick animation test and sure enough it is broken.

[steveps3]

Oh no, tell a lie, animation does appear to be working.

[stratified]

Ok, so getting back to the LUA script. I get python to write the LUA script and then what? Can I then pass that script to Octane via the command line and get it to run the script? Is that the [--script <string>] parameter?

So
when the .OCS doesn't exist, generate the script, call Octane with the --script flag
when the .ocs does exist then call Octane with the .OCS filename


Could I not just use this instead? Wouldn't this just make it future proof?
-n <filename>, --new <filename>
Create a new OCS project file from given command line arguments

I think you're right steveps3.

I just read through the old exporter specification that Marcus posted. If there's an official Blender exporter flying around somewhere it should work on the Octane side of things (maybe it needs to be updated because the Blender API changed). The command line arguments of Octane didn't change and you wouldn't need lua at all.

cheers,
Thomas

[pixelrush]

To add to this, the original python script for Blender 2.49 is obsolete for 2.5x ,2.6x. Things changed a fair bit internally for Blender UI, API etc.
The circa 1.20 script I think works fine for exporting .obj/.mtl although perhaps there are a few rare issues with API name changes now that need updating, I am not sure how many but they are reportable because they will throw errors in the console - None type etc. The console will give clues where to find the error from recent trace back.
Where the script is most outdated is that it writes out the old .ocs format. To me it seems like too much work to fix and in light of the advent of the plugin maintained by Otoy.
I would have thought Octane was capable of reading old .ocs still but apparently not. Perhaps there are Blender API changes tripping up things in there too. This old .ocs capability could just be removed or commented out from the present script.
If the new. ocs is wanted it would be better and more future proof to get that out of Octane as regular save .ocs or to invoke Lua to do it IMO.
I am not sure we have defined the actual problem here yet or what it is we want to do about it and into the future.
Perhaps there are a few aspects. 1.Fixing occasional small API breakages - fairly easy 2. upgrading for .ocs2 and then future changes - seems involved/time consuming and 3. other large extensions arising like for Alemic - potentially involved again and perhaps better to rewrite virtually everything.
What is actually wanted/needed and how much effort do we want to put in keeping functionality working/extended?
Personally I don't use the.ocs out of Blender. I wonder how many people this .ocs issue affects?
What are peoples thoughts? We already hear some people work another way with grouping meshes.

[stratified]

Where the script is most outdated is that it writes out the old .ocs format. To me it seems like too much work to fix and in light of the advent of the plugin maintained by Otoy.
I would have thought Octane was capable of reading old .ocs still but apparently not. Perhaps there are Blender API changes tripping up things in there too. This old .ocs capability could just be removed or commented out from the present script

The script shouldn't writing the .ocs in the first place. The "official" exporter should be updated, not the one that writes .ocs files. Octane can perfectly read old .ocs files but the "unofficial" script is trying to interpret .ocs files in the new format, which it can't.

If the new. ocs is wanted it would be better and more future proof to get that out of Octane as regular save .ocs or to invoke Lua to do it IMO.
I am not sure we have defined the actual problem here yet or what it is we want to do about it and into the future.

Like said, I was wrong here. Read the official guidelines and you'll understand that all can be done via the command line params.

What should happen IMHO is that somebody ports the "official" exporter to the new Blender versions. The "unofficial" one should die, it only causes grief and confusion.

cheers,
Thomas

[steveps3]

Hmm, looks like the -n option is not working. Either that or I have done something wrong.

Here is the command line used

but Octane complains

Capture2.JPG (12.84 KiB) Viewed 3928 times

Can you spot anything?

No test2.ocs was created by the way.

[steveps3]

What should happen IMHO is that somebody ports the "official" exporter to the new Blender versions. The "unofficial" one should die, it only causes grief and confusion.

I would have to concur with this. Mind you people that use the script for animation may not be too pleased but I guess that the official path for animation of Alembic these days? Not that I am concerned because I don't do animations but there must be blender people that do?

[pixelrush]

Thomas,
The 'official' Blender script was done I believe by @radiance for Blender 2.49.
So your call if Otoy want to update/redo it for us.
As I said scripts made for 2.49 are obsolete for 2.5x 2.6x.
Lionels albeit 'unofficial' script is the port, except now it has .ocs issues and needs a little repairs.
I don't quite remember why it does write .ocs anyway...just Lionels initiative perhaps as he was thinking he might do the plugin.
Perhaps we can just strip out that and keep it .obj/.mtl focused.
The community script can continue as a lesser/basic solution to the plugin.
It seems as though there are a few users who could be satisfied with that level of functionality?
BTW its unlikely a community based script could/would conform to a guideline or 'specs' as to layout or, included features etc.
Blender participation just doesn't work that way in practice.
Be happy that a community script exists that allows Blender users to be Octane customers.
If they get really keen for the full experience they can move up to be plugin customers too.

[steveps3]

the .OCS contains the definitions for the materials. So Lionel's script needs to read the .OCS because you could change a glossy to a diffuse etc. In this respect I think that Lionel tried to get too clever. I really can't see anyone trying to set up their materials in Blender before they export to Octane. Yes you could define them as glossy / diffuse I guess but even that it more than is required.

If the guys at OTOY want to produce an updated OFFICIAL script then that would be cool. As for the unofficial script, as I say, it is working for me now. Hacking out the bits that generate the .OCS was only 20 lines of code. My attempts at getting a .OCS generated when there isn't one have failed so far but this isn't such a hardship. It just means that Octane complains when you first export (see above) but once you have manually created the .OCS it is fine.

I've attached my version of the script. Sorry it really is the bare minimum required. I didn't even change the version number or anything like that. You install it just the same way as you always do. I've also not touched the interface but obviously features such as "Create or Replace OCS file" don't work now.

octanerender.zip

(62.71 KiB) Downloaded 208 times