This lead to the feature request: it would be really useful if we had a --render-target switch which would tell Octane which render target node to use for rendering, similar to the --mesh-node switch that tells which mesh to render. This way we could automate rendering of some scene with different settings (camera, resolution, etc..), without the need to be behind the computer & manually start render jobs or messy tricks like duplicating .ocs files.
OctaneRender® 1.025 beta2.58b test release [Obsolete]
Forum rules
NOTE: The software in this forum is not %100 reliable, they are development builds and are meant for testing by experienced octane users. If you are a new octane user, we recommend to use the current stable release from the 'Commercial Product News & Releases' forum.
NOTE: The software in this forum is not %100 reliable, they are development builds and are meant for testing by experienced octane users. If you are a new octane user, we recommend to use the current stable release from the 'Commercial Product News & Releases' forum.
I have a small feature request regarding render targets. I have set up the scene with a custom render target and pluged the mesh into it, like it's visible on the screenshot:
The first problem appears when you click on the mesh node - it actually starts to render the render target that is set up in the "preview configuration", instead the one that the mesh is plugged in. Ok, this is not really a problem, cause you can click on the custom render target node to start it. But if you run Octane from the command line, you can't render the custom one, because Octane always starts the one that is defined in the "preview configuration". This is probably a bug or something, because it should render with the settings that are defined in the render target where the mesh is plugged in.
This lead to the feature request: it would be really useful if we had a --render-target switch which would tell Octane which render target node to use for rendering, similar to the --mesh-node switch that tells which mesh to render. This way we could automate rendering of some scene with different settings (camera, resolution, etc..), without the need to be behind the computer & manually start render jobs or messy tricks like duplicating .ocs files.
This lead to the feature request: it would be really useful if we had a --render-target switch which would tell Octane which render target node to use for rendering, similar to the --mesh-node switch that tells which mesh to render. This way we could automate rendering of some scene with different settings (camera, resolution, etc..), without the need to be behind the computer & manually start render jobs or messy tricks like duplicating .ocs files.
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
Major slowdown the first 10 sec of rendering when reloading a heavy scene (many textures) with a changed OBJ. Almost impossible to navigate.
Didn't happen in v2.57.
Didn't happen in v2.57.
Win 11 Pro | i5 12600K | 32GB ram | 2x GTX 1080Ti + 3080Ti - studio driver 560.94| Modo/Blender/ZBrush/Daz/Poser
They're on at default. I tryed to close the ones showing in the node inspector but it didn't help.roeland wrote:Were you using the material preview?
--
Roeland
Win 11 Pro | i5 12600K | 32GB ram | 2x GTX 1080Ti + 3080Ti - studio driver 560.94| Modo/Blender/ZBrush/Daz/Poser
It happens after voxelizing right when I open the project! You can't reproduce?roeland wrote:What were you doing at the time of the crash?colorlabs wrote:I'm getting a crash, I've attached the scene and OSX crash report.
--
Roeland
Mac OS X 10.8.0 | ASUS GTX 580 1.5GB | MSI GTX 470 | ATI Radeon 6870 | Core i7 2.9Ghz | 16GB
OK, we can reproduce it, and we can fix it. The file seems to be missing the default preview configuration node. What version of Octane did you use to save this file?colorlabs wrote:It happens after voxelizing right when I open the project! You can't reproduce?roeland wrote:What were you doing at the time of the crash?colorlabs wrote:I'm getting a crash, I've attached the scene and OSX crash report.
--
Roeland
--
Roeland
Yay!! The file was generated by the Cinema 4D pluginroeland wrote: OK, we can reproduce it, and we can fix it. The file seems to be missing the default preview configuration node. What version of Octane did you use to save this file?
Mac OS X 10.8.0 | ASUS GTX 580 1.5GB | MSI GTX 470 | ATI Radeon 6870 | Core i7 2.9Ghz | 16GB
thanks for update.
I totally agree with the idea to remove or put in background task the 'pop-up' voxelising message, that's a point i've ask to you some month ago. Please do it, it will be great for animators!
Another thing: i've just tested the "Summer of code 2011" build ( version 45946 64bits compiled by tungerz -> only this one actually has this feature ) of the (excellent) cycles for blender, and there's something very very good: the BHV structure ( the process for voxelising like in octane) is MULTITHREADED and it is wonderfull on an intel 2600K: near REALTIME, for complex high polygons geometries ( normaly the same geom. could take more than 15-20 seconds, now less than 0.5sec. !!! ).
It would be so great to see this in octane: RSTEAM please look at this because the voxelising process in octane is still slow ( compared to this of course ). Thanks.
I totally agree with the idea to remove or put in background task the 'pop-up' voxelising message, that's a point i've ask to you some month ago. Please do it, it will be great for animators!
Another thing: i've just tested the "Summer of code 2011" build ( version 45946 64bits compiled by tungerz -> only this one actually has this feature ) of the (excellent) cycles for blender, and there's something very very good: the BHV structure ( the process for voxelising like in octane) is MULTITHREADED and it is wonderfull on an intel 2600K: near REALTIME, for complex high polygons geometries ( normaly the same geom. could take more than 15-20 seconds, now less than 0.5sec. !!! ).
It would be so great to see this in octane: RSTEAM please look at this because the voxelising process in octane is still slow ( compared to this of course ). Thanks.