[dennisat]

 dennisat, on 16 April 2014 - 04:40 AM, said:

Does this fit the bill? It renders everything I've tried correctly but I've no access to the original problem:

                //var xd = (x.XNAMatrix.Translation - XNAViewerPos).Length() - x.RenderPrimitive.SortIndex;
                //var yd = (y.XNAMatrix.Translation - XNAViewerPos).Length() - y.RenderPrimitive.SortIndex;
                var xd = (x.XNAMatrix.Translation - XNAViewerPos).Length();
                var yd = (y.XNAMatrix.Translation - XNAViewerPos).Length();
                if (yd > xd)
                    return 1;
                else
                    if (xd > yd)
                        return -1;
                    else
                        if (y.RenderPrimitive.SortIndex > x.RenderPrimitive.SortIndex)
                            return -1;
                        else
                            if (x.RenderPrimitive.SortIndex > y.RenderPrimitive.SortIndex)
                                return 1;
                            else
                                return 0;
                //return Math.Sign(yd - xd);

The main reason I was attracted to the above is that it's fairly proof against bad format float values. They will just drop through the greater and less than checks so there should be no crashes at this point. Even hugely different valid float values can only be greater than, less than, or neither (exactly the same hopefully). Now what will happen to the Render task subsequently if any of these values are bad I've got no idea! Moves the crash on a bit, I suppose.

My recent attempts at debugging have all either started with, or ended up with finding bad float values so I'm now a bit suspicious of them. Does C# have a debugging mode that will validate numeric fields as the program runs? Very resource consuming, of course, but if you've got a problem that's hard to spot this can be a very useful tool.

Dennis

[James Ross]

 dennisat, on 16 April 2014 - 06:29 AM, said:

The main reason I was attracted to the above is that it's fairly proof against bad format float values. They will just drop through the greater and less than checks so there should be no crashes at this point. Even hugely different valid float values can only be greater than, less than, or neither (exactly the same hopefully). Now what will happen to the Render task subsequently if any of these values are bad I've got no idea! Moves the crash on a bit, I suppose.

My recent attempts at debugging have all either started with, or ended up with finding bad float values so I'm now a bit suspicious of them. Does C# have a debugging mode that will validate numeric fields as the program runs? Very resource consuming, of course, but if you've got a problem that's hard to spot this can be a very useful tool.

I'm not convinced we want to let bad values through, since they always indicate a bug elsewhere. I don't think C# has a mode which checks for and aborts on NaN results, though it would indeed be useful for figuring out where they came from. :)

[Csantucci]

dennisat's patch avoids the crashes that triggered this thread.
James' last proposed patch had to modified as follows (not in an optimized way I think )because the return value must be an integer

               var xd = (x.XNAMatrix.Translation - XNAViewerPos).Length();
                var yd = (y.XNAMatrix.Translation - XNAViewerPos).Length();
                if (Math.Abs(yd - xd) >= 0.001)
                    return Math.Sign (yd - xd);
                return Math.Sign (x.RenderPrimitive.SortIndex - y.RenderPrimitive.SortIndex);

and avoids the crashes too.

However I wonder what is against the patch I proposed

             return Math.Sign((y.XNAMatrix.Translation - XNAViewerPos).Length() - (x.XNAMatrix.Translation - XNAViewerPos).Length() - y.RenderPrimitive.SortIndex + x.RenderPrimitive.SortIndex);

I conceptually like dennisat's and James' solutions, but are there specific test cases where the patch I proposed provides worse results?

[dennisat]

 Csantucci, on 16 April 2014 - 09:27 AM, said:

             return Math.Sign((y.XNAMatrix.Translation - XNAViewerPos).Length() - (x.XNAMatrix.Translation - XNAViewerPos).Length() - y.RenderPrimitive.SortIndex + x.RenderPrimitive.SortIndex);

I conceptually like dennisat's and James' solutions, but are there specific test cases where the patch I proposed provides worse results?

I haven't pinpointed any particular cases but the original code, and your suggested patch which uses the same logic, could possibly result in some primitives being rendered in the wrong order. Suppose the difference in the vector lengths is very small, it is conceivable that the difference in the SortIndexes could be bigger and thus reverse the order in which they should be rendered.

Dennis

[James Ross]

 Csantucci, on 16 April 2014 - 09:27 AM, said:

               var xd = (x.XNAMatrix.Translation - XNAViewerPos).Length();
                var yd = (y.XNAMatrix.Translation - XNAViewerPos).Length();
                if (Math.Abs(yd - xd) >= 0.001)
                    return Math.Sign (yd - xd);
                return Math.Sign (x.RenderPrimitive.SortIndex - y.RenderPrimitive.SortIndex);

Committed in X2188.