Lost association Tweet

[face_off]

I was trying to define the common steps the few times this occurred but as I said the only common denominator seems to be opening a new Revit file (project or family) while the plugin is open and rendering, resulting in the render window closing. As also mentioned though, other times I re-opened the plugin after the same activity it was still fine... I get the idea that it can handle a certain amount of these events but then gets 'confused' (what do you say, am I a software development candidate of what!?). Sorry that I can't offer any more insight than that. Hopefully the 2 Revit model files will help - sent them by PM about an hour ago.

Thanks Seeker. I've just done about 3hrs of tests with various combinations of saving, loading, new file, etc whilst the Viewport is open, and cannot get the problem to occur. If you can find a way to reproduce the issue, that would help greatly.

Paul

[face_off]

For anyone having this issue - pls try the following version of the plugin. It contains debug code to write to the Revit Journal when loading of saving Octane data. Then if you have the issue occur, pls send me the journal file from C:\Users\[user]\AppData\Local\Autodesk\Revit\Autodesk Revit Architecture 2014\Journals.

http://render.otoy.com/customerdownloads/plugins/OctaneRender_for_Revit_2014_2_6_0_9_Win64.exe

Paul

[Seekerfinder]

I was trying to define the common steps the few times this occurred but as I said the only common denominator seems to be opening a new Revit file (project or family) while the plugin is open and rendering, resulting in the render window closing. As also mentioned though, other times I re-opened the plugin after the same activity it was still fine... I get the idea that it can handle a certain amount of these events but then gets 'confused' (what do you say, am I a software development candidate of what!?). Sorry that I can't offer any more insight than that. Hopefully the 2 Revit model files will help - sent them by PM about an hour ago.

Thanks Seeker. I've just done about 3hrs of tests with various combinations of saving, loading, new file, etc whilst the Viewport is open, and cannot get the problem to occur. If you can find a way to reproduce the issue, that would help greatly.

Paul

Thanks for trying Paul. However, I would have thought you might pick up a difference between the two Revit project / plugin texture-file structures - no? I'll try and see what is the common behaviour.

Best,
Seeker

[Seekerfinder]

For anyone having this issue - pls try the following version of the plugin. It contains debug code to write to the Revit Journal when loading of saving Octane data. Then if you have the issue occur, pls send me the journal file from C:\Users\[user]\AppData\Local\Autodesk\Revit\Autodesk Revit Architecture 2014\Journals.

http://render.otoy.com/customerdownloads/plugins/OctaneRender_for_Revit_2014_2_6_0_9_Win64.exe

Paul

Ok.

Incidentally, I have been getting a few 'the Nvidia driver has stopped working and has recovered' warnings lately with this driver (340.52) (not coinciding with the above issue as far as I am aware though). I would often have PS open together with Revit, SketchUP and Octane and a bunch if images to boot. But I don't recall getting this warning with the previous Nvidia driver. I have not seen any warnings on the forum regarding this driver but please let us know if there is something.

Best,
Seeker

[Seekerfinder]

Grrr.... just happened again. The good news is that the plugin at least remembered my nice grass material. The bad news is that I did not update my stone material I had spent so much time getting right.

I will send you the journal file by PM shorty. It is around 4MB.

FYI, installing and rendering with your custom version worked fine at first. I opened 2 families unintentionally while trying to move them (I have since disabled double-click to edit family), causing a close-down but on both occasions the plugin behaved as expected when I re-opened it and everything was fine. Other than that I was just working away at the model doing nothing unusual that I can think of. This model involves detailed custom wall profiles and creation of sweeps. Could it be sweeps? I'll try and test more. So the workflow involves closing the plugin after it rendered fine. Doing some more modelling work in Revit, saving intermittently. Open plugin again and (sometimes) boom! - the issue. I can't recall if any of these occurrences happened after closing Revit but I think at least one of them happened in the same session.

Observation:
While the earlier journal files are bigger (9-13MB), the one just before the lost material issue is 26MB. Not sure if it means anything but it does seem a bit odd.

Best,
Seeker

[Seekerfinder]

Paul,

I will send you the journal file by PM shorty. It is around 4MB.

Actually, by the time I sent it to you, the file had gone up to about 5.5MB... Could it be that there is an issue when this file gets too big?? Like the 26MB one I mentioned? I.e. we need to save incrementally more often?

EDIT:
Ok, here might be a clue. I went back to the last version that worked to see if I could salvage my stone material by saving it as a favourite. And to my relief, it worked and I could re-apply it in the later 'materials-corrupted' file. But here's the kicker... I did this a few times, closing the previous file every time (the current / latest version of my RVT, which lost the materials, was open all the while) and then going back for another material I needed to go save as fav. But when I tried to do so a 3rd or 4th time, that model ALSO had suddenly lost its materials (gasp). I then noticed in Revit's file-open dropdown list that there was now a Revit back-up of that version (Filename.0001.rvt). I opened it to see if the materials were still there - lo and behold they were! Does that shed any light on this issue?

Best,
Seeker

[face_off]

For other's having this issue - Seeker and I are working through trying to identify the cause via PM. I will post here once there is any news.

Paul

[andredms]

Usually, if the plugin closes due to the opening of a family or other project (it always closes), just reopen the plugin gives the project untouched (textures and proxies) - but if I save the project file with the plugin closed, this is when all the pertinent information is lost.

[face_off]

Usually, if the plugin closes due to the opening of a family or other project (it always closes), just reopen the plugin gives the project untouched (textures and proxies) - but if I save the project file with the plugin closed, this is when all the pertinent information is lost.

This makes sense, however I have tried many many many times to reproduce the problem by 1) opening the viewport 2) opening a family (which closes the plug), 3) closing the family or selecting the original scene, 4) saving (without opening the plugin). And I cannot reproduce the problem this way. Revit should never delete stored plugin data unless a plugin specifically requests it (and the Octane plugin never requests stored data deletion). So it should not be possible for Octane data to go missing.

If you re-download and install the 2.6.0.9 version above, I have updated it to include more debug info - so if you run this version and encounter the problem, send me the journal file and it will give me more clues as to the cause of the issue.

Thanks

Paul

[face_off]

An update on the above.

I have isolated the problem to when Revit saves to the temp file (ie. MyRevitFile.0001.rvt). According to the Revit doco, the 0001.rvt file is simply a snapshot (copy) of the current version of the file, however within the Revit API it is actually renaming the current document to append the 0001, 0002, etc to the document name, so the plugin thinks a different file is being saved, and the Octane info is not saved.

Because I cannot get the problem to occur, I cannot provide an immediate fix, however if you re-download 2.6.0.9 above, it now writes even more debug info in the journal file. Once I receive journal file from the above release where the Octane node info has been cleared, I should then be able to code a work-around to resolve the problem.

Thanks

Paul