3D Convex Hull edges

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

Re: 3D Convex Hull edges

Post by AnyOldName3 »

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.
User avatar
raevol
Posts: 3093
Joined: 07 Aug 2011, 01:12
Location: Caldera

Re: 3D Convex Hull edges

Post by raevol »

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: 2666
Joined: 26 Nov 2015, 03:25

Re: 3D Convex Hull edges

Post by AnyOldName3 »

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).
User avatar
Thunderforge
Posts: 503
Joined: 06 Jun 2017, 05:57

Re: 3D Convex Hull edges

Post by Thunderforge »

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: 3093
Joined: 07 Aug 2011, 01:12
Location: Caldera

Re: 3D Convex Hull edges

Post by raevol »

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 »

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 »

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: 2666
Joined: 26 Nov 2015, 03:25

Re: 3D Convex Hull edges

Post by AnyOldName3 »

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.
User avatar
psi29a
Posts: 5355
Joined: 29 Sep 2011, 10:13
Location: Belgium
Gitlab profile: https://gitlab.com/psi29a/
Contact:

Re: 3D Convex Hull edges

Post by psi29a »

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: 2666
Joined: 26 Nov 2015, 03:25

Re: 3D Convex Hull edges

Post by AnyOldName3 »

The issue is there with both floats and doubles as they're both inexact.
Post Reply