OctaneRender 3 for Revit [OBSOLETE] Tweet

[face_off]

Would it be possible within the future releases of the plugin to give an option to store the texture files used when designating a default material?

I would imagine this would be a enable/disable option, with the ability to set a default path to save the files, similar to the ability to select the location of the texture files for the live database, and when selecting 'save as default' the plugin would duplicate the texture file to a designated location, and link itself to it.

This would mean that when creating an array of default materials, the texture files some of these are linking to will all be within a consolidated folder. This would also mean that if any of these texture files were either accidentally moved or deleted, or if one wanted to share their default library set-up, there would be no missing texture links.

This is an issue across all Octane plugins - specially those that are using in a multi-user environment, and I've tried a number of solutions - none of which have really provided a satisfactory solution.

Most Revit texturemaps will be sourced from the Revit texture library - so as long as other users have that version of Revit installed, the texturemaps will be in the same place. But for other texturemaps (those which you have manually linked to an Octane material and then done a "Save as Default" - those texturemaps won't be on other's PC'. So it's only really the non-Revit library texturemaps which are of concern - however there is probably not a definitive way to determine if a texturemap is a standard Revit library texturemap or not - so this creates an issue. Also, when the plugin copies a texturemap to the "default" folder, what happens if a texturemap of that name is already there?

In the short-term - you can manage all this yourself....create a older in a "common" area (ie. C:\ProgramData\OctaneTexturemaps), copy the texturemaps that are NOT standard Revit library texturemaps into that folder, then link to the Octane material and "Save as Default". Even better - save the texturemaps to Dropbox, or a network drive, then create a symbolic link to that folder from c:\MyOctaneTexturemaps.

Also, keep in mind that if the plugin cannot find a texturemap, it will ask the user for a folder to search for the texturemap - and this path is "remembered" for other missing texturemaps when loading the scene into Octane. So if all non-Revit library texturemaps are on c:\myfolder, and another user opens the scene and the texturemaps are in c:\yourfolder, they just need to point the plugin to that folder when the "Cannot find texturemap" dialog pops, and they will all be relinked.

Does that help?

Paul

[thefishnut]

In the short-term - you can manage all this yourself....create a older in a "common" area (ie. C:\ProgramData\OctaneTexturemaps), copy the texturemaps that are NOT standard Revit library texturemaps into that folder, then link to the Octane material and "Save as Default". Even better - save the texturemaps to Dropbox, or a network drive, then create a symbolic link to that folder from c:\MyOctaneTexturemaps.

Thank you Paul,
Fair points. I my self find that almost all revit texture files are not up to par with user created textures, so I am in the process of creating a lot of materials and saving them as default. I will explore the drop box option, as this would be an effective solution in the mean time.

Also, keep in mind that if the plugin cannot find a texturemap, it will ask the user for a folder to search for the texturemap - and this path is "remembered" for other missing texturemaps when loading the scene into Octane. So if all non-Revit library texturemaps are on c:\myfolder, and another user opens the scene and the texturemaps are in c:\yourfolder, they just need to point the plugin to that folder when the "Cannot find texturemap" dialog pops, and they will all be relinked.

Also I did not realise you implemented this feature. Fantastic.

Many Thanks Paul.

[face_off]

I will explore the drop box option, as this would be an effective solution in the mean time.

If you do this - store your texturemaps in Dropbox\OctaneTexturemaps, then junction link that folder to c:\OctaneTexturemaps using http://www.howtogeek.com/howto/16226/complete-guide-to-symbolic-links-symlinks-on-windows-or-linux/. You can also share you plugin defaults by copying C:\Users\[username]\AppData\Local\OctaneRender for Revit\Defaults into your Dropbox folder, and junction link to C:\Users\[username]\AppData\Local\OctaneRender for Revit\Defaults. Then each new default added in the plugin will by synced to Dropbox, and then shared to anyone else using that Dropbox account (they will need to setup the junction link to c:\OctaneTexturemaps and C:\Users\[username]\AppData\Local\OctaneRender for Revit\Defaults. Once setup, this is a very reliable, robust solution, and you can replicate it to new PC's with just 2 junction links.

Paul

[prehabitat]

Hi Paul,

I'm preparing for a new role & setting up a template: part of which involved starting with no materials & creating the ones i need then applying applicable appearance assets to them. While I was experimenting i found i could modify one of the autodesk standard materials to be seamless (in photoshop) then overwrite the autodesk shared material & Revit would unwittingly load that texturemap. At first this seemed like a boon; but after testing i found the octane plugin default system is so robust that it serves no purpose (except for tileless 'realistic mode' perhaps)
Can you think of a use for modifying the default texturemaps beyond realistic mode? Do we gain anything?
I am mainly referring to "All materials from the standard “Autodesk Materials” library and the “AFC Materials” library should bring across their default texturemaps when the plugin converts from a Revit material to an Octane material. However the texturemaps/bump maps for other materials (not in the above 2 libraries) will NOT be bought across from converted from the..."

Next question, relating to the testing i did with defaults: I did a bit of experimenting with assets & defaults and it seems the octane default is linked to the asset by some unseen unique identifier: ie duplicate assets (even unchanged) do not pick up 'default' for the original, and changes to the revit asset (even if it originally shared maps with the octane setting) do not update to the asset (although changing the map does)
This is all pretty fundamental stuff; and its likely the answers are "you'll only gain tile-less realistic mode, and yes; assets & thier octane defaults are unique one-way linked sets" am i right?

If so i think the best course of action is to make/replace the critical autodesk maps with seamless ones, do the symbolic link trickery to place the defaults in a syncing location, ensure my octane defaults use either seamless versions of default maps or new ones in the new syncing location and batch it for deployment.

[face_off]

I am mainly referring to "All materials from the standard “Autodesk Materials” library and the “AFC Materials” library should bring across their default texturemaps when the plugin converts from a Revit material to an Octane material. However the texturemaps/bump maps for other materials (not in the above 2 libraries) will NOT be bought across from converted from the..."

The Revit API provides no way to determine what texturemaps are assigned to a Revit material - so the standard texturemap assignments are pre-coded into the plugin. If you change a texturmeap for a Revit material, the plugin will not know, so won't pick this up.

Next question, relating to the testing i did with defaults: I did a bit of experimenting with assets & defaults and it seems the octane default is linked to the asset by some unseen unique identifier: ie duplicate assets (even unchanged) do not pick up 'default' for the original, and changes to the revit asset (even if it originally shared maps with the octane setting) do not update to the asset (although changing the map does)
This is all pretty fundamental stuff; and its likely the answers are "you'll only gain tile-less realistic mode, and yes; assets & thier octane defaults are unique one-way linked sets" am i right?

Setting the Octane default for an Octane material does not change the way to corresponding Revit material appears. It simply indicates that the next time that Revit material is used, if there is no Octane material in the scene for it - use the "default" Octane material that has been saved. So yes, you are right - it's one-way.

If so i think the best course of action is to make/replace the critical autodesk maps with seamless ones, do the symbolic link trickery to place the defaults in a syncing location, ensure my octane defaults use either seamless versions of default maps or new ones in the new syncing location and batch it for deployment.

Yes - this is the best workflow.

In the future, I think so of this will be simplified, because a) hopefully Autodesk to provide support in the API to obtain the texturemap names, and b) it may be possible to build support in the plugin to save "Default" Octane materials as ORBX in the users Octane Standalone LocalDb. Then only that folders needs to be copied between users.

