Octane Render for SketchUp 3.03.2b Test Release Tweet

[CaptainCrowbar]

This update contains all the changes in the Octane 3.03.2 release.

The 2.x and 3.x plugins cannot be simultaneously installed with the same copy of SketchUp. Installing the 3.x plugin should replace the 2.x plugin if you already have it, although we recommend uninstalling any existing plugins first. If you install the 3.x plugin and want to go back to 2.x, you will need to fully uninstall the plugin before reinstalling 2.x.

Changes in the Octane 3 SketchUp plugin are mostly internal to the Octane rendering code; the SketchUp side of the application works pretty much the same as it did in the 2.x plugin. Changes to better integrate the new Octane features with the SketchUp user interface will be added in future releases, but this initial release is essentially the new Octane 3 rendering code integrated into the existing SketchUp plugin.

Major Changes (since 2.x)

* Like the Octane 3 standalone version, the SketchUp plugin uses the new single sign-on system. You still need to have purchased a license for the SketchUp plugin, but it will now be checked automatically when you log in using your Otoy account credentials; you no longer need to keep track of user IDs and passwords for individual licenses.

* Because most rendered images are now stored in your computer's main RAM instead of your video card's RAM (see the section on host film buffers in the Octane 3 feature list), all Octane 3 applications, including the SketchUp plugin, will frequently use a good deal more memory than their Octane 2 equivalents, especially for high resolution renders. You should keep this in mind when upgrading.

* The new authorization management window is a modal dialog where the user can sign out and sign in. It also informs the you under which name you are signed in and if that sign-in was in offline or online mode. When a user signs out, all of your licenses which were activated on this computer will be deactivated. This requires that all these licenses are currently not in use by other Octane processes. If that's not the case the sign out will fail.

* Because of ongoing changes to the license management system, you should avoid mixing different 3.x Octane installations on the same computer. Please make sure that all Octane standalone and plugin installations are the same version. (Expect this to be relaxed in future releases.)

* 3.03+ releases include experimental Pascal GPU support. Please note that we are still working on performance issues there.

SketchUp Version

- The plugin requires SketchUp 2015 or 2016 for Windows x64.
- SketchUp 2016 is recommended.
- If you are using SketchUp 2015, remember to select this when installing the plugin.
- If you have multiple versions of SketchUp, plugins are installed separately for each version.
- The plugin is not compatible with any x86 (32-bit) version of SketchUp.

System Requirements

- 64-bit Intel or AMD CPU.
- Microsoft Windows 7, 8, 8.1, or 10 for x64.
- Windows 10 compatibility is still provisional; Windows 8 or 8.1 is recommended.
- One or more recent model Nvidia GPU cards.
- Nvidia drivers 353.x or later; CUDA 7.5 support is required.

More Information

- SketchUp plugin manual (2.x)
- New features in Octane 3.0 (manual)
- New features in Octane 3.0 (forum)
- Octane 3.0 release notes
- Octane 3.03.2 release notes
- Post your questions here on this forum thread!

Support Information

If you have a support issue, please provide the following information:
- Operating system (e.g. Windows 8.1 x64)
- CPU type (e.g. Intel Core i7)
- Amount of RAM
- Graphics cards - model (e.g. Nvidia GTX 690 with 4GB)
- Nvidia driver version (e.g. 365.10)
- SketchUp version (e.g. SketchUp Pro 2016 version 16.1.1449 64-bit)
- OctaneRender for SketchUp version (e.g. 3.03.2.0)

The most important part of resolving a problem is our being able to reproduce the problem, so please provide as much detail as possible!

Download Links

- Current 3.x beta release
- Current 3.x demo release
- Current 2.x release
- Current 2.x demo release

Release Notes

3.03.2.0
- Compiled with Octane 3.03.2b SDK.
- Changes to file path handling code to address issue with user home directories on network paths.

3.02.0.0
- Compiled with Octane 3.02.0 SDK.

3.01.1.0
- Compiled with Octane 3.01.1 SDK.

3.0.1.21
- Compiled with Octane 3.01 release SDK.
- Added authorization management window

3.0.0.20:
- Compiled with Octane 3.0 release SDK.

3.0.0.4:
- Compiled with Octane 3.0.0 beta 4.
- Added a demo version.

3.0.0.1:
- Compiled with Octane 3.0.0 beta 1.
- Internal changes to texture rendering, LiveDB access, and licensing for compatibility with Octane 3 API changes.

[oscartung]

to be blunt what's the point of these releases if the fundamental problems are not addressed?

[resmas]

Come on guys...still no changes, no features...its still the incomplete V2 with a V3 tag.

For me this updates are useless.

hope some joy comes in a near future...

resmas

[smicha]

First, thank you Captain and Azen and all who is working on the SU plugin. Second please give us the nodal approach and all we've been asking for a very very long time.

