Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
Bug / Crash  Errors when ending playmode
#1
Ever since upgrading to 5.1 (and redoing all my ropes), I've gotten tons of error whenever I end playmode. 
In the beginning i didn't think much of it, but now that other weird stuff is starting to happen* I wanted to start by fixing these.

*the weird thing: (for some reason newly created ropes only works for a few minutes, then they won't update with the path, and then they completely disappear - no line/mesh/particle renderer works)

Here's the errors:

Getting one of these for each rope:
Code:
NullReferenceException: Object reference not set to an instance of an object
Obi.ObiRope.RebuildConstraintsFromElements () (at Assets/Obi/Scripts/RopeAndRod/Actors/ObiRope.cs:254)
Obi.ObiRopeCursor.ChangeLength (System.Single newLength) (at Assets/Obi/Scripts/RopeAndRod/Actors/ObiRopeCursor.cs:240)
and a set of these for each rope:

Code:
Can't remove ObiRope (Script) because ObiPathSmoother (Script), ObiParticleRenderer (Script), ObiParticleAttachment (Script), ObiParticleAttachment (Script), ObiRopeCursor (Script) depends on it


Can't remove ObiPathSmoother (Script) because ObiRopeLineRenderer (Script) depends on it

[Image: weird-rope.png]
This happens if i move the broken rope into a new solver - the solver says 103 particles are used - change resolution doesn't affect it. Looks like the rope is not subscribed to the solver.
Reply
#2
Also, when shortening one of my ropes, the particles looks to be "paired" with distance contraints? 
[Image: weird-pair.png]
Reply
#3
Just adding to the list of bugs. Sometimes when i build i get these two errors:
Code:
Shader error in 'Obi/Particles': invalid subscript '_ShadowCoord' at line 92 (on gles3)

Compiling Vertex program with DIRECTIONAL SHADOWS_SHADOWMASK LIGHTPROBE_SH STEREO_MULTIVIEW_ON
Platform defines: UNITY_NO_DXT5nm UNITY_NO_RGBM UNITY_FRAMEBUFFER_FETCH_AVAILABLE UNITY_NO_CUBEMAP_ARRAY UNITY_NO_SCREENSPACE_SHADOWS UNITY_PBS_USE_BRDF3 UNITY_NO_FULL_STANDARD_SHADER SHADER_API_MOBILE UNITY_COLORSPACE_GAMMA UNITY_LIGHTMAP_DLDR_ENCODING
Code:
Error building Player: Shader error in 'Obi/Particles': invalid subscript '_ShadowCoord' at line 92 (on gles3)

Compiling Vertex program with DIRECTIONAL SHADOWS_SHADOWMASK LIGHTPROBE_SH STEREO_MULTIVIEW_ON
Platform defines: UNITY_NO_DXT5nm UNITY_NO_RGBM UNITY_FRAMEBUFFER_FETCH_AVAILABLE UNITY_NO_CUBEMAP_ARRAY UNITY_NO_SCREENSPACE_SHADOWS UNITY_PBS_USE_BRDF3 UNITY_NO_FULL_STANDARD_SHADER SHADER_API_MOBILE UNITY_COLORSPACE_GAMMA UNITY_LIGHTMAP_DLDR_ENCODING
Reply
#4
Hi there,

What Unity version are you using? I'm unable to reproduce any of the errors mentioned here.

Regarding the constraint "pairing", it's a normal thing for under-converged simulations when using sequential solving mode. For maximum parallelization, constraints are grouped in batches that do not share particles. In the case of ropes, there are two batches: even and odd constraints. Solving in sequential mode solves all even constraints first, then all odd constraints. The ones solved last get an edge over the rest.

http://obi.virtualmethodstudio.com/tutor...gence.html

Excerpt from the manual:
Code:
In sequential mode, each constraint is evaluated and the resulting adjustments to particle positions immediately applied, before advancing to the next constraint. Because of this, the order in which constraints are iterated has a slight impact on the final result. In parallel mode, all constraints are evaluated in a first pass. Then in a second pass, adjustments for each particle are averaged and applied. Because of this, parallel mode is order-independent, however it approaches the ground-truth solution more slowly.

This pairing effect can be completely eliminated by switching to parallel solving mode, but most of the time (as long as you're using enough substeps) it should not even be a visible artifact in sequential mode.
Reply
#5
(28-01-2020, 12:38 PM)josemendez Wrote: What Unity version are you using? I'm unable to reproduce any of the errors mentioned here.

I'm using 2019.2.17f1.
Reply
#6
(28-01-2020, 12:59 PM)TheMunk Wrote: I'm using 2019.2.17f1.

Just checked the codebase and no included script removes the ObiRope component of an object at runtime. There's no code in Obi 5.1 (afaik) that could lead to these:

Code:
Can't remove ObiRope (Script) because ObiPathSmoother (Script), ObiParticleRenderer (Script), ObiParticleAttachment (Script), ObiParticleAttachment (Script), ObiRopeCursor (Script) depends on it.
Can't remove ObiPathSmoother (Script) because ObiRopeLineRenderer (Script) depends on it

This will happen if a script tries to remove the ObiRope component of an object without removing all other components that depend on it first. Have you written any custom scripts that do this?

This one:

Code:
NullReferenceException: Object reference not set to an instance of an object
Obi.ObiRope.RebuildConstraintsFromElements () (at Assets/Obi/Scripts/RopeAndRod/Actors/ObiRope.cs:254)
Obi.ObiRopeCursor.ChangeLength (System.Single newLength) (at Assets/Obi/Scripts/RopeAndRod/Actors/ObiRopeCursor.cs:240)

Could only happen if the rope didn't have any distance constraints loaded. Which in turn, can only happen if the rope is not part of a solver. Is the rope part of the hierarchy of a solver?
Reply
#7
(28-01-2020, 04:24 PM)josemendez Wrote: Just checked the codebase and no included script removes the ObiRope component of an object at runtime. There's no code in Obi 5.1 (afaik) that could lead to these:

Code:
Can't remove ObiRope (Script) because ObiPathSmoother (Script), ObiParticleRenderer (Script), ObiParticleAttachment (Script), ObiParticleAttachment (Script), ObiRopeCursor (Script) depends on it.
Can't remove ObiPathSmoother (Script) because ObiRopeLineRenderer (Script) depends on it

This will happen if a script tries to remove the ObiRope component of an object without removing all other components that depend on it first. Have you written any custom scripts that do this?
 I have never written any scripts that removes or destroys an Obi Component. The only thing i had (before upgrading to 5.x) was a script to disable a solver - but that's not in use anymore.

(28-01-2020, 04:24 PM)josemendez Wrote: This one:

Code:
NullReferenceException: Object reference not set to an instance of an object
Obi.ObiRope.RebuildConstraintsFromElements () (at Assets/Obi/Scripts/RopeAndRod/Actors/ObiRope.cs:254)
Obi.ObiRopeCursor.ChangeLength (System.Single newLength) (at Assets/Obi/Scripts/RopeAndRod/Actors/ObiRopeCursor.cs:240)

Could only happen if the rope didn't have any distance constraints loaded. Which in turn, can only happen if the rope is not part of a solver. Is the rope part of the hierarchy of a solver?
All ropes and rods are childed under solvers. 
However, I fixed the error (in my update) by checking if the rope and the cursor is enabled;
Code:
if(rope && cursor)
           cursor.ChangeLength(rope.restLength + change);

This tells me that something is disabling the cursor/rope when I stop play mode (before the last update is run), but I can't figure out what it is.
Reply
#8
(28-01-2020, 04:45 PM)TheMunk Wrote:  I have never written any scripts that removes or destroys an Obi Component. The only thing i had (before upgrading to 5.x) was a script to disable a solver - but that's not in use anymore.

All ropes and rods are childed under solvers. 
However, I fixed the error (in my update) by checking if the rope and the cursor is enabled;
Code:
if(rope && cursor)
           cursor.ChangeLength(rope.restLength + change);

This tells me that something is disabling the cursor/rope when I stop play mode (before the last update is run), but I can't figure out what it is.

Are you able to reproduce this in a fresh project, with only Obi 5.1 installed?
Reply
#9
(28-01-2020, 05:00 PM)josemendez Wrote: Are you able to reproduce this in a fresh project, with only Obi 5.1 installed?

I havn't had time to test it yet. But regarding the broken ropes, it seems to happen consistently when I duplicate a rope, duplicate the blueprint, and then apply the new blueprint to the rope. I lose control over the rope like so:
 [Image: rope-broke.png]

If I then revert the blueprint to the original one that the rope was cloned with, it updates to the changed blueprint but is still broken with the particle controls:
[Image: rope-broke-2.png]
Reply
#10
(29-01-2020, 09:56 AM)TheMunk Wrote: I havn't had time to test it yet. But regarding the broken ropes, it seems to happen consistently when I duplicate a rope, duplicate the blueprint, and then apply the new blueprint to the rope. I lose control over the rope like so:

Hi!

Not able to reproduce this either. What I did:
- Duplicate the rope.
- Duplicate the blueprint and assign it to the duplicate rope.
- Edit the duplicate rope (and/or the original one). Both work correctly.

Do you get any console errors while doing this?

Here's a video:
Reply