[Maximus]

@Csantucci,

in the Version2177 the ads have worked.
In version 2182_2183 still no function.

Maximus

Attached File(s)

•  140_1.cvf.zip (2.02K)
  Number of downloads: 242

[dennisat]

I'm trying to understand something about the new calculation.

If you use Math.Sign(x) then:

if x is positive, it will return 1
if x is negative it will return -1
if x is zero, it will return 0

If you use (int)x then:

if (x >= 0 && x < 1) it will return 0, BUT Math.Sign(x) will return 1.

Have I understood right? (int) does not round, merely truncates at the decimal point?
If so, you will get quite different results from the new calculation. Is that what is wanted?

Hoping I haven't made a fool of myself

Dennis

[Maximus]

From the situation even a video recorded under "RunActivityLAA".

http://youtu.be/LU05dtKvE3Q

Maximus

[James Ross]

dennisat, on 16 April 2014 - 12:52 AM, said:

if (x >= 0 && x < 1) it will return 0, BUT Math.Sign(x) will return 1.

Have I understood right? (int) does not round, merely truncates at the decimal point?
If so, you will get quite different results from the new calculation. Is that what is wanted?

I think you are right... that's why we were using Math.Sign. :)

[gpz]

dennisat, on 16 April 2014 - 12:52 AM, said:

if (x >= 0 && x < 1) it will return 0, BUT Math.Sign(x) will return 1.

It doesn't really matter, because the chance that the result will be in this range is not too much, I think. Anyway, this sorting mechanism physically isn't perfect at all, because it is not pixelwise, but takes only the center point of the render item. A bit more imprecisety doesn't harm... This sorting is optimized for speed, not precisity.

[dennisat]

gpz, on 16 April 2014 - 01:27 AM, said:

It doesn't really matter, because the chance that the result will be in this range is not too much, I think.

The chance may not be high but it's not zero either. There were many examples of this in a test that I ran. Could it affect closely space layers like water, for instance?

Dennis

[James Ross]

dennisat, on 16 April 2014 - 01:43 AM, said:

The chance may not be high but it's not zero either. There were many examples of this in a test that I ran. Could it affect closely space layers like water, for instance?

It could definitely affect water layers - which all sit at the same position apart from a small height difference. It could also be very close to the terrain centre point which would mean water and terrain draw in a random order.

[gpz]

Hmm, indeed, they are close, really...

[dennisat]

dennisat, on 16 April 2014 - 12:52 AM, said:

I'm trying to understand something about the new calculation.

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);

Dennis

[James Ross]

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);

Dennis

That is more technically correct than Math.Sign(yd - xd), although it might be simpler to write like this:

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

So anything that is closer than 1mm (0.001m) is sorted instead by SortIndex. (Trying to compare floats to 0 or each other is always a nightmare.) Could fold that Math.Abs out if we really want to micro-optimise things.