metalfox

After around 1500 vertices placed on an image, it has a random chance of crashing with this error log:
Note: I'm also using multiple constraints, with the image weighted.
- I checked the Forum and didn't come across this problem, I had a similar problem before the 3.7 update -

Spine Launcher 3.7.81
Esoteric Software LLC (C) 2013-2019
Windows 10 Home x86 10.0
Up to date: Spine 3.7.87
Spine 3.7.87 Professional
Licensed to: ****
NVIDIA Corporation
GeForce GTX 1080/PCIe/SSE2
4.6.0 NVIDIA 416.94
OpenAL 1.1, Default audio device Started.

Sorry, an unexpected error has occurred:
java.lang.RuntimeException: java.lang.OutOfMemoryError: Java heap space
at nt.a(SourceFile:364)
at av.a(SourceFile:75)
at ap.run(SourceFile:271)
at java.desktop/java.awt.event.InvocationEvent.dispatch(Unknown Source)
at java.desktop/java.awt.EventQueue.dispatchEventImpl(Unknown Source)
at java.desktop/java.awt.EventQueue.access$600(Unknown Source)
at java.desktop/java.awt.EventQueue$4.run(Unknown Source)
at java.desktop/java.awt.EventQueue$4.run(Unknown Source)
at java.base/java.security.AccessController.doPrivileged(Native Method)
at java.base/java.security.ProtectionDomain$JavaSecurityAccessImpl.doIntersectionPrivilege(Unknown Source)
at java.desktop/java.awt.EventQueue.dispatchEvent(Unknown Source)
at java.desktop/java.awt.EventDispatchThread.pumpOneEventForFilters(Unknown Source)
at java.desktop/java.awt.EventDispatchThread.pumpEventsForFilter(Unknown Source)
at java.desktop/java.awt.EventDispatchThread.pumpEventsForHierarchy(Unknown Source)
at java.desktop/java.awt.EventDispatchThread.pumpEvents(Unknown Source)
at java.desktop/java.awt.EventDispatchThread.pumpEvents(Unknown Source)
at java.desktop/java.awt.EventDispatchThread.run(Unknown Source)
Caused by: java.lang.OutOfMemoryError: Java heap space
at iv.c(SourceFile:305)
at iv.b(SourceFile:299)
at GT.a(SourceFile:113)
at Go.d(SourceFile:132)
at Gh.d(SourceFile:271)
at Iy.a_(SourceFile:147)
at HV.a_(SourceFile:53)
at Iy.a(SourceFile:99)
at HV.a(SourceFile:78)
at uo.a(SourceFile:60)
at HY.a(SourceFile:128)
at java.base/java.lang.invoke.LambdaForm$DMH/12676424.invokeVirtual(LambdaForm$DMH)
at java.base/java.lang.invoke.LambdaForm$MH/29472806.invoke(LambdaForm$MH)
at java.base/java.lang.invoke.LambdaForm$MH/10697531.linkToTargetMethod(LambdaForm$MH)
at nd.b(SourceFile:331)
at dY.b(SourceFile:209)
at ne.b(SourceFile:363)
at dY.b(SourceFile:183)
at q.b(SourceFile:124)
at q.b(SourceFile:124)
at aD.a(SourceFile:344)
at ap.run(SourceFile:259)
at java.desktop/java.awt.event.InvocationEvent.dispatch(Unknown Source)
at java.desktop/java.awt.EventQueue.dispatchEventImpl(Unknown Source)
at java.desktop/java.awt.EventQueue.access$600(Unknown Source)
at java.desktop/java.awt.EventQueue$4.run(Unknown Source)
at java.desktop/java.awt.EventQueue$4.run(Unknown Source)
at java.base/java.security.AccessController.doPrivileged(Native Method)
at java.base/java.security.ProtectionDomain$JavaSecurityAccessImpl.doIntersectionPrivilege(Unknown Source)
at java.desktop/java.awt.EventQueue.dispatchEvent(Unknown Source)
at java.desktop/java.awt.EventDispatchThread.pumpOneEventForFilters(Unknown Source)
at java.desktop/java.awt.EventDispatchThread.pumpEventsForFilter(Unknown Source)
Аватара пользователя
metalfox
  • Сообщения: 6

Erikari

Hello metalfox, seeing your crash log and the other post in the off topic section, it looks like you're using too many vertices (and I assume, direct deformations) and your computer can't take it.
I'd suggest you take a look at your metrics, especially:
Meshes - Spine User Guide: Vertex count
Metrics - Spine User Guide: Vertex transforms

Here's another thread discussing why it is important to keep these numbers down:
Editor frame rate performance issues
Аватара пользователя
Erikari

Erikari
  • Сообщения: 2009

badlogic

