OctaneRender for Revit Beta 1.32 [OBSOLETE] Tweet

[face_off]

This is the recommended thread for downloading, and posting any questions, suggestions or support queries for OctaneRender for Revit, build 1.25.0.1 (TEST RELEASE) onwards. This version is compiled against Octane 1.25+, so see the requirements for that build regarding compatibility with your video card.


Scenes saved with this build cannot be loaded with the 1.20 build, so make sure you keep a backup of the 1.20 scenes

If you have a support issue, pls provide the following information:
- Operating System (ie. Win XP, Vista, 7, 8)
- 32 or 64 bit
- Amount of RAM
- Graphics Card(s) - model (ie. GTX 580, 3GB)
- Nvidia driver version
- Revit version and build number (Help -> About Revit -> Build Number)
- OctaneRender for Revit version (ie. 1.02a)

Change Log from release 1.20.1
1.25.0.1
- Compiled against Octane 1.25 - so substantial changes to the underlying plugin code
- Pin names/node names changed to be more user friendly
- Save to OCS (Octane Standalone) added to the rightclick menu of the Settings tab
- All "scale" pins have been replaced with transform nodes. So you can apply different projections to texturemaps and procedural textures. Old scales from your saved scenes are not retained.
- Converting material with rotated texturemaps is not working correctly yet - but texture scales are working.
- Improved logging. Open the Cuda Log (devices tab) to see any general Octane errors and/or logging.
- Camera motion not implemented (unsure if anyone needs this from Revit or not)
- If you want to rotate an IBL, set the project the Spherical and move the rotatation sliders.
- If a Octane referenced texturemap is not found when loadin = g a scene, the plugin allows the searching for the file. If you abort from the search dialog, all further searching for texturemaps is disabled until a new scene is loaded. Missing texturemaps will be reported as an Octane/Cuda error too.
- Daylight environments now default to a sun position directly overhead (ie. 0, 1, 0)
- It is strongly recommended that you delete your default rendertarget settings (delete C:\Users\[username]\AppData\Local\OctaneRender for Revit\Defaults\Rendertarget.xml) and recreate them again in the plugin. This will ensure the new daylight structure is saved in your default rendertarget.
- It the plugin requests reactivation, you will need to de-activate from the Otoy website and re-activate the plugin
- Scale nodes have changed such that an Octane 1.20 scale of 10 is an Octane 1.25 scale of 0.1. So old scenes will load with an incorrect scale.
- The camera "scale" pin be no longer be set - use the "fov" pin instead.

For more information...
- Read the on-line manual
- Read the FAQ
- Post your question on this forum thread

Limitations
Refer to the on-line manual

Download Links
Download the plugin from the following links:
- OctaneRender for Revit 2014 1.32.0.3 beta (64 bit)
- OctaneRender for Revit 2013 1.32.0.3 beta (64 bit)
- msg me for the 2012 build.

Paul

[Seekerfinder]

Hi Paul,
Thanks for the new build. I really appreciate your continued commitment to keep improving the Revit plugin.

A few questions:
1. Stupid question I guess but who knows... do I have to have Standalone 1.25 installed for this version to operate or does it operate independently from Standalone?
2. You have a few Rhino references in your post. Was it just late at nigh and can we just replace the rendertarget filepath Rhino reference with Revit (I have not been following this forum of late so again I might be missing some context?)

- Save to OCS (Octane Standalone) added to the rightclick menu of the Settings tab

This is great! Thanks Paul!!

One other (unmentionable) plugin currently under development will be able to import .OCS files to replace proxies in the host.... I am still holding out for this feature in the Revit plugin. Like mentioned before, it would be really great to import .OCS files that were properly textured in standalone. Any chance of seeing this feature soon?

Best,
Seeker

[face_off]

Hi Seeker

1. Stupid question I guess but who knows... do I have to have Standalone 1.25 installed for this version to operate or does it operate independently from Standalone?

You only need Octane Standalone 1.25 if you intend exporting from Revit and loading into Octane Standalone (since the OCS files are Standalone 1.25 compatible).

2. You have a few Rhino references in your post. Was it just late at nigh and can we just replace the rendertarget filepath Rhino reference with Revit (I have not been following this forum of late so again I might be missing some context?)

Yes - cut and paste errors. Fixed now. TY for pointing these out.

will be able to import .OCS files to replace proxies in the host.... I am still holding out for this feature in the Revit plugin. Like mentioned before, it would be really great to import .OCS files that were properly textured in standalone. Any chance of seeing this feature soon?

In theory the latest Octane API potentially supports this, although I haven't looked too deeply into it. There will potentially be some conflicts with the OBJ import system - since the OBJ system allows you to edit the materials - whereas the OCS system would not.

Also, if you were going to do this, wouldn't it be simply easier to merge the proxies into the scene in Octane Standalone?

What functionality is this giving you that you don't already have?

Paul

[Seekerfinder]

will be able to import .OCS files to replace proxies in the host.... I am still holding out for this feature in the Revit plugin. Like mentioned before, it would be really great to import .OCS files that were properly textured in standalone. Any chance of seeing this feature soon?