Paul

[prehabitat]

In the future, I think some of this will be simplified, because a) hopefully Autodesk to provide support in the API to obtain the texturemap names, and b) it may be possible to build support in the plugin to save "Default" Octane materials as ORBX in the users Octane Standalone LocalDb. Then only that folders needs to be copied between users.

Paul

Thanks Paul: consolidating the octane materials (in plugins) sounds great, however it happens. for the meantime the default system makes the most sense since it auto-loads over the lesser Revit material automatically - even though its 'invisible' (or less visible).
I suppose the main advantage of defaults being linked to LocalDB is you can have defaults in Revit and Rhinoceros (in my case) which use the same material. I already do this manually - ut if 'grass 1' in Revit & rhino both used the same orbx/xml material automatically it would be neato!

Out of interest: what are the main differences between 'Save as Favourite' 'Save as Default' 'Export to LocalDB' (which saves as an orbx) and Export Material (which saves as an XML)??

[face_off]

Out of interest: what are the main differences between 'Save as Favourite' 'Save as Default' 'Export to LocalDB' (which saves as an orbx) and Export Material (which saves as an XML)??

Export Material - XML format. Obsolete now that you can save to ORBX/localDb
Save as Default - XML (same as Export Material).
Save as Favorite - XML (same as Save as Default, but saved to a folder which populates the "Favorites" combo box)
Export to LocalDb - ORBX. This is gradually become the preferred export/save format.

With the next major release of Octane (Octane 3?) I will probably change the Favorites and Defaults to ORBX format and deprecate the XML format.

Paul

[prehabitat]

Save as Favorite - XML (same as Save as Default, but saved to a folder which populates the "Favorites" combo box)
Export to LocalDb - ORBX. This is gradually become the preferred export/save format.

With the next major release of Octane (Octane 3?) I will probably change the Favorites and Defaults to ORBX format and deprecate the XML format.

In the meantime we can do our symbolic link trickery to make the defaults & Favourites for Rhino/Revit point to the same folder?

I'm really getting excited about how robust the solution is nowadays!

[face_off]

In the meantime we can do our symbolic link trickery to make the defaults & Favourites for Rhino/Revit point to the same folder?

Yes - although now the Rhino plugin has Octane materials as a type of Rhino material - there is no concept of Defaults and Favorites.

Paul

[face_off]

I have refreshed the installers at the top of this thread with:

2.16.0.22
- Compiled with Octane 2.16.
- Various additions/enhancements to emitters, including addition of "Surface Brightness" and "Cast Illumination" pin. See Octane 2.15 Standalone release notes for details.
- Removed ISO and FStop Imager pins. See Octane 2.15 Standalone release notes for details. Scenes saved with plugin versions prior to 2.16.0.24 will have the exposure converted to the new scale, however your default rendertarget "exposure" will not be converted - so you may need to adjust the default exposure and then "Save a Default"
- Added the scene load time into the Viewport statistics
- Added camera motion blur to Walkthrough animations. The plugin assumes 24fps (if your fps is different, adjust the shutter speed accordingly).
- Added option to export a Walkthrough animation to OCS/ORBX format (for loading into Octane Standalone)
- Reduced the mouse sensitivity during Viewport Navigation zooming
- Fixed issues with Viewport Navigation panning
- Daylight illumination power has been re-calibrated (pls see Octane Standalone 2.16 release notes for details). You may need to tweak the Daylight power of some pre-2.16 scenes to compensate.
- The plugin is now out of the Open Beta stage

Paul