|
|
Is there a reason why the calculation of trace intersections and their
normals in megapov may be less accurate than traces on CSG surfaces?
If so, is there a way to improve them: super tight accuracy intervals,
etc.,?
I have been working on a golf game which involves bouncing a bunch of
particles off of an isosurface. For now, it kind of works like taking
200 drives from the tee and seeing if any of them fall into a hole far
away, after bouncing across an isosurface--a golf course. I have spent
weeks pouring over my algorithm, and I am now convinced it is perfect.
The problem is that I am finding that a fraction of the "balls" fall
through the surface. As I said, I am confident that my algorithm is
correct for determining intersections with the surface and the resultant
vector, even if it "bounces" 100 times during a "frame"!
However, some of my particles are still falling through the isosurface.
Consider:
CSG derived flat surface y=136 0 of 200 balls fall through
Isosurface derived flat surface y=136 7 of 200 balls fall through
Noise3d-involved bumpy isosurface 13 of 200 balls fall through
Is there something about the way the trace function interacts with
isosurfaces that I could use to fix this?
If I were simply making art, there would be no complaint. But I'm
considering making a "golf" competition, and thus someone might be upset
if there were a 6.5% chance of my algorithm being too stupid to keep the
ball from going underground! Some balls actualy "come back" after going
through with the bumpy surface!!
I can show people the whole file if you're interested in a
disfunctional program. But here's my macro at least:
#macro Bouncer
(rawvectin,resolvedvectin,posin,vecttestout,vecttrajout,posout,haddabounce)
//rawvectin is the instantaneous velocity, say like 20 mph
//resolvedvectin is the distance the particle will travel in one
frame's timespan, like say 2 inches
//posin is the particle position put into the equation.
//vecttestout is the distance the particle can still travel,
the "output" of resolvedvectin
//vecttrajout is the 'output' instantaneous velocity
//posout is the 'output' particle position
//haddabounce is 0 if no bounce occurred, 1 if it did.
//funk is the separately-called isosurface or
course.
#declare Norm=<0,0,0>;
#declare
crashpoint=trace(funk,posin,0.01*vnormalize(resolvedvectin),Norm);
#if (Norm.x = 0 & Norm.y = 0 & Norm.z = 0)
#declare posout=posin+resolvedvectin;
#declare haddabounce=0;
#declare vecttrajout=rawvectin-0.25*y;
#else
#declare
crashpct=1-vlength(posin-crashpoint)/vlength(resolvedvectin);
// crashpct <0 if no crash during this frame
// 0<crashpct<1 gives the fraction of resolvedvectin
that would be used up before hitting surface.
#if(crashpct<0)
#declare posout=posin+resolvedvectin;
#declare haddabounce=0;
#declare vecttrajout=rawvectin-0.25*y;
#else
#declare haddabounce=1;
#declare posout=crashpoint;//+.01*y;
#declare
vecttrajout=1.0*(rawvectin-2*vdot(rawvectin,Norm)*Norm);
#declare
vecttestout=crashpct*vlength(resolvedvectin)*vnormalize(vecttrajout);
#end
#end
#end
Post a reply to this message
|
|
|
|
Greg M. Johnson <gre### [at] my-dejanewscom> wrote:
: Is there a reason why the calculation of trace intersections and their
: normals in megapov may be less accurate than traces on CSG surfaces?
Yes, there is a reason: Isosurfaces can't be calculated exactly, but
they have to be approximated. Increasing accuracy should lower the errors.
--
main(i,_){for(_?--i,main(i+2,"FhhQHFIJD|FQTITFN]zRFHhhTBFHhhTBFysdB"[i]
):5;i&&_>1;printf("%s",_-70?_&1?"[]":" ":(_=0,"\n")),_/=2);} /*- Warp -*/
Post a reply to this message
|
|