Xmesh MY older builds?


#1

Hi there,

Is it possible to get builds older than 1.4.4 for maya 2017? We get a crash during export in 2017 with the latest build, and i wanted to check it against the build number that works well using maya 2016 (1.3.5.59416) to eliminate that as a potential reason.

cheers
laszlo


#2

Btw, the hang we have is quite sporadic,… this is how the stack looks like:
Capture.PNG

The maya goes into a deadlock, with the main thread being completely idle, waiting.

We initiate the export using cmds.saveXMeshSequence()


#3

I have pinged Paul to look into this (both the hanging, and the older version build question). We also have a support ticket from Bartek about it.


#4

Thanks Bobo! Yeah me and Bartek crossed beams :slight_smile:


#5

Hi Bobo,

It’s Bartek here. Please, let me know if you need any additional information.
Thank you for looking into this issue.


#6

Hi Bartek,

Does it happen with every mesh you tried in Maya 2017, or just with some?
A simple test scene that we could use to reproduce the issue would be very useful.
Given how well protected your environment is, I assume it would be rather tricky for our developers to access your machines for debugging :wink:


#7

It happens with all meshes, but sporadically… i’d say around 40% of the time the export goes through (which seems to indicate some sort of threading / deadlock issue maybe…?)

If you guys have a debug build we could try that as well if that works for you guys?

Ill see if i can produce a simple repro case


#8

Getting a repro case together isolated from our pipeline is a bit problematic, but ill try to get one to you guys. In any case, is it possible to get the older build for maya 2017?
That would help us isolate if the issue is with our changes, or maya 2017, or xmesh. It would also provide a solid baseline (without any other changes that might cause issues).


#9

When running maya in command line, i get this (rather unusable) stack trace for the crash:

2018-03-09 07:50:01: 0: STDOUT: Stack trace:
2018-03-09 07:50:01: 0: STDOUT: MSVCR110.dll!_beginthreadex
2018-03-09 07:50:01: 0: STDOUT: MSVCR110.dll!_endthreadex
2018-03-09 07:50:01: 0: STDOUT: kernel32.dll!BaseThreadInitThunk
2018-03-09 07:50:01: 0: STDOUT: ntdll.dll!RtlUserThreadStart

another:

Stack trace:
MSVCP110.dll!std::codecvt<wchar_t,char,int>::out
MSVCR110.dll!_beginthreadex
MSVCR110.dll!_endthreadex
kernel32.dll!BaseThreadInitThunk
ntdll.dll!RtlUserThreadStart

Sadly, reproducing is very sporadic :-\


#10

Hi Laszlo,

We are unable to offer an older build of XMesh Saver that also supports Maya 2017. The first build to support Maya 2017 was 1.4.3, if you happen to have a backup copy of it somewhere on your servers, you can install it, but we don’t have it anymore and even if we did, we would not be allowed to distribute it.

I tried saving some geometry from a Maya 2017 scene with XMesh 1.4.4 and it did not hang, so I suspect the content of your scene might play a role. I assume you are saving out rigged characters, and the evaluation of the scene graph might be hitting things that a simpler scene like mine does not.

Can you try two things to clarify this?

  • Try saving something trivial like bending boxes to confirm that XMesh works in the more simpler cases. If it does not, then we would have a test case! :slight_smile:
  • Tell us (privately if needed) what the typical content of the scenes is (incl. plugins) so we can try to replicate with the same scene complexity and components as what you are running.

Replicating it on our side would get us closer to finding a solution.


#11

Well right now im having trouble reproducing it on our side… It feels like either a threading or a licensing related issue, based on how sporadic it is. We have periods when all exports hang up, and periods when none of them do. A bit unnerving,…