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!
Plugin v1.19
- Attachments
-
- octanerender.v1.19.zip
- (62.01 KiB) Downloaded 2720 times
Desktop: Ubuntu 13.04 x64 - i7-3770K @ 3.5GHz - 32GB DDR3 - GTX670 2048MB
Laptop: Linux Mint 11 x64 - i7-2860QM @ 2.5GHz - 16GB DDR3 - Quadro 3000M 2GB
Software: NVidia 319.12 - Cuda 4.2.9 - Blender 2.66a
Laptop: Linux Mint 11 x64 - i7-2860QM @ 2.5GHz - 16GB DDR3 - Quadro 3000M 2GB
Software: NVidia 319.12 - Cuda 4.2.9 - Blender 2.66a
So if you don't wont objects to export you have to hid them manually? There should be a better way to do it.yoyoz wrote: - 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)
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'})]
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.
SW: Octane 3.05 | Linux Mint 18.1 64bit | Blender 2.78 HW: EVGA GTX 1070 | i5 2500K | 16GB RAM Drivers: 375.26
cgmo.net
cgmo.net
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.
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.
Desktop: Ubuntu 13.04 x64 - i7-3770K @ 3.5GHz - 32GB DDR3 - GTX670 2048MB
Laptop: Linux Mint 11 x64 - i7-2860QM @ 2.5GHz - 16GB DDR3 - Quadro 3000M 2GB
Software: NVidia 319.12 - Cuda 4.2.9 - Blender 2.66a
Laptop: Linux Mint 11 x64 - i7-2860QM @ 2.5GHz - 16GB DDR3 - Quadro 3000M 2GB
Software: NVidia 319.12 - Cuda 4.2.9 - Blender 2.66a
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.
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.

SW: Octane 3.05 | Linux Mint 18.1 64bit | Blender 2.78 HW: EVGA GTX 1070 | i5 2500K | 16GB RAM Drivers: 375.26
cgmo.net
cgmo.net
@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.
I think that RS should also do, because without a good exporter, they wouldn't have Blender users as customers.
French Blender user - CPU : intel Quad QX9650 at 3GHz - 8GB of RAM - Windows 7 Pro 64 bits. Display GPU : GeForce GTX 480 (2 Samsung 2443BW-1920x1600 monitors). External GPUs : two EVGA GTX 580 3GB in a Cubix GPU-Xpander Pro 2. NVidia Driver : 368.22.
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.
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.
(HW) Intel i7 2600k, 16GB DDR3, MSI 560GTX ti (2GB) x 3
(SW) Octane (1.50) Blender (2.70) (exporter 2.02)
(OS) Windows 7(64)
(SW) Octane (1.50) Blender (2.70) (exporter 2.02)
(OS) Windows 7(64)
- swingsoneto
- Posts: 3
- Joined: Mon Dec 27, 2010 1:49 am
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?
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: http://www.refractivesoftware.com/forum ... 373#p96373. Same constraints as for 1.19 apply.
Desktop: Ubuntu 13.04 x64 - i7-3770K @ 3.5GHz - 32GB DDR3 - GTX670 2048MB
Laptop: Linux Mint 11 x64 - i7-2860QM @ 2.5GHz - 16GB DDR3 - Quadro 3000M 2GB
Software: NVidia 319.12 - Cuda 4.2.9 - Blender 2.66a
Laptop: Linux Mint 11 x64 - i7-2860QM @ 2.5GHz - 16GB DDR3 - Quadro 3000M 2GB
Software: NVidia 319.12 - Cuda 4.2.9 - Blender 2.66a
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

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

2011 New Year Competition - 2nd Prize winning image
Visit my website: Fairview Studio 3D - Facebook page
i7 Quad-Core 2.67Ghz / 16Gb RAM / Windows 7 64bits / 2x GTX 680 / Octane v2.0 / CUDA Driver 6.0
Visit my website: Fairview Studio 3D - Facebook page
i7 Quad-Core 2.67Ghz / 16Gb RAM / Windows 7 64bits / 2x GTX 680 / Octane v2.0 / CUDA Driver 6.0
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.
SW: Octane 3.05 | Linux Mint 18.1 64bit | Blender 2.78 HW: EVGA GTX 1070 | i5 2500K | 16GB RAM Drivers: 375.26
cgmo.net
cgmo.net