[pasmangiu]

just give us our money back

[azen]

Hi,

Apologies for the lack of major additions in this release. Major work is still in progress It is important to ensure that, at the very least, that there is always a release that can work with the latest Standalone version. In this case, the Sketchup plugin can now support the GTX 1080 and other Pascal GPUs (a major addition for many users across the board).

Three major issues that are being handled at the moment:

- Lack of native features to integrate into means that a lot of the requested features needs to be built from scratch.
One example is the nodal approach - while, for instance, 3ds Max had a Slate Material editor integration, a nodal material editor for SU has no such feature to integrate with. This means it will have to be built from scratch inside SU.

- Flash dependencies for interface development.
This is particularly troublesome if features have to be created from scratch inside the application. Future updates to SU could potentially destroy a functional plugin

- Compatibility with other plugins could resolve, but introduces a complex web of dependencies
This is the quickest workaround whenever there is a plugin that can provide the base functionality that the plugin can integrate with (e.g. Skatter). Over-reliance on this approach will produce long-term issue we would like to avoid.


Apologies for the time it is taking to bring SU development to the required state. These are the challenges from the initial Alpha of this product that we need to overcome. Rather than rushing out workarounds for short-term benefit, there is a concentrated effort in progress to resolve the inherent challenges of this plugin and application, to ensure that this plugin is a reliable production tool.

Right now, the Flash dependencies for the SU interfaces has delayed the Mac release. Once this is cleared, it will be a lot easier to do what needs to be done to increase the current feature set.

[smicha]

Azen,

Thanks for reply. Just keep working and keep us informed on progress.

BTW Fuzzy started the nodal approach based purely on the standalone approach - exactly the same standalone interface was used when opening the node graph. Is there any chance to 'quickly' (if this is the right word) connect the standalone with its all features as a render engine to SU as a geometry feeder? Imagine this - geometry is created in the SU and all the rest is done in the active standalone-like window. If I remember well Fuzzy said something about this solution. What I am afraid that SU native material system (including any SU UV plugin) is very primitive and does not give even a fraction of flexibility of the standalone. Even Paul coded for modo ability to copy and paste the standalone material nodes which are far superior to the modo nodal approach. I would not try to code any 'from scratch' flash nodal approach but simply use the standalone interface which is perfect. And sorry for that - but current UI of the SU plugin is the wrong way to go, it is simply useless (at least for me). I only used it as an ocs exporter. Please don't go into wrong direction. My wish/dream (whatever you call it) is to hit a button and see the exact standalone interface connected to SU on my second monitor that wound be updated only when the position of SU geometry changes (only scatter data would be updated). If you keep all functions including geometry import, ocs import this is a ready solution for proxies. It would give a very fast way to replace geometry nodes with external geometry objs from e.g. zbrush, modo, c4d, max,....

Just keep it simple.

smicha

[resmas]

Hello All

Thanks Azen for the feedback.

As Smicha said your work update is important so we users can give you and Cap our feedback.

Dont go the wrong way.... Smicha is right about the nodal aprouch, the example of Mobo is perfect.
Standalone UI is awesome and if there was a way to open SU and use it as a "geometry editor" to Octane Standalone it would be amazing .

Offcourse the ability to control some features with SketcUp shortcuts allow a more user friendly setup.

We have talked about this main features:

- configurating a default Octane Materials Librarie to SU, basically we could help to create a Octane version of the default SU materials, so users with less knowledge can use the software in a simple way.

- control of the environment setup (sun, hour, and location) - we already have this

- the UI in Octane Render Window could have less settings... Only simple setup... For example, Samples control, resolution, imager tab, gpus, some camera functions, and 4 render setups like "fast render", "draft render", "Optimal Render", and "Production Render".
For advanced users all the settings would be in the node window

I think with a good foundation like this you guys could then control what features you could implement or adjust to the capabilities of the SU UI.

I believe flash and the on the fly communication between SU and Octane must be really hard, and for that reason IMHO you should reduce the "active stuff" that should only be accessible from the nodal aprouch.

That is way all major software uses the nodal aprouch. SU cannot handle all that control in a simple UI.

SU has a lot of uses.... Some more advanced then other, OCT4SU should stay simple, but allowing the more advanced users to take the most of this amazing software.

Some of us allready said, parallel to what I said before, if there was a way to:

Enhance the export ability... This way:

- open SU and export the 3D model to OCS/Orbx format.
- open Octane work in there, materials, etc etc etc
- for some reason we need to change the model or edit the geometry just reopen SU, edit, save and export again to OCs/orbx
- refresh in Octane.... Done.

This function updated the geometry, materials, render targets, nothing more.
Of course this only be possible if the export result would be more simple, the suggestions of Smicha to components and groups might help a lot.

