Lumion Error
Jenn Smotherman
So today I came across an error I've never had before. I have downloaded Revit 2020 few weeks back. Designed my model and now I want to export to lumion. When I want to export to create collada file to import to lumion this error dialog box pops up. "Lumion Collada Exporter : Error exporting document, Object reference not set to an instance of an object". This is the first time I'm having such an issue. I've already reinstalled the latest Lumion live sync add on. I tried to reinstall and repair Revit 2020 but nothing seems to work. Please see attached jpg. Hope there is a solution.
I've got the same issue here. Uninstalled and reinstalled the LiveSync Plugin, installed the latest graphics card drivers and all latest windows updates. Nothing seems to fix it. Is there a chance you found a solution?
The error message being displayed represents a very common/generic error. It basically means that something the code thought would exist did not exist. It is impossible to provide any more precise details without more information (which Lumion Collada Exporter does not seem to be providing).
It is possible that the plugin made certain assumptions about the document that were not met (e.g. it assumes there is a family called MyFamily42, tries to do something with that family, shows this error message when the family doesn't exist). Does the documentation for Lumion Collada Exporter specify anything the document must have, and if so does the document have it?
I've finely got some sort of answer, or at least a work around this error.
the problem is in Steelworks in Revit; not exactly sure why but I think its to do with the hidden points.
The work around I found is to redo the steelworks using walls floors or even Inventor.
If Lumion crashes or displays an error while loading or saving a Scene file, it usually means that the Scene file has been corrupted due to a save error. In older versions of Lumion, you may also notice that the .LS Scene file is empty, i.e. that the file size is 0 KB.
2.6: Verify that the Windows User Account type is an Administrator account. If it is a Standard account, please click on the link below and follow the instructions to change it to an Administrator account:
Lumion 9.0: If a save error is detected, you will see a pop-up error message that describes the cause of the save error. You do not need to read the rest of this section. Please continue with section 4 below.
Hi,
I am using Rhino with v-ray and sometimes export files to collada to use the geometry in Lumion. It seems that something changed in an update somewhere, because i have increasingly run into issues where materials are not recognized by Lumion as the correct, but instead it seems they are named individual pr. mesh. The only fix i have found so far is that materials without bump seems to always go through, but material with bump assigned can sometimes go through.
I have recreated the issue on multiple computers with a lot of variations in the material definition, and there does not seem to be an apparent mistake i did recently, so it is general.
This is the DAE I get from v6. Not sure what to expect exactly, but importing it in Blender gives for instance two boxes with the same material Wood_box (or actually named Material-_Wood_box), not with duplicate materials.
I tried with your export, and it acts the same way as in Rhino 5.
The guys at Lumion has made me a Hot-fix which solves the issue for me personally, but the odd influence is still there for others.
Just out of curiosity, if it worked in the Rhino 6, would it not be fixed in Rhino 5, or has that now lost priority? It makes me a bit sad since i bought a Rhino 5 license in september. I tried to upgrade it before i finished my education to have Rhino 6 to play with at home, but never got a response from the danish re-seller.
If it is the Lumion import that gives duplicate materials, then the error is probably with Lumion. Blender imports the materials as expected. The COLLADA file internally looks well formed as well, with only one material for the Wood_box as mentioned earlier:
I have been working on the ampersand issue, and I think I have a fix ready. The fix will actually allow even for accepted non-ASCII characters as well, meaning scandics should work, greek letters, cyrillic etc.
Interesting to see the inner workings of the file. It seems the material id is what sometimes gets mixed up with the name for some reason. And somehow the bump provocates this.
Good with the character-fix. Thought having those kind of letters is just asking for trouble later on.
additional to the known bug that same materials are showing different colors over the rendered image I got the problem that different materials are using the same material id color - for example a metal rail, an emitter display and the window glass - all are green. So, I can't select several objects. A quick fix would be very appreciated. My client like to get the mat id renders and I can't deliver.
I sent an example scene with 5 used materials and all got the same mat ID color. Looks like this isn't caused by the statistical process ... I got an idea now and tested it yet. If I duplicate a material and assign it to a new object, than this object get the same mat id color. Bug found.
(So there there stay to fix the "to much colors for the same material" mat id bug. I suppose so this is caused since Rhino internal create a high count of the materials ... . The Rhino material system is not the best. Maybe there is needed an other way to create the material id colors.)
Is PM the same like conversation? Conversation doesn't work for your profile, it's disabled. I sent the file 26.4. 10:47 per email, but if you guide me, I can try the PM way too, maybe I have overseen the button.
Any news? I'm working for some teams of design offices and larges companies. My client strongly need the material ID and ask me, when I can deliver renderings plus working mat id. Please help. I found no workaround. (I sent two emails with examples where several different materials are shown in the same color.)
Here an example from my current project - all fields with a are one material, same for b. At the green field of c and d should be shown different materials. And there are a lot more objects in this render output, where I get the wrong colors. It's a big problem for my client.
Micha I have taken a look at your files, and although the material is shared between your objects, the Rhino API still reports different materials with different IDs to the Enscape plugin. So it's not trivial from our side, but we try to come up with a solution.
Simon Weinberger Sounds like the McNeel team could help here and fix it at the Rhino side. On the other side render plugins like Octane got it working, maybe an other identification could be used to identify the materials. Good luck.
Regarding the problem "same material has different IDs": I contacted Nathan, and it looks like there might be an easy way for Rhino 6, but not for Rhino 5. It's kind of an API problem. We still have to evaluate on further steps. Splitting the code for Rhino 5 and 6 would be one solution, but would complicate our development and does not work for Rhino 5. Merging the same materials manually would be another solution, but it's error-prone and needs extensive testing in combination with live updates. Unfortunately it's not as easy as it looks.
Simon Weinberger From my side I have no problem to use Rhino 6 for Enscape only. Rhino 5 is outdated and it's nice move, if you release a Rhino 5 version, but if R5 is to limited to get it full working, than it's fine so.
(Maybe it helps not to use Rhino data, simple use the Enscape material names. I suppose so Vray for Rhino is going this way and use the materials on the render engine side to identify which object need the same ID color. Since we don't see different materials, why not show the same ID color?)
Micha For the easy solution for Rhino 6 we have to split our code for Rhino 5 & 6 which isn't a small change. But we're close to finish that project so it should be included in one of our next upcoming versions.
I've rendered the following videos at 3 star quality on lumion, HD. The final walkthrough animations however come out with a lot of grain, or some sort of fuzziness especially for interior shots. What can I do to tackle this? Links to the two videos are pasted below:
Yeah, the trade off is always noise for time. The less noise you want, the more time it will take the render. Some off the issues look like you are using too strong of a sharpening filter, especially on the couch shots in the 2nd animation.
I would recommend to just render at max quality and output a larger image to give better pixel size to render. For instance if your final output is HD then render 1440 or 4K then reduce the size in post to HD. I am not a fan of any sharpening filter in any software really.
As mentioned previously, while importing 3D models into Lumion, the process is very simple and most of the time you don't face any major issues. However, after the first few projects in Lumion, you will definitely learn how to avoid them.
The first issue arises when you import the 3D model that is placed on the scene. The difficulty here is that you don't see the model immediately. Why? One of the reasons is that you didn't create the 3D model close to the origin axis.
When you click to place the 3D model, which will be far from the location where you initially clicked. This may be something you want (we will see this later when you import large scenes) but if not, the solution is to move the objects close to the 0.0.0 point.
c80f0f1006