OTOY Forums

I indeed export separate obj files and group them, if I have to change one of them I simply re-export it and the link to the materials is kept, nothing special to do. Believe me, it's the best way to have a efficient workflow. Of course this means that the scene should be organised to easily isolate the blender objects corresponding to one obj file. The octane node map quickly becomes messy but I can manage it, I think that with the new version and being able to close some node groups should help.

steveps3 wrote:Yes I am using the export script.

WOW if you are exporting the .OBJ every time then that must be a real pain? How do you link the materials, do you have to relink the pins every time you do a render? Do you render your scenes and a very large group of objects or do you export the whole scene every time. I guess if you were doing the former then it might not be such a pain and it would mean that you could just update a particular object. Still seems like a lot of work when up until version 1.21 the export script was doing an absolutely brilliant job.

I've been taking a look at the difference between what Lionel's script produces and what Octane produces. They are quite different.

If the .OCS is still in flux then surely this is just another reason why Otoy should be in charge of updating it. At least they know when it changes. I really am struggling to understand what is wrong with this scenario. Surely without the exporter then Octane is almost useless. In fact I had a whole speech lined up but your revelation to not using the exporter has sort of thrown a spanner in the works. I will carry on anyway. Octane is only useful when you give it something to render. If there is no way (or only a very complex way) of giving it something to render then what is the point? It is like making the worlds best racing car but forgetting to put any seats in it. Looks brilliant but you can't drive it.

stratified wrote:
Where can I actually download the exporter script, just to satisfy my curiosity. I think the file format is easy enough to fix but it's an ungrateful job maintaining it. Basically you jump to your feet every time somebody complains that something is broken

cheers,
Thomas

Believe me it would be far from an ungrateful job. You would not believe how indebted I would be if you could do something.

Oddly, Whilst I was away I thought that I'd give the blender plugin another chance. It was actually better than I remembered it. It still does weird things like when you create a new material it defaults to the blender diffuse material when obviously blender diffuse is not valid and doesn't appear in the list of material types. I'd still very much prefer to use the standalone version.

enricocerica wrote:I indeed export separate obj files and group them, if I have to change one of them I simply re-export it and the link to the materials is kept, nothing special to do. Believe me, it's the best way to have a efficient workflow. Of course this means that the scene should be organised to easily isolate the blender objects corresponding to one obj file. The octane node map quickly becomes messy but I can manage it, I think that with the new version and being able to close some node groups should help.

I thought that we were told that having lots of separate .obj files linked to a geometry group was slower? Maybe things have changed. I thought that was the reason why the blender plugin has the mesh type options because having a lot of movable proxy objects was slow

I feel that I do need to give the blender plugin a fair crack of the whip. I dismissed it way back when it was still in beta (or was that alpha) and it does appear to have come on quite a bit since. I still prefer the standalone though. I find the current node configuration to be very good for quickly making up materials.

I will have to give the multiple .obj method a try as well. So do you give them all placement nodes in order to move them around.

steveps3 wrote: So do you give them all placement nodes in order to move them around.

No, I don't, I usualy keep the placement made in the blender scene.
I'm working on a new interior scene using the Blender plugin mainly as a lighting exercice to achieve more crispy results, will post the results asap.

As always I will look forward to seeing it. Your work always amazes me.

Just given your method a quick try. I quite like it.

So you work on the whole scene in Blender. I thought that you may have just worked on assets and then combined them in Octane. i.e. model a car in one .blend. Model a house in another .blend combine the house and the car in Octane using placement nodes to position them correctly. That way you are just concentrating on the car or the house. This to me is starting to sound like a good way of doing things. It encourages the building of asset libraries.

Maybe lets go one step back and see how things developed in exporter land over the last years:

In the beginning, there was no API. So the only way to get stuff into Octane was via files. To support as many 3D applications as possible support for the most widely used geometry file format was added: Wavefront OBJ. Although limited it allowed third-party developers to quickly write exporter scripts with the following work flow:

