Exporting failed with unknown error

[kubbek]

Working bigger scenes that are quite unresponsive in modo I get often an error when I try to render. It says Exporting failed with unknown error. I have to not only to restart modo but also windows needs to be restarted.
I have to render newly opened scene because first few tweaks can make it impossible to render. It is a complicated scene with referenced geometry and V-Ray proxies.

[vladimir.nedev]

Can you take a look at the "Event Log" after the "Exporting failed with unknown error" message shows up.
It might have more information what went wrong.

Greetings,
Vladimir Nedev

[kubbek]

Unfortunately nothing interesting in the event log. There were some warnings about unsupported textures but it renders with them sometime and when I disabled them the problem remain.
generaly this problem appears only in bigger scenes.

[vladimir.nedev]

This message actually shows up when something (either V-Ray for MODO or MODO itself) generated an exception (i.e. crashed) during the export.
Is there any chance you could send me the scene ?

Greetings,
Vladimir Nedev

[kubbek]

I will try to pack it and send you via dropbox as it is quite big.

[kubbek]

After consolidating my scene I could not replicate this issue. I will write back if it happens again.

[vladimir.nedev]

After consolidating my scene I could not replicate this issue. I will write back if it happens again.

Did you have referenced scenes in your scene ? These seemed to work fine in MODO 701 without me doing anything special.
In MODO 801 they seem to behave rather sporadically. Sometimes the referenced geometry gets exported in V-Ray, sometimes it doesn't.
I haven't looked into it more to determine what the cause might be.

Greetings,
Vladimir Nedev

[kubbek]

Yes I have referenced geometry (different parts of the building) but they are rendering properly without problems. I had some issues with references in earlier versions of modo 801 but in sp3 it worked without problems (if I succeed to execute render).
The consolidated scene does also use the references though.

[vladimir.nedev]

Yes I have referenced geometry (different parts of the building) but they are rendering properly without problems. I had some issues with references in earlier versions of modo 801 but in sp3 it worked without problems (if I succeed to execute render).
The consolidated scene does also use the references though.

Hm, so maybe it is not the references then. I am doing some testing now, and it seems only referenced meshes with subdivision polygons (or text, or spline patches) in them won't get properly exported.
These are using a different MODO API interface, compared to normal (or static) meshes, so that might be the reason.

Greetings,
Vladimir Nedev

[kubbek]

I checked and there was one sub-d mesh in one of reference files. After removing it from the reference the problem remains - exporting failed with unknown error.
There are no text or spline patches in the scene.

[vladimir.nedev]

I checked and there was one sub-d mesh in one of reference files. After removing it from the reference the problem remains - exporting failed with unknown error.
There are no text or spline patches in the scene.

Yes, in my tests the sub-d meshes don't cause this problem either. They just don't render.

Maybe send me the scene without consolidating it first ? It won't have the image maps at my end, but the problem might still be reproducible.

Greetings,
Vladimir Nedev

[kubbek]

Yes, in my tests the sub-d meshes don't cause this problem either. They just don't render.

Maybe send me the scene without consolidating it first ? It won't have the image maps at my end, but the problem might still be reproducible.

Greetings,
Vladimir Nedev

I send you private message with a link to the scene.

[vladimir.nedev]

The scene directly crashes for me. The referenced scenes seem to be the cause of the crash (usually Block 2_Envelope.lxo or Block 3_Envelope.lxo).
When referenced some of the items in these scenes don't have a valid internal identifier, which is something I didn't expect was possible, so my export code crashes on it.
Just rendering the referenced scenes on their own works, which makes me think this is somehow caused by a bug in MODO's referencing system.
Also sometimes the internal identifiers are ok, it seems random, and is determined when the scene is loaded.

Without these internal identifiers, it might not be possible to identify the items during RT. Also they are used to uniquely name the V-Ray plug-ins.
I am considering aborting the export process when meshes or other items without IDs are encountered.
An error dialog will pop-up telling you of this error. You can then try closing/reopening the scene, maybe even restarting MODO and then try rendering again.
Also you can try reloading just the referenced scene from where the item came, which might be faster.
You can do this by right clicking on the referenced scene's group, and then References -> "Reload imported references".
This doesn't seem to work always though. Also depnding on how the loading went, it might be only one referenced scene that is corrupted,
but it might be all of them, so you might need to do this a lot of times.

Another possible solution, I can try implementing, is to use the "unique name" for items in the scene, which seems to be always set correctly, but this
will require some big changes to the code, it might create other problems and I may not be able to make it work in V-Ray RT.

In any case, you should probably send the scene to The Foundry so they can identify the source of the issue.

By the way, the scene exports to V-Ray very slowly, because of the huge amount of polygon part tags that are present.
I need to eventually optimize my export code for this case, but even then removing these polygon part tags will speed-up other parts of MODO's UI unrelated to V-Ray.
You can just go through each of the scenes and do the following :
1. Go in item selection mode
2. Select -> Item Types -> Meshes
3. Go in polygon selection mode
4. Geometry -> Polygon -> Set Part... and enter "default"
5. You can now go to the "Info & Statistics" viewport and check that there is only one part tag under "Polygons" -> "Part tags"
Of course you should first make sure that you are not using any Part tags for masks in the shader tree.

