OTOY Forums

Hi Paul,
Am I correct in saying that if we use ORBX for importing materials, we would not be able to make any changes to the material in Revit at all? So a textured render that is colour X, can't be changed in the plugin, correct?

Seeker

Hi Seeker

The ORBX save format for material defaults is exactly the same as for the current XML format - except with ORBX the texturemaps are contained inside the ORBX file - so there are fewer problems for people with absolute folder paths to texturemaps. In summary...Save As Default would save the current material in ORBX format instead of XML format. Load as Default would load the material from ORBX if there was an ORBX default, or XML if there was an XML default. The only difference you would find is if you have a material loaded from an ORBX default with a texturemap, if you click the button to change the texturemap, you will get the warning "This texture is in an ORBX package. Do you want to replace it with a texture from your file system?".

The other big plus with saving defaults in ORBX format is that when Octane changes the calibration of a pin (as happens from time to time, like with Exposure, or Scale), the Octane versioning system will automatically convert you 2.20 Default material to whatever version of Octane the plugin is using at that time.

And yes, you can edit a material that was loaded from an ORBX material in exactly the same way as you can with the current XML defaults.

Paul

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

2.16.0.24
- Fixed issue where importing from the LocalDb was applying the LiveDb Scale Factor from the Configuration
- Default materials are now saved in ORBX format rather than XML format. Old XML defaults will still load for materials, however all new defaults saved will be in ORBX format and supercede the XML defaults. Favorites are still saved in the old XML format, as are Views.

Due to the second change above - pls treat this release with the usual caution applied to TEST releases in this thread.

Paul

face_off wrote:Hi Seeker

The ORBX save format for material defaults is exactly the same as for the current XML format - except with ORBX the texturemaps are contained inside the ORBX file - so there are fewer problems for people with absolute folder paths to texturemaps. In summary...Save As Default would save the current material in ORBX format instead of XML format. Load as Default would load the material from ORBX if there was an ORBX default, or XML if there was an XML default. The only difference you would find is if you have a material loaded from an ORBX default with a texturemap, if you click the button to change the texturemap, you will get the warning "This texture is in an ORBX package. Do you want to replace it with a texture from your file system?".

The other big plus with saving defaults in ORBX format is that when Octane changes the calibration of a pin (as happens from time to time, like with Exposure, or Scale), the Octane versioning system will automatically convert you 2.20 Default material to whatever version of Octane the plugin is using at that time.

And yes, you can edit a material that was loaded from an ORBX material in exactly the same way as you can with the current XML defaults.

Paul

Thanks for clarifying, Paul. Do you think ORBX will eventually completely replace the XML format?

Best,
Seeker

Do you think ORBX will eventually completely replace the XML format?

Yes, eventually I would like to have the plugin save the Octane data in the .rvt file in ORBX format, and have all other import/export as ORBX, since then Octane will automatically do conversion of Octane nodes from earlier versions. But I also don't want to break anything, so this change will happen over a few releases.

Paul

face_off wrote:

Do you think ORBX will eventually completely replace the XML format?

Yes, eventually I would like to have the plugin save the Octane data in the .rvt file in ORBX format, and have all other import/export as ORBX, since then Octane will automatically do conversion of Octane nodes from earlier versions. But I also don't want to break anything, so this change will happen over a few releases.

Paul

Cool, thanks Paul.

Seeker

Hello
Not sure if this is the right place to post this.
I've been using Octane for revit for about a month now. I was wondering - how do you create a mirror texture? I tried creating a glossy texture and turning the roughness up but didnt seem to change much. Then tried creating a specular material and doing the same - resulted in a dark glossy material. Then tried a mix of glossy and specular but still nothing. Anyone got any ideas?
Thanks!

Sonnemanntoon wrote:Hello
Not sure if this is the right place to post this.
I've been using Octane for revit for about a month now. I was wondering - how do you create a mirror texture? I tried creating a glossy texture and turning the roughness up but didnt seem to change much. Then tried creating a specular material and doing the same - resulted in a dark glossy material. Then tried a mix of glossy and specular but still nothing. Anyone got any ideas?
Thanks!

Hi Sonnemanntoon,
Glossy material;
Specular high;
Roughness zero;
Play with the Index (of refraction) setting (not film index).

Hope that helps.

Seeker

Mirror would be Glossy with specular = 1, roughness = 0, IOR = 8, no bump, normal or displacement.

Paul

Hi Paul,

I just uninstalled my Octanerender for Revit (2.13 I believe, but it may have been a little newer) and installed the latest build on this Test thread (v2.16.0.24).

For some time now I have been limiting all non-Revit processes (which setting affinity is not blocked) to cpu's 1-4 (using a Powershell script) and running Revit isolated to CPU's 5-8 in high priority mode using a shortcut which uses cmd.exe to start the revit exe with some extra commands.
This method is not my ideal solution, but it is certainly not the first iteration of a solution to achieve the performance benefits with a single-click(ideal).

I did this because Most Revit functions (which affect 'snappy feel') are cpu constrained, and single-threaded (I know Revit does have some multithreaded capability now For Certain Functions).
Some people have been turning off hyperthreading, but my semi-educated guess is that it doesn't really achieve what they think it does. also, it still doesn't prevent windows streaming processes onto the core Revit is using (although I might be underestimating Windows on this one).

At any rate, this was all working beautifully, and Revit felt snappier either by placebo or actual benefit until I installed 2.16.0.24 and Revit could no longer find the dll. previously I had no issue... any ideas if something may have changed that prevents my hack method working?

EDIT: if I run Revit.exe directly (without any trickery) it finds the DLL fine... so I suspect either 2.16.0.24 or UR5forR2 has prevented me using my method...

Note: signature not up to date: I have UR5 for R2 installed (yesterday) if that matters - it might its the only other thing that's changed and I may not have run revit between installing UR5forR2 and reinstalling OctaneRender