Celestia Forums

With the achieved improvements undisputed, the recently
incorporated method of improving the precision
of orbit displays reminds me of a tank battle [latest CVS, 1.3.2.pre7(?)].

Here is an illustration of Saturn's orbit for three values
of OrbitPathSamplingPoints: 100 (default), 500 and 1000.


Here is the full scene:
cel://Follow/Sol:Saturn/2004-03-17T06:56:32.79479?x=gEVCBPSTCK2eDA&y=SvZH1bjGY9T+/////////w&z=9TQ8qKejSJt0/////////w&ow=0.597533&ox=0.368405&oy=-0.707047&oz=0.085538&select=Sol:Saturn&fov=47.787090&ts=1.000000<d=0&rf=120759&lm=0

Aparently the present default of 100 OPSP's produces
really kinky displays in many places! With the present method
it takes a factor of 10 more OPSP's for a really decent orbit display.
Accordingly, the fps rate is bound to drop drastically: by a factor of 1.6
in the present example 100 -> 1000 OPSP's!

In view of this poor "convergence", everyone knowing
about numerical math algorithms would thus start
to explore better, alternative methods...

In cases were the generation of exact points is comparably
"expensive", it is usually much faster to use
3d (cubic) Spline interpolation of a
relatively low number of OPSP's!.

Unlike standard interpolation algorithms, Splines have
many advantages, whence scientists use them exclusively for similar tasks:

-- Splines can handle rapid variations smoothly and cheaply!

-- Splines are "local" interpolations in the sense that only
a few exact points around the interpolated point are
used, rather than the full table of sampled values!

-- There exist extremely fast Spline code templates
(even in assembler ), because Splines are such
important tools.

I have not had the time to study Kendrix' code in detail,
but I though I make these comments to stimulate
perhaps some discussions about this issue.

Bye Fridger

I'm not too deeply familiar with splines to contribute much, but I think having a spline function library integrated into Celestia would give a spinoff for other improvements too. I think of rings, models(?), camera movement, ...

maxim

This is a great idea Fridger, I'm no expert but I remember reading that splines are supported by OpenGl. Maybe its as simple as switching to GlSpline rather than GlLine.

In my old feature request at
http://members.xoom.virgilio.it/pangeli ... Orbits.htm
I was asking for this improvement.

GLU allows to manage Bezier splines and Nurbs surfaces.

A brief example is available at:
http://www.gametutorials.com/Tutorials/ ... GL_Pg4.htm

Bye - Paolo

Paolo wrote:In my old feature request at
http://members.xoom.virgilio.it/pangeli ... Orbits.htm
I was asking for this improvement.

GLU allows to manage Bezier splines and Nurbs surfaces.

A brief example is available at:
http://www.gametutorials.com/Tutorials/ ... GL_Pg4.htm

Bye - Paolo

Hi Paulo,

sorry I did not look into your site. I work with Splines in
different contexts since decades . So when I need
to talk about them, I normally do not look for further info.

I had not followed this lengthy discussion about Kendrix'
'wonder code' said to produce great precision orbits.
Had I known, I would have brought up Splines earlier...

The OpenGL examples/ tutorials you quoted, seem fun to
play with. Notably, since on my Laptop, I have VS.net (version 7) installed and can just start exploring the
tutorial. Of course, it's great that OpenGL supports
Splines! No wonder, since its the only good solution

Bye Fridger

Splines could be useful for rendering orbits paths if they are adaptively sampled based on distance from the viewer. I may have a look at this in a week or so (unless someone else beats me to it.) In the mean time, there's a very obvious way to improve the performance of orbit rendering which I'll look at later today.

--Chris

chris wrote:Splines could be useful for rendering orbits paths if they are adaptively sampled based on distance from the viewer. I may have a look at this in a week or so (unless someone else beats me to it.) In the mean time, there's a very obvious way to improve the performance of orbit rendering which I'll look at later today.

--Chris

Chris,

I am a little confused. Splines are never sampled. Splines are a means to /interpolate/ sampled exact orbit points. It's the exact orbit points that have to be adaptively sampled...

The task is to replace /linear/ interpolation with all its inefficient features by Spline interpolation. That's all as far as I can see.

Bye Fridger

PS: How can I make the Saturn shadow less dark?
It's just not right...(given Grant's rings, of course). But I believe in Grant's rings... Where in the code is the blackness set?

t00fri wrote:

