Orbit

Report bugs, bug fixes and workarounds here.
Topic author
ron
Posts: 18
Joined: 25.02.2002
With us: 22 years 9 months
Location: Perth, Australia

Orbit

Post #1by ron » 11.03.2002, 14:17

When i zoom in close to a planet the orbit line (if i have orbits on) appears to turn at a right angle just befor the planet. All the other planet orbits remain OK.

chenyu

The problem with orbits

Post #2by chenyu » 11.05.2002, 08:26

The problem with orbits appears to be that celestia samples 100 points from each
orbit and then plots the orbits using these points. The trouble is that the orbits start
looking jerky when you zoom in close to an orbit.

Ideally celestia should sample more points close into the orbit. Another option is
to heavily sample the orbit of the object currently selected.

chenyu

patch to improve orbit rendering

Post #3by chenyu » 11.05.2002, 09:05

--- render.cpp 2002-05-11 03:54:47.000000000 -0500
+++ render.cpp.orig 2002-05-02 12:53:47.000000000 -0500
@@ -714,20 +714,7 @@
orbit->body = body;
orbit->keep = true;
OrbitSampler sampler(&orbit->trajectory);
-
- // This makes the orbits look better
- // I use a high sample rate so that the orbits remain curves
- // even when you are close in
-
- // I start the sample one/half period in the past and move
- // forward by one period
-
- // The planets are not perfect ellipses due to perturbations
- // and if I start and stop at time t, I get a kink in the
- // planetary orbits
-
- body->getOrbit()->sample(t - body->getOrbit()->getPeriod() / 2.0,
- body->getOrbit()->getPeriod(), 1000,
+ body->getOrbit()->sample(t, body->getOrbit()->getPeriod(), 100,
sampler);
trajectory = &orbit->trajectory;

[joe@bodhi celengine]$ diff -u render.cpp.orig render.cpp
--- render.cpp.orig 2002-05-02 12:53:47.000000000 -0500
+++ render.cpp 2002-05-11 03:54:47.000000000 -0500
@@ -714,7 +714,20 @@
orbit->body = body;
orbit->keep = true;
OrbitSampler sampler(&orbit->trajectory);
- body->getOrbit()->sample(t, body->getOrbit()->getPeriod(), 100,
+
+ // This makes the orbits look better
+ // I use a high sample rate so that the orbits remain curves
+ // even when you are close in
+
+ // I start the sample one/half period in the past and move
+ // forward by one period
+
+ // The planets are not perfect ellipses due to perturbations
+ // and if I start and stop at time t, I get a kink in the
+ // planetary orbits
+
+ body->getOrbit()->sample(t - body->getOrbit()->getPeriod() / 2.0,
+ body->getOrbit()->getPeriod(), 3000,
sampler);
trajectory = &orbit->trajectory;

Matt McIrvin
Posts: 312
Joined: 04.03.2002
With us: 22 years 8 months

Adaptive sampling

Post #4by Matt McIrvin » 13.05.2002, 03:26

More to the point would be to do some sort of adaptive sampling so that the curve is subdivided further if the polygon deviates from the actual curve by more than some threshold. There could be an absolute limit on sampling frequency as well.

This is how conventional curve flattening algorithms usually work (Foley and van Dam cover the subject in good detail).

drjoe

Adaptive orbits

Post #5by drjoe » 13.05.2002, 18:17

Yeah, I've been looking at the code to see how to make that work.

One of the problems is that you have to take into account the location
of the observer. One thing that I found out is that sampling at 3000
breaks if you move within a few km of the object, which happens if
you are a comet or asteroid. So what you need is a lot of samples
near the observer and fewer samples further away. You can also
"cheat" by ignoring the observer and creating a large number of
samples near the object.

It's all doable, and I'm looking at the code to figure out the best
way of doing it.


Return to “Bugs”