I changed the code, and it works great now. Except…. I'm still relying on a static_cast, so it's not really a solution.
float normalized_double_to_float(const double d)
{
if (d <= 0.0)
return 0.0f;
else if (d >= 1.0)
return 1.0f;
const float df = static_cast<float>(d);
float tempf = nexttowardf(1.0f, df);
while (tempf > df)
tempf = nexttowardf(tempf, df);
return tempf;
}BVH for ray tracing?
There was only one fool-proof way without casting:
float normalized_double_to_float(const double d)
{
if (d <= 0.0)
return 0.0f;
else if (d >= 1.0)
return 1.0f;
ostringstream oss;
oss << setprecision(20) << d;
float df = 0;
istringstream iss(oss.str());
iss >> df;
float tempf = nexttowardf(1.0f, df);
while (tempf > df)
tempf = nexttowardf(tempf, df);
return tempf;
}It's not the fastest, but it kind of works.
Hehe, looks a bit like throwing dice. Einstein would not like this.
On the other hand, maybe reducing precision is needed to emulate quantized nature? :D
Turned out my bug is accidentally not updating the root node on changes. And because the root node is just one, i have overlooked the report of the data difference. How stupid. It's used for GI, yes. After i have that woking, i can finally start working on rendering….
Glad to hear that you found your bug!
Yes the plan of attack is to reduce the precision, to emulate the conversion to float.
taby said:
Yes the plan of attack is to reduce the precision, to emulate the conversion to float.
Let me sum up, to see if i got everything right:
You try to simulate real world physics.
It turns out you come closer to reality if you reduce precision on purpose.
Since this does not really make sense, you try ‘unlimited’ precision, to see what that does. It's still worse than lower precision.
Finally, instead trying to figure out what's probably wrong with your math about physics, you try to improve the process of… reducing precision on purpose?
You do not consider that this ‘32 bits is more accurate than 64 bits’ observation might be a hint about wrong equations?
But well, just keep going. You can always add 19 tiny extra dimensions out of nowhere and call it a string. Just make it complex enough and nobody will dare to complain. :D
LOL
Yes if it’s a coincidence, then it’s a doozy of a trick. I prefer to believe that it’s how it works, and I just don’t know how to emulate it yet. As for your code, pics please!
Could it be there is an error in your initial data?
For example the initial velocity of your planet. They have elliptic trajectories in practice afaik, and so their velocity differs depending on how close they are to the sun.
Maybe your stuff would work without the cast if initial data is ‘right’?
taby said:
As for your code, pics please!
Well, my startegy has shifted from keeping secrets to proofing i was first. So i will post pictures. But it still takes some orbits…
I tried different initial data for the velocity of Mercury. This is not chaotic, so a tiny change doesn't lead to a huge difference.
I also tried different time steps for Newtonian gravity. The smaller the time step, the closer to Newtonian gravity it becomes. Once I have the base rotation zeroed out, I then enable post-Newtonian effects to get a true answer.
taby said:
I tried different initial data for the velocity of Mercury. This is not chaotic, so a tiny change doesn't lead to a huge difference.
But if it's not right, it spirals in or out and the orbit isn't stable?
taby said:
I also tried different time steps for Newtonian gravity. The smaller the time step, the closer to Newtonian gravity it becomes.
In my fluid sim i use timesteps like 0.000001 iirc, so your 0.01 might be still huge eventually.
I don' think so, but maybe a better integrator like midpoint or RK4 would help.
Midpoint already helps a lot if trajectory is curved in my experience. (though, iirc. you do not integrate linear velocity but probably angular velocity around the sun.)
JoeJ said:
you do not integrate linear velocity but probably angular velocity around the sun
In an N-body simulation you would integrate linear velocity for the motion through space. The path it follows is curved due to the gravitational force. Angular velocity refers to the spin of the body, where the angular velocity direction is the instantaneous rotation axis and its magnitude is the angular speed in radians/second.
I agree that a better integrator like RK4 and a smaller time step can make a huge difference. The accuracy of a simulation is only as good as the error introduced by discrete integration, and you can reduce error proportional to dt^4 with RK4, while a Euler integrator has error proportional to dt. So RK4 can use orders of magnitude larger time step and get similar results, or get much higher accuracy for same time step.