chris wrote:Splines could be useful for rendering orbits paths if they are adaptively sampled based on distance from the viewer. I may have a look at this in a week or so (unless someone else beats me to it.) In the mean time, there's a very obvious way to improve the performance of orbit rendering which I'll look at later today.

--Chris

Chris,

I am a little confused. Splines are never sampled. Splines are a means to /interpolate/ sampled exact orbit points. It's the exact orbit points that have to be adaptively sampled...

OpenGL doesn't rasterize splines directly. Instead, they're subdivided into straight line segments. So, what Celestia could do is generate a set of splines that interpolate the sampled orbit points; then at rendering time, these splines would be rendered by subdividing them into line segments, with the degree of subdivision dependent on the curvature and projected size of the spline.

--Chris


The task is to replace /linear/ interpolation with all its inefficient features by Spline interpolation. That's all as far as I can see.

Bye Fridger

PS: How can I make the Saturn shadow less dark?
It's just not right...(given Grant's rings, of course). But I believe in Grant's rings... Where in the code is the blackness set?[/quote]

chris wrote:

t00fri wrote:

chris wrote:Splines could be useful for rendering orbits paths if they are adaptively sampled based on distance from the viewer. I may have a look at this in a week or so (unless someone else beats me to it.) In the mean time, there's a very obvious way to improve the performance of orbit rendering which I'll look at later today.

--Chris

Chris,

I am a little confused. Splines are never sampled. Splines are a means to /interpolate/ sampled exact orbit points. It's the exact orbit points that have to be adaptively sampled...

OpenGL doesn't rasterize splines directly. Instead, they're subdivided into straight line segments. So, what Celestia could do is generate a set of splines that interpolate the sampled orbit points; then at rendering time, these splines would be rendered by subdividing them into line segments, with the degree of subdivision dependent on the curvature and projected size of the spline.

--Chris

Sorry, for being still not with you:

You say above "Instead, they're subdivided into straight line segments.". Splines are curve segments the shape of which depends on 3-4 points, an initial one, a final one and 1-2 "control" points that determine the curvatures of that curve segment.

So how can a Spline be "subdivided into straight line segments"?

Bye Fridger

PS: You overlooked my PS above:

Where in the CVS code can I make the B-ring shadow less black??

t00fri wrote:Sorry, for being still not with you:

You say above "Instead, they're subdivided into straight line segments.". Splines are curve segments the shape of which depends on 3-4 points, an initial one, a final one and 1-2 "control" points that determine the curvatures of that curve segment.

So how can a Spline be "subdivided into straight line segments"?

Lots of very short line segments are used to approximate the curve. From a quality standpoint, dividing the curve into lines no longer than a pixel width is ideal. But, that's not practical . . . Nor is it really necessary, as you can get satisfactory results with longer line segments.

PS: You overlooked my PS above:

Where in the CVS code can I make the B-ring shadow less black??

[/quote]

Look at the function renderRingShadowsVS() in render.cpp and find this line:

float alpha = 1.0f;

The blackness of the ring shadows is equal to the ring texture opacity times alpha. If you want lighter ring shadows, you can set alpha to a lower value. 0.0 will make them disappear entirely, 0.5 will make them half as dark as they are currently. In Celestia 1.3.1, the darkness of the rings was set to:

(1.0 - abs(ri.sunDir_obj.y)) * c

where c is some constant between 0 and 1. This expression had the effect of making the ring shadow darkness darker the closer the rings were to being edge on to the sun. There's some justification for this hack--sunlight travels further through the rings when they're edge on. But mostly I did it so that Saturn looks like it does in the Voyager images when the rings are edge on to the sun without introducing the dark broad bands that you're unhappy with now. My feeling is that the dark bands are in fact correct, albeit very unfamiliar to us. I've a feeling they'll seem much more natural once we're barraged with images from Cassini.

--Chris

t00fri wrote:
Sorry, for being still not with you:

You say above "Instead, they're subdivided into straight line segments.". Splines are curve segments the shape of which depends on 3-4 points, an initial one, a final one and 1-2 "control" points that determine the curvatures of that curve segment.

So how can a Spline be "subdivided into straight line segments"?

When you compute the formula for a spline, you get the exact functions that interpolates between two points in the interpolated data. However, when you have to draw those lines, you have to do it with a lot of little straight lines, since (at least until now) only straight lines were drawn in the code itself.