Re: [Glelite-deve] glElite & CrystalSpace

[Timo K S. <tks...@cc...>]

> I was thinking that the Planets, Moons, Bases, and Ships
> would use the 3D modeling that is used.

Using plain 3D models such as 3DS or LWO is simple in
glElite, as it can already load and show Lightwave
objects pretty nicely.

Last time I checked the 3D object class hierarchy in
Crystal Space it lacked some functions I needed, and it
did not have Lightwave loader then. I don't know about
the present situation.

The current 3D object model class hierarchy in glElite
is actually a frontend, a flexible API. It is not very
good for drawing, in fact it is very unoptimized. I
plan to add backend optimizers later.

> the 3D model (adding more objects for detail around
> your landing site) or do a 'perspective shift; and
> switch to the Terrain generator with the buildings
> for the StarPort being modelled. Once you get close
> enough to most Planets or Moons, you only see thelocal
> environment plus what ever is overhead anyways.

This is the idea in general, but it does not cover
terrain. Terrain must be look something decent from
any possible altitude, and if you try modelling Earth
so that it looks good from 10m, 1km, 10km, 100km and
thousands of kilometers, you will notice that a making
even a simple sphere mesh for this is very diffucult.

The ROAM addresses most of the problems in a convenient
way.

> modeling, lighting, sprite, and object library systems
> in place that could be vary useful. I was thinking that
> if glElite was using portions of CS, then both projects

I have checked Crystal Space couple of times, and the
architecture is a little, em, different. It would be
beneficial to analyse the differnecies, document those,
and maybe merge some features if it seems possible.

> would benefit. Maybe your 3D Terrain can be another
> plugin to CS in the long run?

The terrain ROAM code is not mine. It is written and
maintained by Sean O'Neil. I have added some very small
tweaks and suggestions only.


-- Timo Suoranta -- tks...@cc... --