Hey metalfox, sorry for the trouble. Could you please send us your project, so we can further investigate why Spine is running out of memory? Please send it to contact@esotericsoftware.com with a link to this forum thread.
Аватара пользователя
badlogic

Mario
  • Сообщения: 2108

metalfox

[ Erikari ] If you read my computer specs, it shouldn't be my computer; unless the programs info distribution is racking unnecessary data

[ badlogic ] As trustworthy as you & Esoteric may be, I'm not sending copies of my hard-work when I intend on making money on it in the future. But here is an extended amount of data for you to analyze:

I've Lowered the rim bone size from 10 to 20 to cut out more bones; so like the description said, it was crashing when above 1,500, but not now.
It could be the image, since I'm stretching ( let's say ) a 64x64 box out to 1080x1080 with several vertices.
|Skeletons|
Bones: 157
BTransforms: 157
Constraints: 4
Slots: 14

|Attachments|
Total: 15
Visible: 1/4
Vertices: 973 / 1,080
VertexTransforms: 1,843 / 2,106
Triangles: 1,841 / 1,843
Area (sq px): 543 / 863
ClippingPoly: 0
ClippingTri: 0

|Animation|
TimeL: 0
Keys: 0
DeformV: 0

---

[ Erikari ] In case you intend on continuing to blame my systems; I have no problem having several more vertices on other 3D Autodesk software, such as Maya, Blender and Rhinoceros 3D.
Next argument: They're not all built for animating, Maya & Blender is. ( Not saying your 'miss-informed', a lot of people like to tell me I'm wrong; and I hate these conversations. Since we both gain nothing from it. )

---

Even an auto-save with tool-exit, and manual-saves being written as backup saves, would make use as a bypass to crashing L-L
I've even had one rare case where my old computer was crashing during Spine save, which corrupted the data, and I lost everything. A convenient backup would have fixed this instance.

---

Note: The image type is PNG
Аватара пользователя
metalfox
  • Сообщения: 6

Erikari

Hello metalfox, I was not blaming your specs, but usually when people get the java.lang.OutOfMemoryError: Java heap space the culprit often is a wild usage of vertices, or bones per vertex. It might not be your case of course, but it doesn't hurt to check this first.

From the link I posted above Nate said:
Yeah, I'm a bit scared people go crazy with mesh deforms. Every deform key has to start all mesh verts. Also, each vertex (a float) is stored for every bone that affects a vertex. So a mesh with 100 verts where each vert is affected by 3 bones is 300 verts, then someone goes and keys that mesh a dozen times in 20 animations = 12 * 20 * 300 = 72,000 verts stored! This affects data file size and memory consumption, but at least CPU isn't affected.
It doesn't look like you're using mesh deforms which is great, so this one is out.

Then again Nate said:
Probably you don't have vertices which are influenced by ALL those bones. It's per vertex. If a vertex is influenced by 4 bones, then 4 floats are stored for that vertex in the setup pose, current pose, and every key. Also, for every bone that influences a vertex, a vertex transform is calculated. You can see the number of vertex transforms in the Metrics view. Using Purge in the Weights view can remove the bone influence that is very small, which can make a big difference. See the docs for details:
Meshes - Spine User Guide: Vertex count
Metrics - Spine User Guide: Vertex transforms
(same docs I posted above earlier just in case)

So maybe the problem could be that you have over 3-4 bones per vertex, and this is generating a lot of calculations for Spine.
To help with this, you could use the Prune function: Weights - Spine User Guide: Prune which recently got updated so that you can choose the maximum number of bones affecting a vertex.

If this doesn't help, as Badlogic said, it would be great to see the project, you can send us the project with the textures all black.
Spine shouldn't crash even in these cases, so having a repro file would really help us out. If you still can't, don't want, we can just hope it was one of the problems above, or hope it doesn't occur again, but we won't be able to guarantee your problem is fixed of course.

Regarding backups, Spine automatically saves them in the backup folder: Settings - Spine User Guide: General
You should be able to find this folder by going to the Files section, then clicking on the folder icon of the Backup row:


I hope this will help!
Аватара пользователя
Erikari

Erikari
  • Сообщения: 2009

metalfox

Thank you so much! Actually, then it is Mesh Deforms; like I said, "It could be the image, since I'm stretching ( let's say ) a 64x64 box out to 1080x1080 with several vertices." That would explain the data dump;

I'm sure you guys aren't the programmers but Quote,"If a vertex is influenced by 4 bones, then 4 floats are stored for that vertex in the setup pose, current pose, and every key."
Instead of using an array-float for each bone/vertex, why don't he just have the necessary base floats, to form a grid of information. So when he uniforms out the information, its just calculated with these floats. You can do this by having a hexadecimal code to distribute the number sequence, and if the sequence is to long for the Shader to calculate, add an additional float then. A lot of programs use something similar to this when calculating colors for Shaders ^-^

