It seems the Revit finally has Octane 4.0. I'm sure it's been a hard couple of months and that you are quite worked up by this last update. I also know you've left a lot of items to be worked after this major update.

There are a few items which are more important for me, especially in order to be able to recommend using Octane on our 200+ office Revit render stations. I am thinking of:-Supporting Revit lights without having to modify our existing lights (adding an emissive surfaces in each light fixture)-Supporting C4R

Do you know if there is any kind of time-frame where this could be supported? I quite love Octane and would love to be able to implement it in our office. I think we would get much more out of it than Vray. I would also be interested in seeing the Revit roadmap if there is one available for us to peruse.

With regards to the link files issue, after some analysis, I can see 2 viable options for this.

1) Lock each Octane material to the source (linked) file. So if A.RVT is a linked file loaded by MAIN.RVT, the geometry will be loaded from A.RVT, and the Octane Materials stored in A.RVT will be used on the A.RVT geometry. If there is a "MyMaterial" material in A.RVT and a "MyMaterial" material MAIN.RVT, then the MAIN.RVT Octane material will be used on MAIN.RVT geometry and the A.RVT Octane material will be used on the A.RVT geometry. Octane materials in linked files will not be able to be material picked or edited. If you want to change the Octane material allocated to geometry in a linked file, you will need to open that linked file and edit the Octane material there.

or....

2) Octane materials would be matched by material name (as opposed to the current method of matching by the internal Revit element id). That means all geometry in the scene with a material name of "MyMaterial" would use the same Octane material named "MyMaterial" from MAIN.RVT. Any Octane materials stored in linked file would be ignored.

Please let me know your preference. Both options above are complex to implement, so I will need your support to test the change, and your understanding if there are on-going problems getting the change robust.

1, Ideally the materials from links should be manipulate (to apply octane material and to change) within the main.rvt.

2, when loading the links, Is it possible to add an indicator to the material shows where the material is loaded,

Such as "Material A" in rvt1.rvt in a shape like rvt1-Material_A, means just adding the link's name work together with the material name, so no matter what the origin name (or ID) is, they will never conflict with any other material (from the main or other link, sub link etc) I guess vray and even revit internal render engine are doing similar things, If we are looking into vray for revit's material, we can see from which link they are coming from.

3. since all revit projects are starting from given templates so all the revit default material that from different project will have exactly same ID , means they are born conflict with each other if to use the ID directly, I guess...

I have no problem to help you to testing your updates on this issue, just let me know when needed, I do want to see it is resolved eariler.

face_off wrote:With regards to the link files issue, after some analysis, I can see 2 viable options for this.

1) Lock each Octane material to the source (linked) file. So if A.RVT is a linked file loaded by MAIN.RVT, the geometry will be loaded from A.RVT, and the Octane Materials stored in A.RVT will be used on the A.RVT geometry. If there is a "MyMaterial" material in A.RVT and a "MyMaterial" material MAIN.RVT, then the MAIN.RVT Octane material will be used on MAIN.RVT geometry and the A.RVT Octane material will be used on the A.RVT geometry. Octane materials in linked files will not be able to be material picked or edited. If you want to change the Octane material allocated to geometry in a linked file, you will need to open that linked file and edit the Octane material there.

or....

2) Octane materials would be matched by material name (as opposed to the current method of matching by the internal Revit element id). That means all geometry in the scene with a material name of "MyMaterial" would use the same Octane material named "MyMaterial" from MAIN.RVT. Any Octane materials stored in linked file would be ignored.

Please let me know your preference. Both options above are complex to implement, so I will need your support to test the change, and your understanding if there are on-going problems getting the change robust.

Thanks

Paul

Hi Paul,Thanks for looking into this. I agree that it is needed. My cursory take is that our office would probably prefer your second method. This allows for uniformity between model materials.1. If you say that 'materials stored in the linked file will be ignored' (the 2nd method), how will those (ID-less) materials be displayed?2. This may not be directly related, but a common workflow with linked models would be linking existing buildings. This means they are created in a different Revit Phase. I know we had Octane issues in the past with losing materials when view Phase settings changed. I'd actually like to just check when back at my desk what exactly Revit does with Phase settings these days, but I'd like to make sure if you spend the time with this that it works also with linked models in different Phases - whatever that means we might have to explore further.

Re the option 2The good thing for the option 2 is when there is conflict, you can change the material's name manually to avoid the conflict.

The bad thing is there will be conflicts for sure, and you have to change the names manually one by one,and in a scene with 24 links, in each link there is 30 materials, guess you may want to turn to Vray directly.

Though Vray rendered really slow, yet it take 0 time on this, consider the work load for manually changing this and that, vray maybe much easier, at least the workload leave to people is much less, and in total time Vray may also be even faster.

So please take a look into how Vray is dealing with this kind of issue