• The user creates the scene in the 3D app
• Then runs the export script to export the scene as OBJ/MTL file pair
• The script launches Octane with some special command line arguments, which tell Octane to load the specified OBJ file into a mesh node (that's mostly important for the initial set up and can be skipped if OBJ/MTL files are only updated)
• Octane creates a new mesh node for this OBJ file, creates some preliminary materials from the material definitions in the MTL file and saves everything out as a OCS file
• The user then modifies the materials in Octane, renders and saves the OCS file
• If the user wants to modify the geometry, he can do that in the 3D app by modifying it and exporting it again. Octane will - after loading the previously saved OCS file - update the mesh node(s) and keep the materials linked to the material pins with the same name as they were connected to when the OCS file was saved the last time. That's the so-called "re-linking".

This workflow is obviously limited (especially the material export), but quite robust and still supported. So that's the official way of doing things.

The unofficial way of yoyoz' plugin is to write out an actual OCS file. That's still supported since we can read older OCS files. What is not working anymore is reading and updating OCS files, since the OCS files written by Octane >1.20 have a new format. When I saw the release of the first unofficial Blender plugin, I contacted yoyoz and explained to him that this approach doesn't work, because the OCS file format will very likely change in the future. And that has happened now.

Before there was an API, we were thinking about how to improve the communication between 3D apps and Octane. We had several options:

• Provide an official, documented file format perhaps with a library to read/write it.
• Provide a network API to feed data into a separate Octane process.
• Provide a DLL to integrate Octane into 3D apps.

The last option would have the lowest latency, highest speed (since data wouldn't need to be pushed through a file system or a network) and would allow the highest complexity of the interface (just functions, no serialization required), which made it our favorite option. In a quick and dirty test, Andrey got Octane building as a DLL and launching inside of 3ds max in about 1 or 2 days. After some initial work on the API, we got Octane rendering something in 3ds max in about 2 weeks. After that the decision was made to go the DLL route and I think it was the right decision.

All options above would have required that a new plugin is written for every 3d app that should support Octane the new way and obviously that has happened since then. And we are really happy that we could find developers who are willing to write and maintain the integration plugins, which give the user the highest comfort and best Octane support. Of course, these plugins are not free, but believe me the amount of work to do these tight integrations is much higher than what they get out of the plugins financially. So we should all be thankful for the work they have done.

Now, what does that mean for the standalone? It's true that with the advent of the integration plugins the standalone version lost a lot of its former importance, but it still has it's place, for example for those people that use 3D applications for which no integration plugins are available. It's also important for cloud rendering, for a dedicated render system and for testing (and for quickly playing with nodes). And although we have been focusing mainly on new features in the API and the render engine, we have some future plans for the standalone application, too. -> We are not planning to abandon the standalone application any time soon.

So what does that mean for Blender? The best way would be to use OctaneRender for Blender. If there are things missing, please let Jim know so he can add the required features to it. But I can hardly see where the unofficial export plugin offers any advantages over the integration plugin. The other option would be to use either the old official export plugin or to use the unoffical export plugin for exporting OBJ/MTL files only (without updating OCS files). I think these options should still work.

Cheers,
Marcus

abstrax wrote:The unofficial way of yoyoz' plugin is to write out an actual OCS file. That's still supported since we can read older OCS files. What is not working anymore is reading and updating OCS files, since the OCS files written by Octane >1.20 have a new format. When I saw the release of the first unofficial Blender plugin, I contacted yoyoz and explained to him that this approach doesn't work, because the OCS file format will very likely change in the future. And that has happened now.

I remember Lionel mentioning this very point. I knew that the current script was living on borrowed time.

I think that the last couple of days have been a bit of a voyage of discovery. I have been giving the blender plugin another go and it has improved greatly from its beginnings. I'm not saying that I like it but it is not as bad as I recently made out. So I guess that given a push that I may be able to work with it. I know for a fact that it cannot handle scenes that are as large as the standalone. I remember having quite a heated debate in the testing forum because it was consistently crashing on me.

I have also been trying out the multiple .obj/.mtl method and I am quite liking this. As you say it is very robust because it should be able to cope with any future updates to Octane.

Sadly neither option is, in my opinion, better than the exporter script. This was a complete dream to use. I really wish that someone could make some effort to update the script.

If I was to use the blender plugin then I'd really like to see it becoming a bit more of a dedicated product. It still feels like something that has been bolted on. Things like the Blender nodes floating around give it this feel. I don't see the point in displaying the nodes that cannot be used. Also when you create a new material, what is the point in having so many options in the material type. You only actually have the choice of the entries on the left hand side. I am not sure what the rest of the options are there for?

The multiple .obj/.mtl method works for me ...

I like to create measured/accurate objects in Revit and more fluid objects in Blender, then export to OBJ and import/group them in Octane Render standalone.

Whilst Cycles impresses - there is nothing to match the speed of Octane Render ...

I have the answer!

It was staring me in the face all along. What we (I) need is something that uses the recommended way of exporting to Octane combined with the ease of Lionel's script. Simple, all I need is a script that will

• Check if the project exists, if not then generate the project
  Check if the .ocs exists, if not then generate the .ocs
  generate the .obj/.mtl files
  call Octane using the command line pointing it at the project / .ocs

As I have said before I really don't worry about materials in Blender, I just set up vanilla materials and sort them out in Octane.

The good points of this method is that it should stay pretty stable as Octane evolves. It also gives a good degree of flexibility because it is so simple. A revision could be to have some way of identifying what objects in Blender are to be exported to the .obj. Perhaps the custom properties on an object could be used to form render groups.

What is the best news, for OTOY, is that I can probably do this myself. I'd have to work out what the minimum spec for a .OCS is. Perhaps you could help me with this? Other than that it will just be a case of hacking out some of Lionel's code to stop it worrying about regenerating the .OCS. All it needs to do is generate the initial .OCS and export the .OBJs. I can do the initial import of the geometry within Octane.

I feel a lot happier now.