That's badass, I thought I learned everything about your program, but I guess I missed a bit of it, lol. I'll make sure to utilize backups for now on
Аватара пользователя
metalfox
  • Сообщения: 6

badlogic

The vertext layout in a shader is fixed. What you described amounts to run length encoding, something you can't do with vertex data. But we aren't talking about GPU sice issues here. What you are running into is a CPU side issue.

Your data above gives us some idea about your project setup, but ultimately, we'll need a project that reliably crashes for you to identify the underlying issue. We'd be grateful if you could either send us a blacked out version of your real project, or a new, non-secret project that simulates the traits of your real project.
Аватара пользователя
badlogic

Mario
  • Сообщения: 2108

metalfox

My god, forward this post to one of your main programmers; for the sake of your companies benefit, if s/he doesn't get it, then your shit out luck. I appreciate you guys replying at all; I have nothing more to say on this.

Specifically:
" I'm sure you guys aren't the programmers but Quote,"If a vertex is influenced by 4 bones, then 4 floats are stored for that vertex in the setup pose, current pose, and every key."
Instead of using an array-float for each bone/vertex, why don't he just have the necessary base floats, to form a grid of information. So when he uniforms out the information, its just calculated with these floats. You can do this by having a hexadecimal code to distribute the number sequence, and if the sequence is to long for the Shader to calculate, add an additional float then. A lot of programs use something similar to this when calculating colors for Shaders ^-^ "

I'm describing methods of utilizing GPU to do the CPUs job,
I obviously haven't read your code; but from my experience, if there's a leak, the programmer should have the knowledge to already know of its origin; they're just limited on methods to properly distribute the information. (Given, s/he followed the entire script, instead of just managing a portion)

Sorry for being snippy; I was deciding on not sending anything, but you guys made such a good program, I want to support you, regardless of my patience.

I already said I'm not sending anything, I was not trying to explain the issue in that portion. This is all I said toward the issue:
" Actually, then it is Mesh Deforms; like I said, "It could be the image, since I'm stretching ( let's say ) a 64x64 box out to 1080x1080 with several vertices." That would explain the data dump "
Аватара пользователя
metalfox
  • Сообщения: 6

badlogic

I'm in fact one of the programmers on Spine. I believe I have a pretty good handle on how our code works, and how GPU and CPU side skinning and data representations work. I understand that text communication can be frustrating if there are misunderstandings, but please keep it civil.

I understand entirely what you are trying to say, even though phrases like "hexadecimal code", "uniforms out the information", or "form a grid of information" aren't quite what a programmer would use for what you are describing.

What you are referring to as "hexadecimal code" is a packing of bone indices, say a byte per index, with a maximum of 4 indices encodable in 32-bit. For good measure, you can also throw in lower precision weights and even UVs, say fp16, to pack more data into the same amount of space, though that may actually lead to quite a noticeable degradation in the precision of the skinning and texture sampling itself. All of that has nothing to do with "hexadecimal code" though...

The phrase "uniforms out the information" is also nothing a programmer would say. I assume you are talking about matrix palettes stored in uniform buffers, which is an encoding used by most GPU side skinning shaders to share bone transforms across vertices. The bone indices in the vertex point into that palette.

"add an additional float then" is not possible GPU side. These floats are stored as part of a vertex. The vertex layout is fixed. You can not do run-length encoding in a vertex layout, unless you make every vertex as big as the worst run-length encoding requires. In which case you actually waste more memory than needed.

All of the above comes with tradeoffs that you might be able to live with at runtime in your game/app:

  • Number of bones that can influence a single vertex, limited to 4 in a 32-bit packed encoding.
  • Number of total bones limited by uniform space, but more importantly, the 32-bit packing, with one index being represented by a byte, limiting the total number of bones in a single pass to 256.
  • Precision of weights may result in huge deviations in skinning outcome compared to the high precision mode you see in the editor.
  • Precision of UVs may result in texture sampling artifacts compared to the high precision mode you see in the editor.

Again, you can do all of that at runtime, in your game, if you can live with the restrictions and plan your assets accordingly.

But for the Spine Editor, we can not make do with these restrictions. The core data structures in the editor must allow for maximum precision, bone numbers, and other factors that do not turn up in a runtime setting. There are also a bunch of algorithms applied to meshes that have a minimum space complexity of O(n^2) (yes, there are no lower complexity solutions for some of these). Whether things are stored/computed GPU or CPU side is entirely irrelevant for the issue at hand.

We won't be able to fix your issue without a reproduction case. We currently lack such a repro. You said you won't send us anything. Please ask your programmers how they feel about fixing an issue without being able to reproduce it.
Аватара пользователя
badlogic

Mario
  • Сообщения: 2108


Вернуться в Bugs