3D Convex Hull edges

Everything about development and the OpenMW source code.
User avatar
AnyOldName3
Posts: 1135
Joined: 26 Nov 2015, 03:25

Re: 3D Convex Hull edges

Post by AnyOldName3 » 16 Aug 2018, 23:42

It seems to work fine in practice, too. Unfortunately, that doesn't seem to have actually fixed the symptom. Apparently, the function which chops planes off the volume wasn't spitting out garbage just because it was being given garbage, but due to its own issue, too. It hasn't filled in the edge loop around the cut here:

Image

This bug is in code lifted from OSG rather than code I've written. It might just be that it occasionally breaks when fed -DBL_MAX, but I don't anticipate that a solution will be too hard to create.
Would it be better to move this conversation to the Content Development Section? Or is it related somehow to OpenMW development?
How on earth could the guts of the shadow code be content development? You're smarter than that, Thunderforge.
AnyOldName3, Master of Shadows

User avatar
raevol
Posts: 2786
Joined: 07 Aug 2011, 01:12
Location: Caldera

Re: 3D Convex Hull edges

Post by raevol » 17 Aug 2018, 00:12

Thunderforge wrote:
16 Aug 2018, 23:37
Would it be better to move this conversation to the Content Development Section? Or is it related somehow to OpenMW development?
Ouch. This is algorithm stuff for getting shadows working.

User avatar
AnyOldName3
Posts: 1135
Joined: 26 Nov 2015, 03:25

Re: 3D Convex Hull edges

Post by AnyOldName3 » 17 Aug 2018, 00:14

The bug goes away when I switch it from -DBL_MAX to -FLT_MAX, so it is just the algorithm not liking overflow. I might be able to make it more robust, or I might find that things work fine in all situations with it left at -FLT_MAX instead (after all, consumer-grade GPUs don't use double precision floating point, so I don't think we can have shadow casters more than FLT_MAX away from the camera without some severe artefacts).
AnyOldName3, Master of Shadows

User avatar
Thunderforge
Posts: 493
Joined: 06 Jun 2017, 05:57
Github profile: https://github.com/Thunderforge

Re: 3D Convex Hull edges

Post by Thunderforge » 17 Aug 2018, 02:15

AnyOldName3 wrote:
16 Aug 2018, 23:42
Would it be better to move this conversation to the Content Development Section? Or is it related somehow to OpenMW development?
How on earth could the guts of the shadow code be content development? You're smarter than that, Thunderforge.
It wasn’t clear to me from the last page of posts that this was for shadows. I haven’t worked in that code, so I didn’t recognize it. Sorry for the confusion.

User avatar
raevol
Posts: 2786
Joined: 07 Aug 2011, 01:12
Location: Caldera

Re: 3D Convex Hull edges

Post by raevol » 17 Aug 2018, 09:28

Thunderforge wrote:
17 Aug 2018, 02:15
I didn’t recognize it. Sorry for the confusion.
To be fair, most people probably aren't rabid fanboys of AnyOldName3's PRs like me... :oops:

PatDaRat
Posts: 8
Joined: 03 Aug 2017, 09:45

Re: 3D Convex Hull edges

Post by PatDaRat » 17 Aug 2018, 12:42

AnyOldName3 wrote:
16 Aug 2018, 20:31
The answer to all of those is no. The prototype version of PatDaRat's idea seems to be working flawlessly, though, so I'm going to get it into C++ and hopefully it'll work.
Nice. I'm glad it worked and I was able to help!

Horrowind
Posts: 6
Joined: 07 Aug 2011, 16:34

Re: 3D Convex Hull edges

Post by Horrowind » 20 Aug 2018, 15:31

All of these posts seem to be forgetting that if a point is on a plane, I can't find this out - depending on how the rounding happens to come out, there's a 50% chance of it being flagged as on one side of the plane and a 50% chance of it being flagged as on the other side, but a 0% chance of it being flagged as on the plane. I had thought about a system using the midpoints of edges, but the midpoints of all edges are on planes, and therefore have a good chance of being flagged as inside the volume.
Of course, you can not expect to test that a point lies on a plane by just plugging the coordinates of the point into the plane equation. I suggest to calculate the distance of the point from the plane and if the distance is smaller than some error/epsilon, then it is on the plane.

User avatar
AnyOldName3
Posts: 1135
Joined: 26 Nov 2015, 03:25

Re: 3D Convex Hull edges

Post by AnyOldName3 » 20 Aug 2018, 23:33

PatDaRat's solution worked, so this discussion is moot anyway, but as I've explained already, the range of values in the data makes anything using epsilons infeasible - an epsilon that is small enough to distinguish between 0.9998 and 0.9999 will be too small to accommodate the error when fed DBL_MAX, but these values all show up within the same convex hull in the same axis.
AnyOldName3, Master of Shadows

User avatar
psi29a
Posts: 4277
Joined: 29 Sep 2011, 10:13
Github profile: https://github.com/psi29a/
Contact:

Re: 3D Convex Hull edges

Post by psi29a » 21 Aug 2018, 07:10

Is this possibly related to the fact that our OSG is compiled with floats while downstream distros use doubles?

https://github.com/OpenMW/osg/commit/55 ... 30e19d0fc4

https://github.com/OpenMW/osg/commit/31 ... a1809bb2c8

User avatar
AnyOldName3
Posts: 1135
Joined: 26 Nov 2015, 03:25

Re: 3D Convex Hull edges

Post by AnyOldName3 » 21 Aug 2018, 11:22

The issue is there with both floats and doubles as they're both inexact.
AnyOldName3, Master of Shadows

Post Reply

Who is online

Users browsing this forum: No registered users and 6 guests