Plugin v1.19 Tweet

[yoyoz]

This is a fix for the problem faced by Roubal during animation exports, and may not be required for people doing stills and/or not facing exact same issue as Roubal did, as you may have to adapt your workflow.

What has changed:
- the "Selection only" option is now ignored, you have to use one of the two others if you don't want to export all objects
- all layers are now exported, instead of only visible ones (this is required in order to have the fix working)
- the "Fly" animation button is back, exporting first frame and then only updating camera and sun for subsequent ones

Requirements should be same as for v1.17 (recent 2.63 builds).

Enjoy!

[matej]

- the "Selection only" option is now ignored, you have to use one of the two others if you don't want to export all objects
- all layers are now exported, instead of only visible ones (this is required in order to have the fix working)

So if you don't wont objects to export you have to hid them manually? There should be a better way to do it.
We had a similar issue in the Yafaray exporter.

This code will get you all objects that are on active layers, are not hidden for rendering but can be hidden for viewport visibility (you still want those exported). (edit: added test for type)

Code: Select all

[o for o in self.scene.objects if not o.hide_render and (o.is_visible(self.scene) or o.hide) and (o.type in {'MESH', 'SURFACE', 'CURVE', 'FONT'})]

This is the same how Blender internal works by default: an object does not get "exported" only if its not present on active layers or is present on active layers but is hidden for render (but not for viewport). IMO, this is how Octane exporter should work by default. The user could then have the additional option (in the Octane export settings) to remove visible, to remove from this list also all those that are hidden for viewport visibility. The option remove hidden could then be removed from the exporter entirely as it serves no purpose, but maybe still keep selection only , this one will then invalidate all the previously described process and export only the selected ones, even if they are hidden for renderability (for the record: I never use this option, but I guess others might)

EDIT: For a more seamless experience the exporting process to Octane should be exactly the same as rendering with Blender (minus the stuff that can't be yet exported to polygons). Having a significantly different way to specify what is to be exported and what not is not user friendly, IMO.

[yoyoz]

The issue is that the existing code to select objects is broken during animation, as well as selection context. I don't know if this is due to an API change, but v1.19 was made for allowing Roubal to keep on working on his project, while people not having same issue as him should stay on 1.17.

There are a lot of changes and cleanup I wanted to make and that I postponed waiting for the promised new file format among other stuff. It has been months now and I must admit I've lost interest in maintaining the plugin while nothing is done on Refractive side to support us. Huge progress could be made if RS had a different policy regarding their API, but there's little chance they change their mind so we're left until someone can pick it up and write the integrated plugin.

[matej]

I see. Didn't know about the api changes...

Yeah, the RS non-involvement is a bit frustrating (waiting for a better file exchange format since I remember).

Though, Roeland mentioned that (since they plan to support instances also for non-integrated 3D apps), they will (have to) think about changes in the exporting process / file format. As I mentioned in that thread, I hope the community will be make aware of the new specifications before they release new Octane versions. We don't fall in the "in-house closed" plugin development, so communication is important.

To the new management:
I hope Otoy is aware that Blender users are a big community (2nd biggest according to postcount) and that until now we didn't cost them a dime (thanks to you, Lionel). So being more forthcoming would be nice. But if they don't care about niceness, then they should consider that a lot of users (if not most) are willing to pay for an integrated plugin. Don't consider Blender users cheapskate and poor amateurs, just because we don't use overpriced 3D apps from big industry players.

[ROUBAL]

@yoyoz : I want to thank you publicly here for your devotion to the community !

I think that RS should also do, because without a good exporter, they wouldn't have Blender users as customers.

[steveps3]

By the sound of it 1.19 is not for me but I would like to add my voice of praise to the work that Lionel has done to make the Blender exporter the thing that it is.

There are still a few things that I'd like to see added to the exporter, such as being able to export particle systems without either making them real or setting up an partical instance, but for the vast majority of things the exporter really is wonderful.

[swingsoneto]

hey guys, out of curiosity, is there a v1.18 between the 1.17 and 1.19 exporters? i'm using blender 2.63 rev 47388. if not, should i be using the 1.19 exporter or 1.17? which works best for general export?

[yoyoz]

Hi, v1.18 was only for testing a bug fix with a user and has not been published. If you don't plan doing animations you can safely stay with 1.17, otherwise you can go to 1.20 which is found here: viewtopic.php?p=96373#p96373. Same constraints as for 1.19 apply.

[madcoo]

Hi everyone,

I've got a question:

I'm planning to switch to Blender's latest version (2.63a) - yeah I know I'm a decade late

1) I'd like to be able to export stills AND animations.
2) I'm using Octane's KEPLER Build
3) I read in this thread that animations should be exported using v.1.17

=> will the 1.17 exporter work well with Blender 2.63a AND with Octane's Kepler Build ?

Many thanks in advance for your help

[matej]

Yes the 1.17 is the best way to go with Blender 2.63a. Which Build of Octane it is it doesn't matter, the exporter communicates the same with them all.