Re: Beginning of the noise integration for the planet simulation

Hi Benjamin,

On Mon, 2013-07-29 at 23:45 -0400, B. Isherwood wrote:

> I have been going over the crystal space source and learning how to
> use libnoise.

About libnoise, you mention in your blog having some compilation
problems. Are you linking with a version of the library that you
installed separately, or are you using the version that is already
included in CS::Math::Noise? That's the second choice that is supposed
to be done, do you meet the same problems there?

Also, what is the public interface of the noise terrain generation tool
that you are implementing? A priori, this should implement the
iTerrainDataFeeder interface. You can take as an example eg the
'modifiable' feeder (defined in 'include/imesh/modifiableterrain.h',
implemented in
'plugins/mesh/terrain/terrain2/modifiabledatafeeder.h/cpp').

> Currently though I think that the sphere mesh should be a separate
> mesh than the terrain2 mesh.

Creating a new mesh type has several drawbacks and should be avoided
when possible.

Also, the original goal of the project was to extend the features around
the current terrain2 mesh, by adding new functionalities while still
being able to benefit of the features already present such as the LOD
management, the texture splatting, the alternate data feeders, etc.

Another example is with the libnoise terrain generator: if this
generator is integrated within terrain2, then it would be possible to
use it also when not in 'sphere' mode. If you separate it then it won't
be possible anymore.

Integrating the spherical mode might however be a tricky task, so it's
possible that the creation of a new mesh type might still be the
solution, but this should be avoided if possible.

> I am not sure I would be able to modify the way that the terrain2
> currently works, since all of the samples are done in XZ, and the
> sampling for the simulation will need to include the plane, XZ
> coordinates on that plane and then the XYZ in the crystal space
> environment.

Not sure what you mean here.

The idea was to be able to set a iTerrainSystem in 'sphere' mode instead
of the current 'flat' mode. Some additional parameters would be needed
for the 'sphere' mode, such as the radius of the sphere. The 2D position
of the cells would not be considered anymore as XZ coordinates, but as
spherical ones instead.

When in 'sphere' mode, the vertices of the terrain cells should be
remapped to the portion of a sphere by using the same equations that you
used for defining your sphere in your current work.

The main changes that are needed are a priori:
- the code of the cells that should be able to optionally compute
differently the position of the vertices around a spherical mapping.
- much probably also the terrain collider if we want to enable collision
detection, but this can probably be kept optional.

The 'planet' tool can however still be kept separate from the code of
terrain2. This would be eg a separate plugin that would set up a
terrain2 mesh and manipulate the amount and size of the cells depending
on the position of the camera.

What do you think?

And keep up the good work!


------------------------------------------------------------------------------
Get your SQL database under version control now!
Version control is standard for application code, but databases havent 
caught up. So what steps can you take to put your SQL databases under 
version control? Why should you start doing it? Read more to find out.
http://pubads.g.doubleclick.net/gampad/clk?id=49501711&iu=/4140/ostg.clktrk