This will reduce the "Translating scene to V-Ray" part of the export from around 1 minute 16 seconds down to 8-9 seconds.

Can you tell me how you imported this geometry initially ? From what format / application ?
Maybe there are import options to disallow the creation of the part tags.

Greetings,
Vladimir Nedev

[kubbek]

The scene directly crashes for me. The referenced scenes seem to be the cause of the crash (usually Block 2_Envelope.lxo or Block 3_Envelope.lxo).
When referenced some of the items in these scenes don't have a valid internal identifier, which is something I didn't expect was possible, so my export code crashes on it.
Just rendering the referenced scenes on their own works, which makes me think this is somehow caused by a bug in MODO's referencing system.
Also sometimes the internal identifiers are ok, it seems random, and is determined when the scene is loaded.

Without these internal identifiers, it might not be possible to identify the items during RT. Also they are used to uniquely name the V-Ray plug-ins.
I am considering aborting the export process when meshes or other items without IDs are encountered.
An error dialog will pop-up telling you of this error. You can then try closing/reopening the scene, maybe even restarting MODO and then try rendering again.
Also you can try reloading just the referenced scene from where the item came, which might be faster.
You can do this by right clicking on the referenced scene's group, and then References -> "Reload imported references".
This doesn't seem to work always though. Also depnding on how the loading went, it might be only one referenced scene that is corrupted,
but it might be all of them, so you might need to do this a lot of times.

Another possible solution, I can try implementing, is to use the "unique name" for items in the scene, which seems to be always set correctly, but this
will require some big changes to the code, it might create other problems and I may not be able to make it work in V-Ray RT.

In any case, you should probably send the scene to The Foundry so they can identify the source of the issue.

I will try to make a bug report - never tried it before.

By the way, the scene exports to V-Ray very slowly, because of the huge amount of polygon part tags that are present.
I need to eventually optimize my export code for this case, but even then removing these polygon part tags will speed-up other parts of MODO's UI unrelated to V-Ray.
You can just go through each of the scenes and do the following :
1. Go in item selection mode
2. Select -> Item Types -> Meshes
3. Go in polygon selection mode
4. Geometry -> Polygon -> Set Part... and enter "default"
5. You can now go to the "Info & Statistics" viewport and check that there is only one part tag under "Polygons" -> "Part tags"
Of course you should first make sure that you are not using any Part tags for masks in the shader tree.

This will reduce the "Translating scene to V-Ray" part of the export from around 1 minute 16 seconds down to 8-9 seconds.

Can you tell me how you imported this geometry initially ? From what format / application ?
Maybe there are import options to disallow the creation of the part tags.

Greetings,
Vladimir Nedev

That interesting - I thought it works so slowly because of the shader tree and item list complexity. Didn't expect I could do anything with it. Most of the geometry comes from Rhino through Power Translators.

[vladimir.nedev]

Can you tell me how to contact The Foundry in this case? Never done it and don't really see a place in the forum where to place such information. I would surely send the scene as referencing is quite important in my case.

I haven't done this myself, maybe write an e-mail to support@thefoundry.co.uk and when they answer, send them the scene. Or maybe ask on The Foundry forum.

That interesting - I thought it works so slowly because of the shader tree and item list complexity. Didn't expect I could do anything with it. Most of the geometry comes from Rhino through Power Translators.

The "Translating MODO scene to V-Ray" part depends on the item list complexity, the amount of unique material/part/selection tag combinations and the shader tree complexity.
What happens now is :
for each geometry item (including normal instances, but not including replicator instances)
---- for each unique material/part/selection tag combination in that item
--------- traverse the shader tree
The complexity of each of these get multiplied together.
I can optimize this by discarding geometry items and material/part/selection tags that are not used in the shader tree.

I don't have access to the "Power Translators" plug-in for MODO, but maybe there is an option somewhere to tell it not to import part tags.
Also I see there is an option to import the geometry as Static meshes. Static meshes can't have their material/part/selection tags changed
(so the 'm' key won't work on them, but you can still use items masks for them in the Shader tree), but they can be exported very fast to V-Ray.
I've tried it on your scene and manually converting all meshes to static meshes changed the "Exporting keyframe..." time from ~24 seconds down to ~0.5 seconds. Translation time is also reduced.
It also reduced the scene size on disc from 748 MBs down to 319MBs. When loaded into MODO the static mesh scene takes ~3GBs from system RAM,
with editable meshes it is ~10GBs. Also loading the scene into MODO takes ~30 seconds with static meshes, and 2m20s with normal meshes.

The static meshes have one huge disadvantage though - they render extremely slow in MODO's Open GL viewport.
My guess is they didn't get updated to use VBOs. This can probably be reported to The Foundry as a performance bug.

Also your scene has an insane (205) number of lights , so it may be a good test for the probabilistic lights option.
I tried rendering a region of the scene with no GI, with 8 probabilistic lights, it rendered for 4m.33s., without probabilistic
lights it rendered for 17m18s. I used our own ray acceleration structure instead of Intel's Embree, in order to preserve
some memory, with Embree the render time difference might be smaller.

Greetings,
Vladimir Nedev