New spiral galaxy types rendering
- t00fri
- Developer
- Posts: 8772
- Joined: 29.03.2002
- Age: 22
- With us: 22 years 7 months
- Location: Hamburg, Germany
Paolo,
you are certainly right pointing out all these missing aspects once more. But here the main aspect CANNOT be to incorporate full 3d information, simply since it is entirely lacking.
++++++++++++++++++++++++++++
The crucial aspect is rather to keep track in an admittedly somewhat primitive but AUTOMATED fashion of a "state-of-the-art" archive of 14000 (!) deep-sky objects in Celestia, the RA & Dec coordinates and 2d shape information of which are very well known.
++++++++++++++++++++++++++++
So it's more a "bookkeeping" task "embellished" with Toti's graphical "skeleton" rather than a sophisticated rendering attempt. As to the latter, only tediously and individually "handicrafted" attempts could possibly be imagined. Also we need to be pretty fast to handle 14000 objects in Celestia...
Bye Fridger
you are certainly right pointing out all these missing aspects once more. But here the main aspect CANNOT be to incorporate full 3d information, simply since it is entirely lacking.
++++++++++++++++++++++++++++
The crucial aspect is rather to keep track in an admittedly somewhat primitive but AUTOMATED fashion of a "state-of-the-art" archive of 14000 (!) deep-sky objects in Celestia, the RA & Dec coordinates and 2d shape information of which are very well known.
++++++++++++++++++++++++++++
So it's more a "bookkeeping" task "embellished" with Toti's graphical "skeleton" rather than a sophisticated rendering attempt. As to the latter, only tediously and individually "handicrafted" attempts could possibly be imagined. Also we need to be pretty fast to handle 14000 objects in Celestia...
Bye Fridger
- t00fri
- Developer
- Posts: 8772
- Joined: 29.03.2002
- Age: 22
- With us: 22 years 7 months
- Location: Hamburg, Germany
..some further thoughts about exploiting existing catalog info:
Steinicke's catalogue does not give actual tilt angles of the extended objects. In case of galaxies at least, it makes a lot of sense to assume that there is some perspective in space where the objects appear essentially rotation symmetric with respect to some axis. On the basis of this plausible assumption the angles of that (virtual) axis in space (and hence the tilt angles) can be reconstructed from the given apparent larger/smaller diameters & the position angle by means of some trivial trigonometry.
If needed, I can certainly help to work these simple formulae out.
Bye Fridger
Steinicke's catalogue does not give actual tilt angles of the extended objects. In case of galaxies at least, it makes a lot of sense to assume that there is some perspective in space where the objects appear essentially rotation symmetric with respect to some axis. On the basis of this plausible assumption the angles of that (virtual) axis in space (and hence the tilt angles) can be reconstructed from the given apparent larger/smaller diameters & the position angle by means of some trivial trigonometry.
If needed, I can certainly help to work these simple formulae out.
Bye Fridger
Ah, I thought position angle meant the tilt angle - what is it then?t00fri wrote:Steinicke's catalogue does not give actual tilt angles of the extended objects.
So no dynamic data for galaxies? A pity.t00fri wrote:For code planning purposes, I list below the catalog entries and notably further below an explanation of the object TYPEs!
Yes, that's true of course. I didn't know a short word for it:Evil Dr Ganymede wrote:They wouldn't evolve really over the scale of millennia (1000s of years) - it'd take millions of years at least to notice anything changing.
century, millenium, ...? (millions-and-millions-of-years-or-what?)
Evil Dr Ganymede wrote:And I'm not sure anyone really knows how galactic structure evolves anyway do they (it's not like we've been watching galaxies evolve for billions of years is it).
I thought that the above diagram showes how galaxy evolution goes on in theory - no?
BTW - staying a large timescales, I would not only like to see the 'Dance of the Galaxies' to describe it in a poetic way, but also the evolution of stars. So what about an algorithm that - provided by a time parameter - pushes the (Celestia-)existing stars forward and backward throught the Russel-Hertzsprung-Diagram?
maxim
Last edited by maxim on 30.03.2005, 17:29, edited 1 time in total.
- t00fri
- Developer
- Posts: 8772
- Joined: 29.03.2002
- Age: 22
- With us: 22 years 7 months
- Location: Hamburg, Germany
maxim wrote:Ah, I thought position angle meant the tilt angle - what is it then?t00fri wrote:Steinicke's catalogue does not give actual tilt angles of the extended objects.
The same meaning as in case of binaries: It's the apparent angle in the sky plane (seen from Earth) of the longer axis relative to some fixed direction (North). Imagine an ellipse to characterize the galaxy boundaries. Then you must speciify how the ellipse is oriented wrto North.
Maxim wrote:So no dynamic data for galaxies? A pity.t00fri wrote:For code planning purposes, I list below the catalog entries and notably further below an explanation of the object TYPEs!
what are a "dynamic" data for galaxies?? You probably mean time-dependent, i.e. non-static, I suppose.
Bye Fridger
maxim wrote:I thought that the above diagram showes how galaxy evolution goes on in theory - no?Evil Dr Ganymede wrote:And I'm not sure anyone really knows how galactic structure evolves anyway do they (it's not like we've been watching galaxies evolve for billions of years is it).
maxim
Maxim, the various galactic types are unrelated to the galactic evolution.
Galactic types are just a morphological representation of galaxies. They are often a source of confusion. As an example : two spiral galaxies may collide and merge together, expulsing the dust and gaz, and form a new gigantic elliptical galaxy.
Nobody knows really how galaxies are evolving. It's a very tricky matter.
"Well! I've often seen a cat without a grin", thought Alice; "but a grin without a cat! It's the most curious thing I ever saw in all my life!"
Ok. So it's the tip, not the tilt.t00fri wrote:Imagine an ellipse to characterize the galaxy boundaries. Then you must speciify how the ellipse is oriented wrto North.
t00fri wrote:what are a "dynamic" data for galaxies?? You probably mean time-dependent, i.e. non-static, I suppose.
non-static=dynamic - no?
Yes, I meant 'rotation period', 'streching', 'proper motion', 'redshift, ...
Watching popular sience docus, you often can here coments like 'These galaxies will collide in x million years', 'A star in that distance will move around the galactic core once in y milion years', 'The arms are streching that way while the galaxy rotates'. Supposed that not all of this is journalistic crap, there must be some data where the information came from.
Ok, ok. I'm waving goodbye to my idea of celestia simulations on big timescales (sight).
maxim
- t00fri
- Developer
- Posts: 8772
- Joined: 29.03.2002
- Age: 22
- With us: 22 years 7 months
- Location: Hamburg, Germany
maxim wrote:Ok. So it's the tip, not the tilt.t00fri wrote:Imagine an ellipse to characterize the galaxy boundaries. Then you must speciify how the ellipse is oriented wrto North.non-static=dynamic - no?t00fri wrote:what are a "dynamic" data for galaxies?? You probably mean time-dependent, i.e. non-static, I suppose.
Yes, I meant 'rotation period', 'streching', 'proper motion', 'redshift, ...
Watching popular sience docus, you often can here coments like 'These galaxies will collide in x million years', 'A star in that distance will move around the galactic core once in y milion years', 'The arms are streching that way while the galaxy rotates'. Supposed that not all of this is journalistic crap, there must be some data where the information came from.
Ok, ok. I'm waving goodbye to my idea of celestia simulations on big timescales (sight).
maxim
Maxim,
but such "exotic" information like trends of galaxies to collide or Andromeda (m31) hitting our milky way can at best apply to very special objects. We want to mass-render 14000 objects in order that Celestia could respond to somebody's query about that dim 16 th magnitude glitch of light in Sagittarus...
Bye Fridger
t00fri wrote:Maxim,
but such "exotic" information like trends of galaxies to collide or Andromeda (m31) hitting our milky way can at best apply to very special objects. We want to mass-render 14000 objects in order that Celestia could respond to somebody's query about that dim 16 th magnitude glitch of light in Sagittarus...
Well, I always seem to tend to rely on sientific knowlegde beeing far beyond my small mind. I really thought that asking for a galaxies proper motion just gives an answer from a bored sientist like:
"(Yawn) - yes, no problem, to what precision to you need it? Is 16 digits enought?"
maxim
-
- Posts: 1386
- Joined: 06.06.2003
- With us: 21 years 5 months
maxim wrote:Yes, that's true of course. I didn't know a short word for it: century, millenium, ...? (millions-and-millions-of-years-or-what?)
I guess "aeon" works for a timespan of millions of years. Geologists use "Periods" for spans lasting tens of millions of years and "Eras" for hundreds of millions of years. And sometimes "Epoch" is in there too somewhere.
Generally though, I think we should avoid trying to simulate EVERY detail of a galaxy, otherwise we're just going to get bogged down in detail. Most of the time, we're probably not going to have all the info required (if we start thinking of halos, then we need to know how many globular clusters each galaxy has, etc). Maybe it'd be better to get something that is just broadly representative of the galaxy that we're looking at (ie just have one graphic representing a barred spiral, or elliptical or a ring galaxy or whatever), and forget about the halo.
- PlutonianEmpire
- Posts: 1374
- Joined: 09.09.2004
- Age: 40
- With us: 20 years 2 months
- Location: MinneSNOWta
- Contact:
Time passes by and the expectations about this patch are growing.
Perhaps I've missed something.... But I haven't seen the C++ code yet.
It seems to me that Toti is a little bit jealous of it.
Other options should be that there are some implementation problems or only a spare of time is available. In both cases if the code will be shared perhaps someone of us will be able to help.
Perhaps I've missed something.... But I haven't seen the C++ code yet.
It seems to me that Toti is a little bit jealous of it.
Other options should be that there are some implementation problems or only a spare of time is available. In both cases if the code will be shared perhaps someone of us will be able to help.
Thanks Chris for your help offer. The C++ was the easy part however.
I just came to the conclusion that the present code is useless. It has a strong dependance on curvature, so density gets too high in eg. bars. This implies a lot of blobs near the center, in addition to the galaxy bulge ones. The framerate is thus lowed significantly on slow machines.
Tweaking the LOD solves the problem, but the Milky Way's shape isn't recognizable from Earth's surface anymore.
I have to investigate a curvature independent solution.
And please lower your expectations: this is not a piece of highly sophisticated code: it's just a parametrized spiral trajectory, a mere extension of Chris's original hack.
I just came to the conclusion that the present code is useless. It has a strong dependance on curvature, so density gets too high in eg. bars. This implies a lot of blobs near the center, in addition to the galaxy bulge ones. The framerate is thus lowed significantly on slow machines.
Tweaking the LOD solves the problem, but the Milky Way's shape isn't recognizable from Earth's surface anymore.
I have to investigate a curvature independent solution.
And please lower your expectations: this is not a piece of highly sophisticated code: it's just a parametrized spiral trajectory, a mere extension of Chris's original hack.
- t00fri
- Developer
- Posts: 8772
- Joined: 29.03.2002
- Age: 22
- With us: 22 years 7 months
- Location: Hamburg, Germany
Toti wrote:Thanks Chris for your help offer. The C++ was the easy part however.
I just came to the conclusion that the present code is useless. It has a strong dependance on curvature, so density gets too high in eg. bars. This implies a lot of blobs near the center, in addition to the galaxy bulge ones. The framerate is thus lowed significantly on slow machines.
Tweaking the LOD solves the problem, but the Milky Way's shape isn't recognizable from Earth's surface anymore.
I have to investigate a curvature independent solution.
And please lower your expectations: this is not a piece of highly sophisticated code: it's just a parametrized spiral trajectory, a mere extension of Chris's original hack.
Toti,
perhaps it would'nt be bad to really make your mathematical galaxy parametrizations available. I happen to be pretty experienced in such games, from my professional background. Perhaps I could help with some simplifications. Also Paulo indicated readyness to help.
For instance, in the early Celestia days, I managed to save a factor of 30 in nebula rendering time at small field of view by means of (clever) culling ...
Bye Fridger
Sure. Here is a .diff against latest CVS. This uses the most recent parametrization. To actually watch the galaxies, just replace the values marked by //*** with a 255 in GalaxyTextureEval().
Code: Select all
? .deps
? .libs
? Makefile
? Makefile.in
? buildstardb
? myPatch.diff
? cel3ds/.deps
? cel3ds/Makefile
? cel3ds/Makefile.in
? celengine/.deps
? celengine/Makefile
? celengine/Makefile.in
? celestia/.deps
? celestia/.libs
? celestia/Makefile
? celestia/Makefile.in
? celestia/celestia
? celestia/gtk/Makefile
? celestia/gtk/Makefile.in
? celestia/gtk/data/Makefile
? celestia/gtk/data/Makefile.in
? celestia/kde/.deps
? celestia/kde/Makefile
? celestia/kde/Makefile.in
? celestia/kde/celestialbrowser.moc.cpp
? celestia/kde/celestialbrowserbase.uic.cpp
? celestia/kde/celestialbrowserbase.uic.h
? celestia/kde/celestialbrowserbase.uic.moc.cpp
? celestia/kde/eclipsefinderdlg.moc.cpp
? celestia/kde/eclipsefinderdlgbase.uic.cpp
? celestia/kde/eclipsefinderdlgbase.uic.h
? celestia/kde/eclipsefinderdlgbase.uic.moc.cpp
? celestia/kde/kcelbookmarkmanager.moc.cpp
? celestia/kde/kcelbookmarkmenu.moc.cpp
? celestia/kde/kdeapp.moc.cpp
? celestia/kde/kdeglwidget.moc.cpp
? celestia/kde/kdepreferencesdialog.moc.cpp
? celestia/kde/kdeuniquecelestia.moc.cpp
? celestia/kde/selectionpopup.moc.cpp
? celestia/kde/data/Makefile
? celestia/kde/data/Makefile.in
? celestia/kde/doc/Makefile
? celestia/kde/doc/Makefile.in
? celestia/kde/doc/celestia/Makefile
? celestia/kde/doc/celestia/Makefile.in
? celestia/kde/po/Makefile
? celestia/kde/po/Makefile.in
? celestia/res/Makefile
? celestia/res/Makefile.in
? celmath/.deps
? celmath/Makefile
? celmath/Makefile.in
? celtxf/.deps
? celtxf/Makefile
? celtxf/Makefile.in
? celutil/.deps
? celutil/Makefile
? celutil/Makefile.in
Index: celengine/galaxy.cpp
===================================================================
RCS file: /cvsroot/celestia/celestia/src/celengine/galaxy.cpp,v
retrieving revision 1.13
diff -u -r1.13 galaxy.cpp
--- celengine/galaxy.cpp 11 Feb 2005 05:09:36 -0000 1.13
+++ celengine/galaxy.cpp 31 Mar 2005 23:14:26 -0000
@@ -24,23 +24,27 @@
using namespace std;
+
+static const unsigned int GALAXY_POINTS = 5000;
+
static bool formsInitialized = false;
-static vector<Point3f>* spiralPoints = NULL;
-static vector<Point3f>* ellipticalPoints = NULL;
-static vector<Point3f>* irregularPoints = NULL;
-static GalacticForm* spiralForm = NULL;
-static GalacticForm* irregularForm = NULL;
+
+static GalacticForm** spiralForms = NULL;
static GalacticForm** ellipticalForms = NULL;
-static void InitializeForms();
+static GalacticForm* irregularForm = NULL;
static Texture* galaxyTex = NULL;
+static void InitializeForms();
+
+
struct GalaxyTypeName
{
const char* name;
Galaxy::GalaxyType type;
};
+
static GalaxyTypeName GalaxyTypeNames[] =
{
{ "S0", Galaxy::S0 },
@@ -62,6 +66,12 @@
};
+static float gaussr()
+{
+ return Mathf::gaussrand() / (2 * (float) exp(1.0f)); //hack: should work for the 5000 points default.
+}
+
+
static void GalaxyTextureEval(float u, float v, float w,
unsigned char *pixel)
{
@@ -70,9 +80,9 @@
r = 0;
int pixVal = (int) (r * 255.99f);
- pixel[0] = 65;
- pixel[1] = 64;
- pixel[2] = 65;
+ pixel[0] = 65; //***
+ pixel[1] = 64; //***
+ pixel[2] = 65; //***
pixel[3] = pixVal;
}
@@ -115,10 +125,7 @@
case SBa:
case SBb:
case SBc:
- form = spiralForm;
- break;
- case Irr:
- form = irregularForm;
+ form = spiralForms[type - S0];
break;
case E0:
case E1:
@@ -130,7 +137,10 @@
case E7:
form = ellipticalForms[type - E0];
break;
- }
+ case Irr:
+ form = irregularForm;
+ break;
+ }
}
@@ -190,19 +200,19 @@
float distanceToObject = offset.length() - getRadius();
if (distanceToObject < 0)
distanceToObject = 0;
- float minimumFeatureSize = pixelSize * 0.5f * distanceToObject;
+ float minimumFeatureSize = pixelSize * 0.75f * distanceToObject; //0.5f
Mat4f m = (getOrientation().toMatrix4() *
Mat4f::scaling(form->scale) *
Mat4f::scaling(getRadius()));
- float size = getRadius();
+ float size = getRadius() / 2.0f; //1.0f
int pow2 = 1;
vector<Point3f>* points = form->points;
int nPoints = (int) (points->size() * clamp(getDetail()));
glBegin(GL_QUADS);
- for (int i = 0; i < nPoints; i++)
+ for (int i = 0; i < nPoints; ++i)
{
Point3f p = (*points)[i] * m;
Point3f relPos = p + offset;
@@ -210,7 +220,7 @@
if ((i & pow2) != 0)
{
pow2 <<= 1;
- size /= 1.5f;
+ size /= 1.25f; //1.5f
if (size < minimumFeatureSize)
break;
}
@@ -250,81 +260,131 @@
}
-void InitializeForms()
+GalacticForm* buildSpiralForms(const float torsion, const float noiseAmp, const float logRatio,
+ const float bulgeRad, const float barRad)
{
- int galaxySize = 5000;
- int i;
+ const float torsionPI = torsion * PI;
+ const float phi = logRatio * torsion;
+ const float phiExp = (float) exp(phi) - 1.0f;
+ const float barRadCube = 4.0f * cube(barRad);
+ const float barRadQuad = 3.0f/4.0f * barRad;
+
+ vector<Point3f>* spiralPoints = new vector<Point3f>();
+ spiralPoints->reserve(GALAXY_POINTS);
- // Initialize the spiral form--this is a big hack
- spiralPoints = new vector<Point3f>();
- spiralPoints->reserve(galaxySize);
- for (i = 0; i < galaxySize; i++)
+ for (unsigned int i = 0; i < GALAXY_POINTS; ++i)
{
- float r = Mathf::frand();
- float theta = Mathf::sfrand() * PI;
-
- if (r > 0.2f)
- {
- theta = (Mathf::sfrand() + Mathf::sfrand() + Mathf::sfrand()) * (float) PI / 2.0f / 3.0f;
- if (Mathf::sfrand() < 0)
- theta += (float) PI;
+ float s, c;
+
+ // TODO: add a random number generator with an ad-hoc density distribution:
+ float r = Mathf::frand();
+
+ float gaussProfile = (float) exp(-0.25f * square(r)) * noiseAmp; // follow a bell profile along arms
+
+ if (r < bulgeRad)
+ {
+ r = bulgeRad * Mathf::frand();
+ Mathf::sincos(PI * Mathf::frand(), s, c);
+ }
+ else if (r < barRad)
+ {
+ r = ((float) exp(phi * r) - 1.0f) / phiExp;
+ Mathf::sincos(torsionPI * (square(r*r) / barRadCube + barRadQuad), s, c);
}
- theta += (float) log(r + 1) * 3 * PI;
- float x = r * (float) cos(theta);
- float z = r * (float) sin(theta);
- float y = Mathf::sfrand() * 0.1f * 1.0f / (1 + 2 * r);
- spiralPoints->insert(spiralPoints->end(), Point3f(x, y, z));
- }
- spiralForm = new GalacticForm();
- spiralForm->points = spiralPoints;
- spiralForm->scale = Vec3f(1, 1, 1);
+ else
+ {
+ r = ((float) exp(phi * r) - 1.0f) / phiExp;
+ Mathf::sincos(torsionPI * r, s, c);
+ }
+
+ float x = gaussProfile * gaussr() + r * c;
+ float y = gaussProfile * gaussr() / 2.5f;
+ float z = gaussProfile * gaussr() + r * s;
+
+ if (Mathf::sfrand() > 0.0f)
+ {
+ x = -x; z = -z;
+ }
+ spiralPoints->push_back(Point3f(x, y, z));
+ }
+
+ GalacticForm* spiralForm = new GalacticForm();
+ spiralForm->points = spiralPoints;
+ spiralForm->scale = Vec3f(1.0f, 1.0f, 1.0f);
+
+ return spiralForm;
+}
- irregularPoints = new vector<Point3f>;
- irregularPoints->reserve(galaxySize);
+
+void InitializeForms()
+{
+ unsigned int i;
+
+ spiralForms = new GalacticForm*[7];
+
+ //torsion, noiseAmp, logRatio, bulgeRad, barRad:
+ spiralForms[Galaxy::S0] = buildSpiralForms(0.0f, 0.75f, 0.00f, 1.00f, 1.00f);
+
+ spiralForms[Galaxy::Sa] = buildSpiralForms(4.0f, 0.40f, 0.15f, 0.25f, 0.25f);
+ spiralForms[Galaxy::Sb] = buildSpiralForms(3.0f, 0.40f, 0.35f, 0.10f, 0.10f);
+ spiralForms[Galaxy::Sc] = buildSpiralForms(2.5f, 0.40f, 0.65f, 0.01f, 0.01f);
+
+ spiralForms[Galaxy::SBa] = buildSpiralForms(5.0f, 0.45f, 0.01f, 0.20f, 0.75f);
+ spiralForms[Galaxy::SBb] = buildSpiralForms(3.0f, 0.75f, 0.30f, 0.15f, 0.75f);
+ spiralForms[Galaxy::SBc] = buildSpiralForms(2.0f, 0.85f, 0.65f, 0.15f, 0.75f);
+
+
+
+ vector<Point3f>* ellipticalPoints = new vector<Point3f>();
+ ellipticalPoints->reserve(GALAXY_POINTS);
i = 0;
- while (i < galaxySize)
+ while (i < GALAXY_POINTS)
{
Point3f p(Mathf::sfrand(), Mathf::sfrand(), Mathf::sfrand());
float r = p.distanceFromOrigin();
if (r < 1)
{
- float prob = (1 - r) * (fractalsum(Point3f(p.x + 5, p.y + 5, p.z + 5), 8) + 1) * 0.5f;
- if (Mathf::frand() < prob)
+ if (Mathf::frand() < cube(1 - r))
{
- irregularPoints->insert(irregularPoints->end(), p);
- i++;
+ ellipticalPoints->push_back(p);
+ ++i;
}
}
}
- irregularForm = new GalacticForm();
- irregularForm->points = irregularPoints;
- irregularForm->scale = Vec3f(1, 1, 1);
-
- ellipticalPoints = new vector<Point3f>();
- ellipticalPoints->reserve(galaxySize);
- i = 0;
- while (i < galaxySize)
+ ellipticalForms = new GalacticForm*[8];
+ for (int eform = 0; eform < 8; ++eform)
+ {
+ ellipticalForms[eform] = new GalacticForm();
+ ellipticalForms[eform]->points = ellipticalPoints;
+ ellipticalForms[eform]->scale = Vec3f(1.0f, 1.0f - (float) eform / 8.0f, 1.0f);
+ }
+
+
+
+ vector<Point3f>* irregularPoints = new vector<Point3f>;
+ irregularPoints->reserve(GALAXY_POINTS);
+ i = 0;
+ while (i < GALAXY_POINTS)
{
Point3f p(Mathf::sfrand(), Mathf::sfrand(), Mathf::sfrand());
float r = p.distanceFromOrigin();
if (r < 1)
{
- if (Mathf::frand() < cube(1 - r))
+ float prob = (1 - r) * (fractalsum(Point3f(p.x + 5, p.y + 5, p.z + 5), 8) + 1) * 0.5f;
+
+ if (Mathf::frand() < prob)
{
- ellipticalPoints->insert(ellipticalPoints->end(), p);
- i++;
+ irregularPoints->push_back(p);
+ ++i;
}
}
}
+ irregularForm = new GalacticForm();
+ irregularForm->points = irregularPoints;
+ irregularForm->scale = Vec3f(1.0f, 1.0f, 1.0f);
+
- ellipticalForms = new GalacticForm*[8];
- for (int eform = 0; eform <= 7; eform++)
- {
- ellipticalForms[eform] = new GalacticForm();
- ellipticalForms[eform]->points = ellipticalPoints;
- ellipticalForms[eform]->scale = Vec3f(1.0f, 1.0f - (float) eform / 8.0f, 1.0f);
- }
-
+
formsInitialized = true;
}
Index: celmath/mathlib.h
===================================================================
RCS file: /cvsroot/celestia/celestia/src/celmath/mathlib.h,v
retrieving revision 1.2
diff -u -r1.2 mathlib.h
--- celmath/mathlib.h 12 Mar 2002 04:58:25 -0000 1.2
+++ celmath/mathlib.h 31 Mar 2005 23:14:29 -0000
@@ -21,6 +21,7 @@
static inline void sincos(T, T&, T&);
static inline T frand();
static inline T sfrand();
+ static inline T gaussrand();
static inline T lerp(T t, T a, T b);
static inline T clamp(T t);
@@ -106,7 +107,6 @@
c = (T) cos(angle);
}
-
// return a random float in [0, 1]
template<class T> T Math<T>::frand()
{
@@ -121,6 +121,23 @@
}
+// return a (signed) random float with a gaussian/normal distribution
+// modified from the GNU Scientific Library. (src/randist/gauss.c, polar method)
+template<class T> T Math<T>::gaussrand()
+{
+ T x, y, r;
+ do
+ {
+ x = sfrand();
+ y = sfrand();
+ r = x*x + y*y;
+ }
+ while (r >= 1);
+
+ return x * (T) sqrt(-2 * (T) log(r) / r ); // Box-Muller transform.
+}
+
+
template<class T> T Math<T>::lerp(T t, T a, T b)
{
return a + t * (b - a);
Perhaps this also might be useful: this somewhat "cleaner" parametrization will create the blueprints seen in the screenshot. Use the following parameters (always noiseAmp = 0.0)
The empty area near the center dot is occupied by the bulge.
Bye
Code: Select all
#torsion logFactor bulgeRad barRad
#Sa = 4.0 1.25 0.25 0.35
#Sb = 3.0 1.50 0.15 0.25
#Sc = 2.0 2.00 0.10 0.15
#SBa = 4.0 0.25 0.25 0.65
#SBb = 2.0 0.50 0.15 0.55
#SBc = 1.0 1.00 0.10 0.45
Code: Select all
SPIRAL_POINTS = 5000
PI = 3.1416
#--------------------------------------------------------------------
def buildGalaxy(torsion, logFactor, bulgeRad, barRad):
for i in range(0, SPIRAL_POINTS):
bend = 0.0
re = 0.0
theta = 0.0
r = Noise.random()
if r < bulgeRad:
pass
elif r < barRad:
re = r / (barRad * math.exp(logFactor * (1.0 - barRad)))
bend = r**3 / barRad**2
elif r < 1.0:
re = math.exp(logFactor * (r - barRad)) / math.exp(logFactor * (1.0 - barRad))
bend = (3 * r - 2 * barRad)
theta = bend/3.0 * torsion * PI
x = re * math.cos(theta)
y = 0.0
z = re * math.sin(theta)
if sfrand() > 0.0:
x = -x
z = -z
#addVertex(x, y, z)
The empty area near the center dot is occupied by the bulge.
Bye
I'm just wondering if there has been any more progress ?
I assume there were a few flaws in the code ?
maxim wrote:Uh, Oh!
Do we really use non-optimized trig-functions, or is this for demonstration only? Also PI/3 should go into a constant, no?
maxim
I assume there were a few flaws in the code ?
1.6.0:AMDAth1.2GHz 1GbDDR266:Ge6200 256mbDDR250:WinXP-SP3:1280x1024x32FS:v196.21@AA4x:AF16x:IS=HQ:T.Buff=ON Earth16Kdds@15KkmArctic2000AD:FOV1:SPEC L5dds:NORM L5dxt5:CLOUD L5dds:
NIGHT L5dds:MOON L4dds:GALXY ON:MAG 15.2-SAP:TIME 1000x:RP=OGL2:10.3FPS
NIGHT L5dds:MOON L4dds:GALXY ON:MAG 15.2-SAP:TIME 1000x:RP=OGL2:10.3FPS
The Toti solution is for the shape of the galaxy spiral arms and he said that has a point distribution problem so I suppose that he is working on it.
If you want to spend a couple of minutes reading the following I've tried to resume the problem hopefully giving some new contribution.
I've analyzed briefly the original Celestia Code. To render the galaxies Celestia uses an array of 5000 points for each "galaxyForm" and so there is an array of forms, where each item represents a galaxy type.
The code creates at start-up the various galaxyForms placing the 5000 points accordingly the various shapes (this part is where Toti is going to improve the code).
During rendering for each point Celestia draws a blob (billboard): a faint circular halo that is a texture built at runtime. I think 5000 points is a compromise: should be more than enough watching the galaxy from far distance or should be not enough watching it from close distance.
Since the galaxy is rendered using BillBoards (textures that reorients automatically toward the observer) it is not possible to create openGL Displaylists to speedup the rendering. So every galaxy has to be drawn from scratch every time considering its proper orientation and the position and orientation of the observer.
It should be possible to optimize the code creating a displaylist every time that the observer moves or changes the FOV but i think that the total improvement should be negligible.
Watching a large number of galaxies from the inside of the milky way using large fovs is not a problem because Celestia has already a LOD management in the galaxy::render method. The code is not commented so it is a little bit tricky to understand how this LOD works, but it works!
I've understood it partially. I guess the distance of the observer reduces the number of Billboards drawn. So if the observer is near it draws all the 5000 points. If is more far it discards the last ones keeping only the first ones. So I guess that this works because the galaxyForm is based upon the assumption that all the points of the galaxy have a uniform distribution. Can someone confirm this?
This should be a big problem in order to manage correctly more complex galaxy shapes because is difficult to distribute bulge, arms and halo points uniformly in the 5000 points array.
Beside the Toti's work I think that this LOD should be improved changing the transparency of the BillBoards when are drawn. Now the transparency has always high values. I think that the transparency must be an inverse function of the distance of the observer and of the number of points. So when the distance is short (e.g. Milky way blobs inside the Milky way) should be used a high base transparency like now. Unlike when the distance is high or the fov is large a low transparency should be used. This should improve immediately the visual effect.
Another more complex and expensive improvement should be done including a size and color value to the points. So instead of 5000 x 3 (x,y,z) floats for every galaxyForm we will have 5000 x 5 (x,y,z,size,color) floats. The size parameter should include an intrinsic transparency value so small billboard should be more opaque than large ones.
A more complex improvement should be done if for every of the 5000 points we use a cluster of blobs instead of a single blob. This cluster should be managed like the galaxyforms adding an exponential level of detail to the Galaxy rendering.
The whole thing is a little bit complex! Since it's a long time that I don't compile the Celestia Win version I can't do some tests.
If you want to spend a couple of minutes reading the following I've tried to resume the problem hopefully giving some new contribution.
I've analyzed briefly the original Celestia Code. To render the galaxies Celestia uses an array of 5000 points for each "galaxyForm" and so there is an array of forms, where each item represents a galaxy type.
The code creates at start-up the various galaxyForms placing the 5000 points accordingly the various shapes (this part is where Toti is going to improve the code).
During rendering for each point Celestia draws a blob (billboard): a faint circular halo that is a texture built at runtime. I think 5000 points is a compromise: should be more than enough watching the galaxy from far distance or should be not enough watching it from close distance.
Since the galaxy is rendered using BillBoards (textures that reorients automatically toward the observer) it is not possible to create openGL Displaylists to speedup the rendering. So every galaxy has to be drawn from scratch every time considering its proper orientation and the position and orientation of the observer.
It should be possible to optimize the code creating a displaylist every time that the observer moves or changes the FOV but i think that the total improvement should be negligible.
Watching a large number of galaxies from the inside of the milky way using large fovs is not a problem because Celestia has already a LOD management in the galaxy::render method. The code is not commented so it is a little bit tricky to understand how this LOD works, but it works!
I've understood it partially. I guess the distance of the observer reduces the number of Billboards drawn. So if the observer is near it draws all the 5000 points. If is more far it discards the last ones keeping only the first ones. So I guess that this works because the galaxyForm is based upon the assumption that all the points of the galaxy have a uniform distribution. Can someone confirm this?
This should be a big problem in order to manage correctly more complex galaxy shapes because is difficult to distribute bulge, arms and halo points uniformly in the 5000 points array.
Beside the Toti's work I think that this LOD should be improved changing the transparency of the BillBoards when are drawn. Now the transparency has always high values. I think that the transparency must be an inverse function of the distance of the observer and of the number of points. So when the distance is short (e.g. Milky way blobs inside the Milky way) should be used a high base transparency like now. Unlike when the distance is high or the fov is large a low transparency should be used. This should improve immediately the visual effect.
Another more complex and expensive improvement should be done including a size and color value to the points. So instead of 5000 x 3 (x,y,z) floats for every galaxyForm we will have 5000 x 5 (x,y,z,size,color) floats. The size parameter should include an intrinsic transparency value so small billboard should be more opaque than large ones.
A more complex improvement should be done if for every of the 5000 points we use a cluster of blobs instead of a single blob. This cluster should be managed like the galaxyforms adding an exponential level of detail to the Galaxy rendering.
The whole thing is a little bit complex! Since it's a long time that I don't compile the Celestia Win version I can't do some tests.