-
Notifications
You must be signed in to change notification settings - Fork 0
/
Copy pathfracplanet.htm
677 lines (604 loc) · 27.8 KB
/
fracplanet.htm
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
<html>
<head>
<title>
Fracplanet user manual
</title>
<meta name="keywords" content="Fracplanet, user documentation, user manual"/>
<meta name="description" content="Fracplanet user documentation"/>
<link rel="stylesheet" title="Default styles" type="text/css" href="fracplanet.css" media="screen,print"/>
</head>
<body>
<h1>
Fracplanet user manual
</h1>
<h2>Introduction</h2>
<p>
Fracplanet is an application to generate simple random planets and terrain
with oceans, mountains, icecaps and rivers.
Parameters are specified interactively and the results displayed using OpenGL.
The generated objects can be exported in formats directly usable by POV-Ray or Blender,
or as more generally useful texture images.
</p>
<h2>Command line arguments</h2>
<p>
Some command line arguments (not listed here) are intercepted and interpreted by Qt.
These are pretty much what you'd expect most X11 applications to handle
e.g <code>-geometry <em>X</em>x<em>Y</em></code>.
Fracplanet's own command line arguments are:
</p>
<dl>
<dt>--help, -h</dt>
<dd>
Display a list of recognised arguments.
</dd>
<dt>--verbose, -v</dt>
<dd>
Output information about fracplanet execution (and OpenGL) to stderr.
</dd>
<dt>--display-list, -d</dt>
<dd>
Start up the application with rendering in display list mode by default
(c.f immediate mode).
This is particularly useful when the application is running remotely as the
generated meshes are then only sent to the local OpenGL display hardware once.
</dd>
<dt>--invert-mouse-y, -y</dt>
<dd>
Start application with mouse in non-joystick mode for flight.
</dd>
<dt>--wireframe, -w</dt>
<dd>
Start application with rendering set to wireframe mode.
</dd>
</dl>
<h2>GUI</h2>
<p>
The main part of the fracplanet GUI is a tabbed control.
The terrain generated is shown in a separate window (which disappears while regenerating).
A progress dialog is generally displayed while generating terrain (except during application startup).
</p>
<h3>Create tab</h3>
<p>
Note that none of the parameters adjustable on this tab have any effect on the displayed model until one of
the "Regenerate" buttons is pressed. This tab is further subdivided into sub-tabs
("Terrain", "Snow", "Rivers", "Colours", "Clouds").
</p>
<h4>Terrain</h4>
<p>
This tab is actually even further subdivided
("Basics", "Subdivision" and "Noise" tabs),
but the list below doesn't distinguish.
</p>
<dl>
<dt>Starting geometry: Generate...</dt>
<dd>
A pull-down menu (or "combo-box") selects the initial geometry which will be "fractalized".
Planet creates planets by subdividing an icosahedron.
The other terrain area type create planar terrain areas by subdividing one or more triangles.
Note that the square type doesn't produce very good results because the triangles it uses aren't equilateral.
</dd>
<dt>Base land height</dt>
<dd>
This expresses the initial height of the terrain (relative to the sea level) as a percentage of the vertical maximum perturbation size.
Negative values produce (on average) more ocean than land, positive values produce more land than ocean.
</dd>
<dt>Terrain random seed</dt>
<dd>
Specifies the random number generator seed used when creating terrain.
Regenerating without changing this value will produce the same terrain, allowing the user to play with subdivision levels, colours etc while still retaining the same basic pattern of oceans and continents.
The value is initially set to the system time on application start-up.
</dd>
<dt>Power law</dt>
<dd>
A power law applied to all above-sea-level heights after terrain generation.
(This consists of normalising the height relative to the maximum height in the terrain model and raising it to the power of this number divided by 100).
Values above 100 flatten low terrain, tending to produce smooth plains surrounding spiky mountains.
Values below 100 flatten high terrain, tending to produce smooth highlands surrounded by steep cliffs.
</dd>
<dt>Subdivisions</dt>
<dd>
The number of subdivisions of the initial structure.
Each successive level of subdivision increases the number of triangles by a factor of four, so users should increase this parameter with caution.
This has a major impact on the amount of memory consumed, the frame rate and the responsiveness of the application.
</dd>
<dt>Unperturbed subdivisions</dt>
<dd>
Specifies the number of the subdivisions which will be performed <em>without</em> random perturbation of the vertices.
Lower numbers (0, 1) produce a few large continents.
Higher values produce many small islands.
</dd>
<dt>Vertical perturbation</dt>
<dd>
Specifies the maximum size of vertical perturbations at the first level of subdivision.
The maximum perturbation size is then halved at each subsequent subdivision.
Planets and terrain areas both have a nominal radius of 1.0,
and the number here is divided by 100 so if you specify a vertical variation of 12 you could get mountains which are on the order of 12 percent of the planet's radius high, or larger if subsequent perturbations accumulate upwards at a point (of course suppressing initial large perturbations using the "Unperturbed" parameter will tend to reduce this).
This is of course a ridiculous height for mountains on anything but an asteroid, but using realistic values will just produce very boring looking planets.
</dd>
<dt>Horizontal perturbation</dt>
<dd>
Specifies the maximum size of horizontal perturbations at the first level of subdivision.
The maximum perturbation size is then halved at each subsequent subdivision.
Beware of making this value too large as it can produce overhanging/self-intersecting terrain,
on the other hand small values can be useful for breaking up obvious artifacts of the initial geometry.
</dd>
<dt>Noise terms</dt>
<dd>
Number of terms in a Perlin noise function added to the terrain heights.
Each subsequent term doubles the frequency.
The best way to get an appreciation of the qualitative differences between Perlin noise and
subdivision-perturbation is to reduce "Vertical perturbation" (on the "Subdivision" tab)
to zero and increase the number of noise terms.
</dd>
<dt>Noise frequency<dt>
<dd>
Frequency of 1st noise term.
100 gives a scale on the order of the terrain radius.
Subsequent terms double the frequency (and therefore halve their length scale).
</dd>
<dt>Noise amplitude<dt>
<dd>
Amplitude of 1st noise term, as a percentage of the nominal object radius.
</dd>
<dt>Noise amplitude decay rate<dt>
<dd>
The amplitude of subsequent noise terms decays to this percentage of the amplitude of the previous term.
Fifty percent does the classic fractal thing of scaling perturbation size with length scale.
Increasing it slightly (to e.g sixty percent) has the interesting effect of making rivers meander more
as small-scale variations now have a bigger effect on local gradients than large scale features.
</dd>
</dl>
<h4>Snow</h4>
<dl>
<dt>Snowline at equator</dt>
<dd>
The nominal height of the snowline at the equator of a planet (and everywhere on a flat-based terrain area),
expressed as a percentage of the maximum height of the terrain.
</dd>
<dt>Snowline at pole</dt>
<dd>
The nominal height of the snowline at the poles of a planet (unused for a flat-based terrain area),
expressed as a percentage of the maximum height of the terrain.
</dd>
<dt>Snowline power law</dt>
<dd>
Tweaking this parameter lets you control whether the snowline remains high up and only plunges
downward towards the poles, or whether it only quickly rises near the equator.
Experiment, it has a fairly subtle effect.
</dd>
<dt>Snowline slope suppression</dt>
<dd>
The larger this value is, the harder it is for snow to stick to steep slopes
(you can see this effect for real on any mountain range).
This breaks up the snowline quite nicely, as it otherwise tends to stop at
an artificially uniform height (reduce this parameter to zero to see what I mean).
</dd>
<dt>Snowline glacier effect</dt>
<dd>
If this parameter is positive, rivers tend to form glaciers and you
will see e.g white lines running out of snowy areas, and frozen lakes.
If this parameter is negative rivers find it harder to freeze and
you will see them running through snowy areas and forming un-frozen lakes.
</dd>
</dl>
<h4>Rivers</h4>
<dl>
<dt>Rivers</dt>
<dd>
Specifies the number of rivers to be generated.
Note that rivers starting in the sea are immediately abandoned, but still count against this number
(this is so the relative proportions of land/ocean can be tweaked without affecting the river source density).
Rivers run from vertex to vertex along triangle edges, and are then rendered by blending from the
river vertex colour to the surrounding terrain colour.
This isn't ideal as they aren't very sharply defined.
A previous version of the software flowed rivers from triangle to triangle
which produced nice solid edged rivers (like the oceans are)
but since they weren't flat it wasn't ideal either.
</dd>
<dt>Rivers seed</dt>
<dd>
Random number seed for river generation.
If you change this, but not the perturbation seed, you can get a different river network on the same terrain.
</dd>
<dt>Lake becomes sea</dt>
<dd>
As a river is flowed across a terrain, it will sometimes form a lake as the water
level rises sufficiently to overcome a terrain barrier.
If the lake becomes sufficiently large (greater than the percentage of available surface area specified here)
then it is considered to have become an inland sea and it is no longer necessary for the lake to rise until
an outflow to be discovered (in the real world, surface evaporation replaces the outflow).
Increasing this number may result in larger lakes, but the process of river generation can
take considerably longer.
</dd>
</dl>
<h4>Colours</h4>
<dl>
<dt>Change colours</dt>
<dd>
Click on these buttons to bring up a colour-picking dialog and change the colour for the selected class of terrain.
Each button displays the colour currently selected for that class.
Obvious things you might want to do are to change the shoreline colour to
the same colour as the low level terrain (those beaches are pretty absurdly <em>wide</em> otherwise),
change the orange highlands to a more mountainous grey, or perhaps you preferd
an apocalyptic "lava world" with red rivers and oceans (use emission to make them glow),
black shorelines and ash-grey terrain.
</dd>
<dt>Oceans and rivers emissive</dt>
<dd>
Sets the emission (also called "glow") of lakes and rivers, on a scale of 0-100.
This is mainly to facilitate glowing lava planets.
Note that for terrain generated with emission non-zero,
an alternative OpenGL rendering path must be used which may be a little slower.
</dd>
</dl>
<h4>Clouds</h4>
<p>
The cloud layer, when generated, is a triangle mesh with variable
translucency at each vertex.
Note that it's <em>not</em> a texture in the normal sense.
</p>
<dl>
<dt>Clouds enabled</dt>
<dd>
Select the check box to trigger creation of a cloud layer.
</dd>
<dt>Subdivisions</dt>
<dd>
When left unchecked, the cloud layer will be subdivided
to the same degree as the terrain.
Check the box for explicit control of cloud layer subdivision.
</dd>
<dt>Clouds seed.</dt>
<dd>
Change this to get a different cloud pattern.
</dd>
<dt>Cloud height</dt>
<dd>
Change this to get adjust the height of the clouds above the terrain.
</dd>
</dl>
<h4>Other "Create" tab controls</h4>
<dl>
<dt>Generate</dt>
<dd>
Click this button to regenerate the planet/terrain area <em>without changing the random seeds</em>.
</dd>
<dt>...new rivers seed</dt>
<dd>
Click this button to increment the river generation seed by one and regenerate.
This gets you the same landscape with a different river network.
</dd>
<dt>...new terrain seed</dt>
<dd>
Click this button increment the terrain seed by one and regenerate.
This will get you a completely different terrain.
(The river network will be different too, although it's seed won't have changed, as the rivers flow over the tarrain differently).
</dd>
<dt>...new clouds seed</dt>
<dd>
Click this button increment the clouds seed by one and regenerate.
This will get you a different cloud layer.
</dd>
</dl>
<h3>Render tab</h3>
<p>
Options controlling OpenGL rendering appear on this tab.
Generally none of these makes any difference to the state of the rendered mesh.
However, some of the parameters do affect some export methods; see the individual item descriptions.
</p>
<dl>
<dt>Wireframe checkbox</dt>
<dd>
Selects OpenGL wireframe rendering mode.
</dd>
<dt>Joystick mouse checkbox</dt>
<dd>
This simply affects whether, when in flight mode, pulling the mouse down the screen flies you in that
direction, or whether it's more like an aircraft joystick and pitches you up instead.
</dd>
<dt>Display list</dt>
<dd>
Selects OpenGL display list rendering.
Display list rendering is generally but not always faster
(depends on your OpenGL implementation and graphics drivers).
The main reason display list rendering is not enabled by default is that
the application may pause for a long time while OpenGL processes the
list when it is first rendered; the amount of additional memory
consumed by the display list is also a problem for very large meshes.
</dd>
<dt>Background colour</dt>
<dd>
Colour picking buttons to control the colour used for the viewing area background.
The low altitude colour is also used when exporting a cloud mesh to blender.
</dd>
<dt>Ambient</dt>
<dd>
The amount of ambient illumination.
This is also used when exporting shaded textures.
</dd>
<dt>Illumination azimuth and elevation</dt>
<dd>
Control the illumination direction.
These are also used when exporting shaded textures.
</dd>
<dt>Status</dt>
<dd>
A text field displaying information about the rendered mesh,
and rendering performance (recent average frames-per-second).
</dd>
</dl>
<h3>Save tab</h3>
<p>
Strictly speaking it's Export which is provided, not save, as fracplanet's state cannot be restored (yet).
There are currently three ways of exporting models from fracplanet for other uses: to POV-Ray, to Blender and as textures.
</p>
<h4>POV-Ray</h4>
<dl>
<dt>Add atmosphere</dt>
<dd>
This tick-box causes additional POV-Ray directives to be emitted to render a thin layer of atmosphere.
</dd>
<dt>Sea object</dt>
<dd>
This tick-box causes a single sphere or infinite plane to generated
for the oceans <em>instead</em> of numerous individual triangles.
</dd>
<dt>Base filename</dt>
<dd>
Enter the filename root to be used here.
Two files will be generated, one with ".pov" appended, and one with ".inc" appended.
The .inc file actually contains the object (using POV-Rays's <code>mesh2</code> format),
plus any other objects generated due to the options above.
The .pov just includes the .inc and adds a camera and light source and was primarily intended for testing:
the expectation is that users will generally include the .inc into their own scenes, probably wrapping it
in a POV-Ray <code>union</code> with embedded translate/scale/rotate directives).
</dd>
<dt>Save (POV-Ray)</dt>
<dd>
Click this button to create the POV-Ray files.
This can take quite a long time so a progress bar is used to track the completed percentage.
</dd>
</dl>
<p>
There are additional comments on usage with POV-Ray <a href="#pov">below</a>.
</p>
<h4>Blender</h4>
<dl>
<dt>Per vertex alpha</dt>
<dd>
This check box selects Fracplanet's preferred method for outputting clouds:
by specifying per-vertex alpha components.
However, Blender seems to ignore these so a workround is used and an opaque cloud layer is output
(which should be ok if you fly underneath it and light it sensibly).
You probably don't want to switch this on.
</dd>
<dt>Save (Blender)</dt>
<dd>
Click this button to create a file (a file dialog will appear) which can be imported into Blender.
Note that the save file takes the form of a Python script (traditionally a <code>.py</code> file extension)
which can be executed by Blender to reconstruct the fracplanet model.
</dd>
</dl>
<p>
There are additional comments on usage with Blender <a href="#blender">below</a>.
</p>
<h4>Texture</h4>
<p>
Saving as texture(s) gives you a set of 2D images which can be used by other rendering or modelling applications,
if not immediately then perhaps after a little massaging with the ImageMagick or NetPBM tools.
On saving you'll be prompted for a base <i>filename.ppm</i>. A number of files are then saved:
</p>
<dl>
<dt>filename.ppm</dt>
<dd>
The basic texture.
This will be embedded in black pixels if the terrain isn't square e.g for the hexagonal terrain area.
Planets produce a cylindrically projected latitude-longitude "spheremap".
</dd>
<dt>filename_dem.pgm</dt>
<dd>
The height field (a "DEM" is a Digital Elevation Model).
This is output as a PGM image, with heights from 0.0 to 1.0 scaling to 0 to 65535.
If the DEM contains a value greater than or equal to 256
(highly likely, except for exceptionally flat terrains),
then it will be output as a 16-bit PGM which, while part of the PGM
<a href="http://netpbm.sourceforge.net/doc/pgm.html">"standard"</a>
isn't well supported by many common graphics tools which appear to otherwise offer good PPM support
(e.g The Gimp doesn't like it).
The NetPBM tools are your best bet to convert this to something else (e.g pnmdepth).
Imagemagick's simple "display" tool also handles them well, scaling the maximum value to white.
</dd>
<dt>filename_norm.pgm</dt>
<dd>
The surface normals; XYZ components are mapped to RGB; [-1, 1] is scaled to [0,255].
It is thought this should be useful for bump-mapping renderers (e.g
<a href="http://www.shatters.net/celestia/">Celestia</a>) where the
illusion of surface relief is produced by normal perturbation.
If you intend to use this file, you almost certainly want to disable shading (see below),
as your renderer will compute it later.
</dd>
</dl>
<p>
Other texture save options:
<p>
<dl>
<dt>Shaded texture</dt>
<dd>
Controls whether the texture map includes the effect of lighting.
If you intend to use the information in the _norm.ppm or the _dem.pgm files to subsequently compute lighting,
then you almost certainly do <em>not</em> want the output texture to be shaded.
The amount of ambient lighting is taken from the slider on the render tab.
(Disabling shading is the same effect as setting ambient to 1.0).
The lighting direction is controlled by the render tab's illumination azimuth and elevation controls.
If you want to use the OpenGL window to preview the lighting, you should set zero spin and tilt
by hitting the "reset"button and dragging the tilt to the centre (unfortunately, this
gives you an edge-on view of flat terrain areas so it may be necessary to use the "fly" mode).
</dd>
<dt>Texture height</dt>
<dd>
The number of pixels high the saved texture images are.
The width is implicitly determined by the height.
For flat terrain the width is the same as the height.
For planets the width is twice the height because the height spans [-90,+90] degrees latitude,
and the width spans [-180,180] degrees longitude.
</dd>
</dl>
<p>
There are additional comments exported texture usage <a href="#texture">below</a>.
</p>
<h3>About tab</h3>
<p>
This tab displays information about the software (in particular the version number) and its license.
There is a button to show a dialog containing user documentation,
and another button to display information about the Qt toolkit.
</p>
<h3>Display window</h3>
<p>
The display window, when shown, shows the current
(most recently generated) terrain model.
It is hidden when terrain is being regenerated or saved.
The (badly named) "tilt" slider controls the latitude of the camera (when viewing a sphere-based object),
and the elevation (as in azimuth-elevation) of the camera when viewing a planar based terrain area.
Note that in the latter case the bottom half of the slider places the camera below base ground level/sea level,
which results in little being seen due to back-face culling.
The "spin rate" controls the rate at which the object is rotated.
The display window update rate is clamped to 60Hz, although this will typically
only be reached at the lower levels of subdivision.
</p>
<p>
Hitting the "Fly" button puts you into free-flight mode.
Pitch and yaw are controlled by the mouse position relative to the window centre
(if the pitch control feels backwards, invert mouse-Y behaviour on the render tab).
Roll is controlled by left/right mouse buttons, or the keyboard left/right arrow keys.
Speed is controlled by the mouse wheel or the keyboard up/down arrow keys.
Hit Esc to return to the normal viewing mode.
</p>
<h2>Fracplanet exports: usage notes</h2>
<a name="pov"><h3>POV-Ray</h3></a>
<p>
To ray-trace a saved terrain (saved as terrain.pov and terrain.inc, say) do:<br/>
<code>povray -Q9 -geometry 768x576 terrain.pov</code><br/>
Expect to get MANY "determinant too small" messages,
especially when using high degrees of subdivision.
It used to take POV-Ray a LOT longer to read large models than
to render them, but it seems to load much faster these days.
</p>
<p>
Note that clouds, if generated, are output using POV-Ray's <code>double_illuminate</code>
and <code>no_shadow</code> declarations.
<code>double_illuminate</code> means that both sides of clouds are the same colour
(rather than the underside being black).
<code>no_shadow</code> means that the clouds cast no shadow on the ground
(where the clouds are solid, the shadows are completely black, which looks more unnatural than no shadows).
If desired, the declarations can be found at the end of the saved .inc file and simply edited out.
</p>
<p>
(The author currently uses POV-Ray 3.6).
</p>
<a name="blender"><h3>Blender</h3></a>
<p>
The easiest way to load mesh saved for blender is with blender's <code>-P <filename.py></code>
command line argument on startup.
Note that you'll have to remove blender's default initially created object to see much of the fracplanet object.
Also, its shading won't look much like it did in fracplanet until you change blender's viewport shading mode to
something better than the "solid" default.
</p>
<p>
Blender consumes an alarming amount of memory.
Even loading a planet generated with fracplanet's default five levels of subdivision
consumes a quarter of a gigabyte of RAM.
It would probably help if fracplanet made some effort to optimise its meshes,
and/or made use of textures rather than trying to do everything using geometry, but it doesn't yet.
</p>
<p>
Blender's per-vertex-colours capability seems to ignore the alpha component of per-vertex colours,
with the result that the cloud layer is rendered as a solid opaque colour.
<em>If anyone has a solution to this it would be gratefully received.</em>
Fracplanet's workround is to output an opaque surface with the blending
(with the "low altitude" colour from the render tab controls) already done.
The "per-vertex alpha" checkbox switches to the preferred behaviour in case it ever gets fixed.
</p>
<p>
Each mesh is output with 2 materials.
The clouds just use material 0.
For the terrain, material 0 is for land facets, material 1 for the sea.
This may be useful for users wanting to give them different shader properties.
</p>
<p>
In Blender, the terrain mesh is named "fracplanet.terrain".
There will also be a "fracplanet.cloud" if clouds were enabled.
</p>
<p>
Emissive terrain isn't supported.
</p>
<p>
If you want to manipulate the terrain, and know a bit of Python,
an easy way might be to edit the <code>.py</code> file;
at the start there are two functions defined:
<code>v</code> called to create each vertex
and <code>f</code> called to create each face.
</p>
<p>
(The author currently uses Blender 2.46).
</p>
<a name="texture"><h3>Texture Maps</h3></a>
<p>
It is hoped that the texture export option will be of use to those building planets for
<a href="http://www.shatters.net/celestia/">Celestia</a>.
(The author hasn't tried it himself yet; at time of writing Celestia
is waiting to make it's way from Debian Unstable to Testing).
Celestia's texture formats are well documented at the
<a href="http://www.celestiamotherlode.net/catalog/documentation.html">Celestia Motherlode</a>,
in particular by the <a href="http://www.lns.cornell.edu/~seb/celestia/textures.html">Virtual Surface Textures</a>
document.
The main issues for anyone doing this would seem to be the need to reduce the height map from 16 to 8 bit
(easily changed by pnmdepth) and the possiblity that fracplanet's normal map (if used, alternative Celestia
can compute normal maps from the height map) needs it's components exchanging or reflecting.
Celestia can also take a specular map, generally used to indicating the presence of reflective water (or snow);
fracplanet doesn't output this (yet) but it should be possible to fake something by processing the height or texture map.
</p>
<p>
As a simple demonstration of how to use a saved planet texture, here's how to use it as a spheremap in POV-Ray.
Save an unshaded <code>spheremap.ppm</code> from fracplanet, and do:<br/>
<code>
convert spheremap.ppm spheremap.png<br/>
convert -depth 8 spheremap_dem.pgm spheremap_dem.png<br/>
cat <<EOF > spheremap.pov<br/>
camera {perspective location <0,1,-4.5> look_at <0,0,0> angle 45}<br/>
light_source {<100,100,-100> color rgb<1,1,1>}<br/>
sphere<br/>
{<br/>
<0,0,0>,1<br/>
pigment { image_map {png "spheremap.png" map_type 1} }<br/>
normal { bump_map {png "spheremap_dem.png" map_type 1 bump_size 20.0} }<br/>
rotate <0,clock*360,0.0><br/>
}<br/>
EOF<br/>
povray spheremap.pov +KFI1 +KFF100 +W640 +H480 +Of.png<br/>
animate f???.png<br/>
</code>
</p>
<p>
<code>convert</code> is one of the ImageMagick utilities.
You could omit the line beginning "normal" but you will get a rather flat looking planet.
The factor of 20.0 at the end of the line is a rather arbitrary parameter.
Raise or lower it to adjust the apparent roughness of the planet.
</p>
<h2>License</h2>
<p>
This program is free software; you can redistribute it and/or
modify it under the terms of the GNU General Public License
as published by the Free Software Foundation; either version 2
of the License, or (at your option) any later version.
This program is distributed in the hope that it will be useful,
but WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
GNU General Public License for more details.
You should have received a copy of the GNU General Public License
along with this program; if not, write to the Free Software
Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA.
</p>
<p>
The full license can be also viewed on fracplanet's "About" tab.
</p>
</body>