Important to note that this function should exist parallel to the total integrated plugin, and at this time would be a great way to have a working V3 plug-in, because we would be allowed to use the V3 functions.

Cheers
Resmas

[oscartung]

Hi,

Apologies for the lack of major additions in this release. Major work is still in progress It is important to ensure that, at the very least, that there is always a release that can work with the latest Standalone version. In this case, the Sketchup plugin can now support the GTX 1080 and other Pascal GPUs (a major addition for many users across the board).

Three major issues that are being handled at the moment:

- Lack of native features to integrate into means that a lot of the requested features needs to be built from scratch.
One example is the nodal approach - while, for instance, 3ds Max had a Slate Material editor integration, a nodal material editor for SU has no such feature to integrate with. This means it will have to be built from scratch inside SU.

- Flash dependencies for interface development.
This is particularly troublesome if features have to be created from scratch inside the application. Future updates to SU could potentially destroy a functional plugin

- Compatibility with other plugins could resolve, but introduces a complex web of dependencies
This is the quickest workaround whenever there is a plugin that can provide the base functionality that the plugin can integrate with (e.g. Skatter). Over-reliance on this approach will produce long-term issue we would like to avoid.


Apologies for the time it is taking to bring SU development to the required state. These are the challenges from the initial Alpha of this product that we need to overcome. Rather than rushing out workarounds for short-term benefit, there is a concentrated effort in progress to resolve the inherent challenges of this plugin and application, to ensure that this plugin is a reliable production tool.

Right now, the Flash dependencies for the SU interfaces has delayed the Mac release. Once this is cleared, it will be a lot easier to do what needs to be done to increase the current feature set.

I'm really confused on the direction OTOY has chosen to go with the sketchup plugin.
How about providing a stable release before introducing anymore new features? There has never a stable release for V2 (i think there should be a refund or a partial refund), so whats the point nodal/skatter let alone MAC, 1080 support if the plugin crashes every 10 min or so.

It's even more frustrating to see a new login system being implemented so quickly (I manage to get standalone to work but the plugin never worked for me had to roll back to V2) while there has been no improvement to the plugin itself , talk about priority. What happened to the internal review Goldorak promised back in May?

[azen]

Hi,

Apologies for the lack of major additions in this release. Major work is still in progress It is important to ensure that, at the very least, that there is always a release that can work with the latest Standalone version. In this case, the Sketchup plugin can now support the GTX 1080 and other Pascal GPUs (a major addition for many users across the board).

Three major issues that are being handled at the moment:

- Lack of native features to integrate into means that a lot of the requested features needs to be built from scratch.
One example is the nodal approach - while, for instance, 3ds Max had a Slate Material editor integration, a nodal material editor for SU has no such feature to integrate with. This means it will have to be built from scratch inside SU.

- Flash dependencies for interface development.
This is particularly troublesome if features have to be created from scratch inside the application. Future updates to SU could potentially destroy a functional plugin

- Compatibility with other plugins could resolve, but introduces a complex web of dependencies
This is the quickest workaround whenever there is a plugin that can provide the base functionality that the plugin can integrate with (e.g. Skatter). Over-reliance on this approach will produce long-term issue we would like to avoid.


Apologies for the time it is taking to bring SU development to the required state. These are the challenges from the initial Alpha of this product that we need to overcome. Rather than rushing out workarounds for short-term benefit, there is a concentrated effort in progress to resolve the inherent challenges of this plugin and application, to ensure that this plugin is a reliable production tool.

Right now, the Flash dependencies for the SU interfaces has delayed the Mac release. Once this is cleared, it will be a lot easier to do what needs to be done to increase the current feature set.

I'm really confused on the direction OTOY has chosen to go with the sketchup plugin.
How about providing a stable release before introducing anymore new features? There has never a stable release for V2 (i think there should be a refund or a partial refund), so whats the point nodal/skatter let alone MAC, 1080 support if the plugin crashes every 10 min or so.

It's even more frustrating to see a new login system being implemented so quickly (I manage to get standalone to work but the plugin never worked for me had to roll back to V2) while there has been no improvement to the plugin itself , talk about priority. What happened to the internal review Goldorak promised back in May?

Hi,

While I went into more detail than perhaps I needed to, in a nutshell stability is the primary objective. Stability of the base features, as well as setting a stable development pipeline for future work. I wish to be upfront with the challenges that are being resolved - and they are being resolved. Ensuring stability has come at the cost of development speed, and we do apologize for the on-going inconveniences for this. In saying that, the current direction being taken is essential to providing the stable, production-ready product that will provide the return on investment our users should expect.

As for signing out of the plugin, what is the issue you are getting with signing out? The Deactivation window is functional, so any additional information to help duplicate the bug would be good.