Post 4.0 To Do List Tweet

[face_off]

Thanks for the feedback.

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?

It would be easy to grab the Octane material definition from the linked file in this situation.

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

I think that if you load a MAIN.RVT file which contains a link to LINKED.RVT, whist MAIN.RVT is open, there is no way to save changes to LINKED.RVT, so if it were possible to edit the Octane materials from LINKED.RVT whilst MAIN.RVT was open, the changes would need to be saved to MAIN.RVT. This introduces a further problem. LINKED.RVT is actually referenced as the full path name (ie. c:\myfolder\LINKED.RVT). So if you move MAIN.RVT and LINKED.RVT to another folder (say c:\myfolder2), all the Octane materials saved in MAIN.RVT for LINKED.RVT would be lost (because the filename of the linked file would be different from that saved in the MAIN.RVT file). So I am doubtful that I could make Octane materials in linked files editable.

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.

As stated above - I think this makes a major assumption that the .RVT filename is unique (so that all LINKED.RVT files present in your file system are the same). You may have MAIN.RVT contain c:\myfolder\LINKED.RVT and c:\myfolder2\LINKED.RVT - and they are separate and different linked files with the same name.

Ideally a .RVT file would have a unique reference number which the plugin could use to uniquely identify materials - but it doesn't have this. Using the filename is going to cause problems, due to the folder name being part of the filename, and it will therefore change when you move the .RVT file.

Based on the above, I feel option 2 is the better option. But I understand this may not be perfect, so is it worth doing at all?

Paul

[jimho]

I think that if you load a MAIN.RVT file which contains a link to LINKED.RVT, whist MAIN.RVT is open, there is no way to save changes to LINKED.RVT,

True

so if it were possible to edit the Octane materials from LINKED.RVT whilst MAIN.RVT was open, the changes would need to be saved to MAIN.RVT.

This is actually what we want, change for that material should be saved in Main.rvt because it is where the view from, and actually shoud not be saved inr link.rvt, because from another main2.rvt's view, we may want this link.rvt look different.

This introduces a further problem. LINKED.RVT is actually referenced as the full path name (ie. c:\myfolder\LINKED.RVT). So if you move MAIN.RVT and LINKED.RVT to another folder (say c:\myfolder2), all the Octane materials saved in MAIN.RVT for LINKED.RVT would be lost

just FYR, Vray do have this kind of moving folder issues, similar to octane project transfer between PCs, if there is a clear guide which folders or files need to be moved together with the project, this may be viewed as work flow resolvable issue.

]As stated above - I think this makes a major assumption that the .RVT filename is unique (so that all LINKED.RVT files present in your file system are the same). You may have MAIN.RVT contain c:\myfolder\LINKED.RVT and c:\myfolder2\LINKED.RVT - and they are separate and different linked files with the same name.

In Vray's solution, c:\myfolder\LINKED.RVT and c:\myfolder2\LINKED.RVT are as different file, I think it is right

Based on the above, I feel option 2 is the better option. But I understand this may not be perfect, so is it worth doing at all?

As you mentioned the change for the plugin will make quite some workload for you, so before you go it should be a at least a strategy which really worthy, my view is this option 2 makes very small refinement, and not the right direction.

Strongly I suggest if you can look into Vray's solution, which is practically workable...
Thanks,

Jim

[face_off]

As you mentioned the change for the plugin will make quite some workload for you, so before you go it should be a at least a strategy which really worthy, my view is this option 2 makes very small refinement, and not the right direction.

OK, I will take a closer look at what can be done with that solution.

Paul

[prehabitat]

think that if you load a MAIN.RVT file which contains a link to LINKED.RVT, whist MAIN.RVT is open, there is no way to save changes to LINKED.RVT,

If LINKED.rvt is a worksharing file you can save changes to the link while it’s loaded in the MAIN.rvt...

I vote option 2 too, with preparation I feel it’s more flexible.
ie. can make global changes to materialA in main.rvt which will affect the link geometry too...
only one document library to manage,
could have proxy materials assigned within the link pretty easily and presumably pick & substitute from in the main.rvt

[jimho]

I vote option 2 too, with preparation I feel it’s more flexible.

the current issue with the materials from the linked project is they are ignored, not loaded into the main scene. Since the materials are ID oriented, and cannot be touched by revit user, so it is no means even to get the lost material back.
Now our developer provides the "Option 2" which alter the ID oriented to material name oriented method when loading the materials, means the materials which are ignored now will still be ignored, but you can manually change the names in the sub link to let them in. This is a little bit improve, but far from enough.
To change the names manually can be too huge amount of work in a normal architectural scene.

As mentioned in the previous a few posts, the materials in the links should be translated into the main automatically, and can be substituted to oc materials.
It is kind of Option 3...

[face_off]

An update on this issue......I posted a test build with option 1, and unfortunately it contained some substantial issues which ended up in the Octane 2018.1 build of the plugin, which I have now removed the download links for, due to these issues.

After a lot of coding to get around these issues, I now believe that option 1 is not possible to implement within the constraints of the Revit API, and I will now try to implement options 2 (ie. materials are matched by material name). If I cannot get option 2 working, I will need to rollout all the changes.

Thanks

Paul

[Seekerfinder]

Thanks for your efforts on this, Paul.

Re my post earlier in this thread, I’d be keen to know how / phasing materials will be handled with linked models. I presume OR will follow the phase filter settings, where materials may be overridden by the ‘phase - exist’ material etc. It may just work out of the box when you impliment method 2 but please bear in mind to test the behaviour of linked models in different phases.

Many thanks,
Seeker

[face_off]

Re my post earlier in this thread, I’d be keen to know how / phasing materials will be handled with linked models. I presume OR will follow the phase filter settings, where materials may be overridden by the ‘phase - exist’ material etc. It may just work out of the box when you impliment method 2 but please bear in mind to test the behaviour of linked models in different phases.

Hi Seeker, I'm sorry, but I don't know the answer to this.

I have just posted an EXPERIMENTAL build in the 2018 release thread using "Option 2", so would appreciate everyone testing it.

Thanks

Paul

[Seekerfinder]

I saw that. Thanks Paul. Will give it a spin!

[SamuelAB]

Some comments on this:

Phases filters should not be followed in a rendering. No one wants to render existing materials in opaque grey...... If you want phase materials, please explain why. Revit renders should be in the phase filter 'Show Complete', with whatever active phase.

Linked file materials. By definition, in Revit, the materials in linked files are independent. If the engineers has his own materials named 'concrete' and the architect has his own material named 'concrete', they should not mix. Therefore option 1 is the one that mimics how Revit works. I understand that it is easier to manager multiple materials with operation 2, but that is not how Revit works.

Some reasons for this: Users are lazy at renaming materials and don't look into the materials on the linked files (other consultants). If you are the engineers, do you really care what material the architect is using? You're not going to open his model and look through the hundreds of materials to see if anything matched your materials. Imagine is the architecture concrete is pink, you don't want to have anything to do with that. It would also brign the other question, which materials wins? Is the concrete pink only when you open the architecture model and grey in the structural model? No, everyone is independent and allowed their materails with the same name, but with different graphics.