In theory the latest Octane API potentially supports this, although I haven't looked too deeply into it. There will potentially be some conflicts with the OBJ import system - since the OBJ system allows you to edit the materials - whereas the OCS system would not.

That's ok, some elements (like pre-textured Xfrog trees for example) are pre-textured by others, in which case there is often no need for engaging Octane's material system.

Also, if you were going to do this, wouldn't it be simply easier to merge the proxies into the scene in Octane Standalone?

The answer for me is, no. I think for me (and many others) the ultimate goal is to achieve an integrated un-fragmented workflow for architects. Revit has offered a real potential for an all-in-one design / documentation tool for architects. Except with regards to rendering. Your plugin offers a great solution and the very purpose of a plugin is convenience and an unbroken / integrated / real-time / updated solution. So going out of Revit to Standalone (which used to be my workflow) breaks this again. We're kinda going backwards if we do that in my view.

What functionality is this giving you that you don't already have?

Well, first of the node system in the plugin is really not a node system at all in my view, it only references Standalone's nodes. There is no node-type GUI, making it much harder to work efficiently with material texturing. Standalone's node system gives us the opportunity to create great, efficiently textured objects in standalone (from any OBJ) that we could roll out in the company or even sell online. The workflow in such a scenario is not broken since the task of creating a well textured object library (furniture, cars, art, even perhaps people) could (and should) be a separate, focused exercise, not something that happens in Revit when a deadline is looming - we should just be able to drop in those objects using the proxy feature, already well textured with low memory footprints. I could well imagine us building up a great library in the office which, when brought into Revit, require no further tweaking.

I think the ability to import OCS files (preferably also with instancing) would add significantly to the usability of the product for most offices / users.

Best,
Seeker

[face_off]

Thanks for your thoughts Seeker.

One of the challenges that come to mind with this is that when you load an OCS, the plugin will not actually know if there is a mesh object in that scene - so it will require the user knows what they are doing in order to put together the source OCS file.

I will add it to the "long-term" list - since there are other things that may happen with the Octane API which will influence this. For example, it might be neat to be able to load a material from an OCS into the plugins via the API. Then all the plugins could swap export and import Octane materials via OCS.

Paul

[Seekerfinder]

One of the challenges that come to mind with this is that when you load an OCS, the plugin will not actually know if there is a mesh object in that scene - so it will require the user knows what they are doing in order to put together the source OCS file.

I guess that could be assumed when someone actually does an OCS import / link.

I will add it to the "long-term" list - since there are other things that may happen with the Octane API which will influence this. For example, it might be neat to be able to load a material from an OCS into the plugins via the API. Then all the plugins could swap export and import Octane materials via OCS.

Thanks Paul, I'd love to see that happen. Not quite sure what you mean by swapping importing / exporting materials. Are you referring to XML files? Currently, all the plugins can already access the live DB - that is why I find it confusing why can't create our own materials in standalone and just load it onto a local database of materials to import into the plugins - like a 'localDB' (or can we...?). Nonetheless, there is still a benefit to actually texturing library objects in Standalone and bring into the plugins in OCS format for reasons mentioned above, not least being the benefit of doing detailed procedural texture mapping with a small mem footprint much more easily.

Best,
Seeker

[face_off]

Thanks Paul, I'd love to see that happen. Not quite sure what you mean by swapping importing / exporting materials. Are you referring to XML files? Currently, all the plugins can already access the live DB - that is why I find it confusing why can't create our own materials in standalone and just load it onto a local database of materials to import into the plugins - like a 'localDB' (or can we...?).

I lot has been done under the hood with Octane 1.25+, and this sort of thing is almost possible now (or might be already - we just haven't had time to sort through it all).

Paul

[Seekerfinder]

Thanks Paul, I'd love to see that happen. Not quite sure what you mean by swapping importing / exporting materials. Are you referring to XML files? Currently, all the plugins can already access the live DB - that is why I find it confusing why can't create our own materials in standalone and just load it onto a local database of materials to import into the plugins - like a 'localDB' (or can we...?).

I lot has been done under the hood with Octane 1.25+, and this sort of thing is almost possible now (or might be already - we just haven't had time to sort through it all).

Paul

Great to hear! Can't wait to see some of those long anticipated features materialise.

Best,
Seeker

[Seekerfinder]

Hi Paul,
I got this error (below) today. But more worrying was the fact that the screen was black with no image.

Then, when I tried to navigate in the OVP (the viewport navigation was on by default), I got:

1.25.0.1 navigation crash

I could not get out of the plugin either. Had to stop Revit in the task manager.

I'm finally on my new system: Win 8, Revit 2014. I do not have the 1.2 plugin installed on this machine. Standalone version in 1.20.

Let me know should you need any more info.

Best,
Hendrik

[face_off]

Hendrik - I think that there is some old Octane 1.20 settings in the RVT file causing this. Perhaps it is the sun vector at 0, 0, 0 (which would throw an error such as this). Could you pls reload the RVT file, and check the sun settings in the Settings tab.

EDIT: Could also be the aperture or scale being out. If we can identify the cause, I can code the latest version to ensure this does not happen.

EDIT2: It might also be a 0, 0, 0 camera up vector.

Paul