passagemath-tachyon 10.5.42__cp312-cp312-macosx_14_0_arm64.whl
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- passagemath_tachyon-10.5.42.dist-info/METADATA +97 -0
- passagemath_tachyon-10.5.42.dist-info/RECORD +13 -0
- passagemath_tachyon-10.5.42.dist-info/WHEEL +6 -0
- passagemath_tachyon-10.5.42.dist-info/top_level.txt +2 -0
- passagemath_tachyon.dylibs/libpng16.16.dylib +0 -0
- sage/all__sagemath_tachyon.py +6 -0
- sage/ext_data/doctest/invalid/syntax_error.tachyon +91 -0
- sage/interfaces/all__sagemath_tachyon.py +1 -0
- sage/interfaces/tachyon.py +900 -0
- sage/libs/all__sagemath_tachyon.py +7 -0
- sage/libs/tachyon.cpython-312-darwin.so +0 -0
- sage/libs/tachyon.pyx +1 -0
- sage_wheels/bin/tachyon +0 -0
@@ -0,0 +1,97 @@
|
|
1
|
+
Metadata-Version: 2.4
|
2
|
+
Name: passagemath-tachyon
|
3
|
+
Version: 10.5.42
|
4
|
+
Summary: passagemath: Computations on monomial ideals with Frobby
|
5
|
+
Author-email: The Sage Developers <sage-support@googlegroups.com>
|
6
|
+
Maintainer: Matthias Köppe, passagemath contributors
|
7
|
+
License-Expression: GPL-2.0-or-later
|
8
|
+
Project-URL: release notes, https://github.com/passagemath/passagemath/releases
|
9
|
+
Project-URL: repo (upstream), https://github.com/sagemath/sage
|
10
|
+
Project-URL: repo, https://github.com/passagemath/passagemath
|
11
|
+
Project-URL: documentation, https://doc.sagemath.org
|
12
|
+
Project-URL: homepage (upstream), https://www.sagemath.org
|
13
|
+
Project-URL: discourse, https://passagemath.discourse.group
|
14
|
+
Project-URL: tracker (upstream), https://github.com/sagemath/sage/issues
|
15
|
+
Project-URL: tracker, https://github.com/passagemath/passagemath/issues
|
16
|
+
Classifier: Development Status :: 6 - Mature
|
17
|
+
Classifier: Intended Audience :: Education
|
18
|
+
Classifier: Intended Audience :: Science/Research
|
19
|
+
Classifier: Operating System :: POSIX
|
20
|
+
Classifier: Operating System :: MacOS :: MacOS X
|
21
|
+
Classifier: Programming Language :: Python :: 3 :: Only
|
22
|
+
Classifier: Programming Language :: Python :: 3.9
|
23
|
+
Classifier: Programming Language :: Python :: 3.10
|
24
|
+
Classifier: Programming Language :: Python :: 3.11
|
25
|
+
Classifier: Programming Language :: Python :: 3.12
|
26
|
+
Classifier: Programming Language :: Python :: 3.13
|
27
|
+
Classifier: Programming Language :: Python :: Implementation :: CPython
|
28
|
+
Classifier: Topic :: Scientific/Engineering :: Mathematics
|
29
|
+
Requires-Python: <3.14,>=3.9
|
30
|
+
Description-Content-Type: text/x-rst
|
31
|
+
Requires-Dist: cysignals!=1.12.0,>=1.11.2
|
32
|
+
Requires-Dist: passagemath-environment~=10.5.42.0
|
33
|
+
Requires-Dist: passagemath-objects~=10.5.42.0
|
34
|
+
Provides-Extra: test
|
35
|
+
Requires-Dist: passagemath-repl; extra == "test"
|
36
|
+
|
37
|
+
========================================================
|
38
|
+
passagemath: Interface to the ray tracing system tachyon
|
39
|
+
========================================================
|
40
|
+
|
41
|
+
`passagemath <https://github.com/passagemath/passagemath>`__ is open
|
42
|
+
source mathematical software in Python, released under the GNU General
|
43
|
+
Public Licence GPLv2+.
|
44
|
+
|
45
|
+
It is a fork of `SageMath <https://www.sagemath.org/>`__, which has been
|
46
|
+
developed 2005-2025 under the motto “Creating a Viable Open Source
|
47
|
+
Alternative to Magma, Maple, Mathematica, and MATLAB”.
|
48
|
+
|
49
|
+
The passagemath fork was created in October 2024 with the following
|
50
|
+
goals:
|
51
|
+
|
52
|
+
- providing modularized installation with pip, thus completing a `major
|
53
|
+
project started in 2020 in the Sage
|
54
|
+
codebase <https://github.com/sagemath/sage/issues/29705>`__,
|
55
|
+
- establishing first-class membership in the scientific Python
|
56
|
+
ecosystem,
|
57
|
+
- giving `clear attribution of upstream
|
58
|
+
projects <https://groups.google.com/g/sage-devel/c/6HO1HEtL1Fs/m/G002rPGpAAAJ>`__,
|
59
|
+
- providing independently usable Python interfaces to upstream
|
60
|
+
libraries,
|
61
|
+
- providing `platform portability and integration testing
|
62
|
+
services <https://github.com/passagemath/passagemath/issues/704>`__
|
63
|
+
to upstream projects,
|
64
|
+
- inviting collaborations with upstream projects,
|
65
|
+
- `building a professional, respectful, inclusive
|
66
|
+
community <https://groups.google.com/g/sage-devel/c/xBzaINHWwUQ>`__,
|
67
|
+
- developing a port to `Pyodide <https://pyodide.org/en/stable/>`__ for
|
68
|
+
serverless deployment with Javascript,
|
69
|
+
- developing a native Windows port.
|
70
|
+
|
71
|
+
`Full documentation <https://doc.sagemath.org/html/en/index.html>`__ is
|
72
|
+
available online.
|
73
|
+
|
74
|
+
passagemath attempts to support all major Linux distributions and recent versions of
|
75
|
+
macOS. Use on Windows currently requires the use of Windows Subsystem for Linux or
|
76
|
+
virtualization.
|
77
|
+
|
78
|
+
Complete sets of binary wheels are provided on PyPI for Python versions 3.9.x-3.12.x.
|
79
|
+
Python 3.13.x is also supported, but some third-party packages are still missing wheels,
|
80
|
+
so compilation from source is triggered for those.
|
81
|
+
|
82
|
+
|
83
|
+
About this pip-installable distribution package
|
84
|
+
-----------------------------------------------
|
85
|
+
|
86
|
+
This pip-installable source distribution ``passagemath-tachyon`` provides an interface to
|
87
|
+
the ray tracing system [tachyon](http://jedi.ks.uiuc.edu/~johns/raytracer/).
|
88
|
+
|
89
|
+
|
90
|
+
Examples
|
91
|
+
--------
|
92
|
+
|
93
|
+
A quick way to try it out interactively::
|
94
|
+
|
95
|
+
$ pipx run --pip-args="--prefer-binary" --spec "passagemath-tachyon[test]" ipython
|
96
|
+
|
97
|
+
In [1]: from sage.all__sagemath_tachyon import *
|
@@ -0,0 +1,13 @@
|
|
1
|
+
passagemath_tachyon-10.5.42.dist-info/RECORD,,
|
2
|
+
passagemath_tachyon-10.5.42.dist-info/WHEEL,sha256=VrhWOWJdu4wN9IKhAFBqWPMo6yuww-SFg9GbWc0qbmI,136
|
3
|
+
passagemath_tachyon-10.5.42.dist-info/top_level.txt,sha256=Kmzulf9WsphADFQuqgvdy5mvTLDj_V2zkFHU2s3UXos,6
|
4
|
+
passagemath_tachyon-10.5.42.dist-info/METADATA,sha256=mpMnjweEdSTG7TwPY8ndtsTVCIKj0ErGDiPayPnsH6Y,4277
|
5
|
+
sage_wheels/bin/tachyon,sha256=7Kpo2316tBho76aVXM4_4dfRsF6Epz6Dt71ZDgjXKOY,197776
|
6
|
+
passagemath_tachyon.dylibs/libpng16.16.dylib,sha256=h32Ytj314szPtElmoOjZwO1CW-yyawC7A_dc9rcpnYY,285104
|
7
|
+
sage/all__sagemath_tachyon.py,sha256=11IF4LhzQgW9pLP4qg2orAUzp4za7tgeXOx4HY0-3tM,187
|
8
|
+
sage/ext_data/doctest/invalid/syntax_error.tachyon,sha256=T63BiiHK2Isz3zUr9Kh1AiVl5yymejYP5CjF5OH7B-I,2413
|
9
|
+
sage/libs/tachyon.cpython-312-darwin.so,sha256=X_Vj59nA2pHawj_kTFqoQTSWu4eIBqb77xFfaiO6qjA,55456
|
10
|
+
sage/libs/tachyon.pyx,sha256=0ZcxN1iXbvcw2ngvTJbySrEstyQcX51WoF870h-F8qA,46
|
11
|
+
sage/libs/all__sagemath_tachyon.py,sha256=kbiu3HPTxZvqYjSkrBd4EOZmiPs1u4C7a3bVUwVQE9g,164
|
12
|
+
sage/interfaces/tachyon.py,sha256=UXKGzfLUU1lnpTkIVh_Y5el9O0sI4A8gx_7ttfGZh8s,32719
|
13
|
+
sage/interfaces/all__sagemath_tachyon.py,sha256=0ZcxN1iXbvcw2ngvTJbySrEstyQcX51WoF870h-F8qA,46
|
Binary file
|
@@ -0,0 +1,91 @@
|
|
1
|
+
# This is NOT a valid tachyon input file
|
2
|
+
#
|
3
|
+
# We use it to test that tachyon errors are diagnosed in the Sage
|
4
|
+
# interface to tachyon.
|
5
|
+
|
6
|
+
|
7
|
+
begin_scene
|
8
|
+
resolution 400 400
|
9
|
+
|
10
|
+
camera
|
11
|
+
zoom 1.0
|
12
|
+
aspectratio 1.0
|
13
|
+
antialiasing 8
|
14
|
+
raydepth 8
|
15
|
+
center 2.3 2.4 2.0
|
16
|
+
viewdir -2.3 -2.4 -2.0
|
17
|
+
updir 0.0 0.0 1.0
|
18
|
+
end_camera
|
19
|
+
|
20
|
+
|
21
|
+
light center 4.0 3.0 2.0
|
22
|
+
rad 0.2
|
23
|
+
color 1.0 1.0 1.0
|
24
|
+
|
25
|
+
plane
|
26
|
+
center -2000 -1000 -500
|
27
|
+
normal 2.3 2.4 2.0
|
28
|
+
TEXTURE
|
29
|
+
AMBIENT 1.0 DIFFUSE 1.0 SPECULAR 1.0 OPACITY 1.0
|
30
|
+
COLOR 1.0 1.0 1.0
|
31
|
+
TEXFUNC 0
|
32
|
+
|
33
|
+
Texdef texture239
|
34
|
+
Ambient 0.333333333333 Diffuse 0.666666666667 Specular 0.0 Opacity 1
|
35
|
+
Color 0.0 0.0 0.0
|
36
|
+
TexFunc 0
|
37
|
+
Texdef texture240
|
38
|
+
Ambient 0.333333333333 Diffuse 0.666666666667 Specular 0.0 Opacity 1/2
|
39
|
+
Color 0.0 0.0 0.0
|
40
|
+
TexFunc 0
|
41
|
+
|
42
|
+
TRI V0 0.5 -0.5 0.5 V1 -0.5 -0.5 0.5 V2 -0.5 0.5 0.5
|
43
|
+
texture239
|
44
|
+
TRI V0 0.5 -0.5 0.5 V1 -0.5 0.5 0.5 V2 0.5 0.5 0.5
|
45
|
+
texture239
|
46
|
+
TRI V0 0.5 -0.5 0.5 V1 0.5 -0.5 -0.5 V2 -0.5 -0.5 -0.5
|
47
|
+
texture239
|
48
|
+
TRI V0 0.5 -0.5 0.5 V1 -0.5 -0.5 -0.5 V2 -0.5 -0.5 0.5
|
49
|
+
texture239
|
50
|
+
TRI V0 0.5 -0.5 0.5 V1 0.5 0.5 0.5 V2 0.5 0.5 -0.5
|
51
|
+
texture239
|
52
|
+
TRI V0 0.5 -0.5 0.5 V1 0.5 0.5 -0.5 V2 0.5 -0.5 -0.5
|
53
|
+
texture239
|
54
|
+
TRI V0 -0.5 -0.5 -0.5 V1 0.5 -0.5 -0.5 V2 0.5 0.5 -0.5
|
55
|
+
texture239
|
56
|
+
TRI V0 -0.5 -0.5 -0.5 V1 0.5 0.5 -0.5 V2 -0.5 0.5 -0.5
|
57
|
+
texture239
|
58
|
+
TRI V0 0.5 0.5 -0.5 V1 0.5 0.5 0.5 V2 -0.5 0.5 0.5
|
59
|
+
texture239
|
60
|
+
TRI V0 0.5 0.5 -0.5 V1 -0.5 0.5 0.5 V2 -0.5 0.5 -0.5
|
61
|
+
texture239
|
62
|
+
TRI V0 -0.5 0.5 0.5 V1 -0.5 -0.5 0.5 V2 -0.5 -0.5 -0.5
|
63
|
+
texture239
|
64
|
+
TRI V0 -0.5 0.5 0.5 V1 -0.5 -0.5 -0.5 V2 -0.5 0.5 -0.5
|
65
|
+
texture239
|
66
|
+
TRI V0 3 -0.5 0.5 V1 2 -0.5 0.5 V2 2 0.5 0.5
|
67
|
+
texture240
|
68
|
+
TRI V0 3 -0.5 0.5 V1 2 0.5 0.5 V2 3 0.5 0.5
|
69
|
+
texture240
|
70
|
+
TRI V0 3 -0.5 0.5 V1 3 -0.5 -0.5 V2 2 -0.5 -0.5
|
71
|
+
texture240
|
72
|
+
TRI V0 3 -0.5 0.5 V1 2 -0.5 -0.5 V2 2 -0.5 0.5
|
73
|
+
texture240
|
74
|
+
TRI V0 3 -0.5 0.5 V1 3 0.5 0.5 V2 3 0.5 -0.5
|
75
|
+
texture240
|
76
|
+
TRI V0 3 -0.5 0.5 V1 3 0.5 -0.5 V2 3 -0.5 -0.5
|
77
|
+
texture240
|
78
|
+
TRI V0 2 -0.5 -0.5 V1 3 -0.5 -0.5 V2 3 0.5 -0.5
|
79
|
+
texture240
|
80
|
+
TRI V0 2 -0.5 -0.5 V1 3 0.5 -0.5 V2 2 0.5 -0.5
|
81
|
+
texture240
|
82
|
+
TRI V0 3 0.5 -0.5 V1 3 0.5 0.5 V2 2 0.5 0.5
|
83
|
+
texture240
|
84
|
+
TRI V0 3 0.5 -0.5 V1 2 0.5 0.5 V2 2 0.5 -0.5
|
85
|
+
texture240
|
86
|
+
TRI V0 2 0.5 0.5 V1 2 -0.5 0.5 V2 2 -0.5 -0.5
|
87
|
+
texture240
|
88
|
+
TRI V0 2 0.5 0.5 V1 2 -0.5 -0.5 V2 2 0.5 -0.5
|
89
|
+
texture240
|
90
|
+
|
91
|
+
end_scene
|
@@ -0,0 +1 @@
|
|
1
|
+
# sage_setup: distribution = sagemath-tachyon
|
@@ -0,0 +1,900 @@
|
|
1
|
+
# sage_setup: distribution = sagemath-tachyon
|
2
|
+
r"""
|
3
|
+
The Tachyon Ray Tracer
|
4
|
+
|
5
|
+
AUTHOR:
|
6
|
+
|
7
|
+
- John E. Stone
|
8
|
+
|
9
|
+
This documentation, which was written by John Stone, describes how to
|
10
|
+
create scene files.
|
11
|
+
|
12
|
+
At the present time, scene description files are very simple. The parser
|
13
|
+
can’t handle multiple file scene descriptions, although they may be
|
14
|
+
added in the future. Most of the objects and their scene description are
|
15
|
+
closely related to the RAY API. *(See the API docs for additional info.)*
|
16
|
+
|
17
|
+
Basic Scene Requirements
|
18
|
+
------------------------
|
19
|
+
|
20
|
+
Unlike some other ray tracers out there, RAY requires that you specify
|
21
|
+
most of the scene parameters in the scene description file itself. If
|
22
|
+
users would rather specify some of these parameters at the command line,
|
23
|
+
then I may add that feature in the future. A scene description file
|
24
|
+
contains keywords, and values associated or grouped with a keyword. All
|
25
|
+
keywords can be in caps, lower case, or mixed case for the convenience
|
26
|
+
of the user. File names and texture names are normally case-sensitive,
|
27
|
+
although the behavior for file names is operating system-dependent. All
|
28
|
+
values are either character strings, or floating point numbers. In some
|
29
|
+
cases, the presence of one keyword will require additional keyword /
|
30
|
+
value pairs.
|
31
|
+
|
32
|
+
At the moment there are several keywords with values, that must appear
|
33
|
+
in every scene description file. Every scene description file must begin
|
34
|
+
with the ``BEGIN_SCENE`` keyword, and end with the ``END_SCENE``
|
35
|
+
keyword. All definitions and declarations of any kind must be inside the
|
36
|
+
``BEGIN_SCENE``, ``END_SCENE`` pair. The ``RESOLUTION`` keyword is
|
37
|
+
followed by an x resolution and a y resolution in terms of pixels on
|
38
|
+
each axis. There are currently no limits placed on the resolution of an
|
39
|
+
output image other than the computer’s available memory and reasonable
|
40
|
+
execution time. An example of a simple scene description skeleton is
|
41
|
+
show below:
|
42
|
+
|
43
|
+
::
|
44
|
+
|
45
|
+
BEGIN_SCENE
|
46
|
+
RESOLUTION 1024 1024
|
47
|
+
...
|
48
|
+
... Camera definition..
|
49
|
+
...
|
50
|
+
... Other objects, etc..
|
51
|
+
...
|
52
|
+
|
53
|
+
END_SCENE
|
54
|
+
|
55
|
+
Camera and viewing parameters
|
56
|
+
-----------------------------
|
57
|
+
|
58
|
+
One of the most important parts of any scene, is the camera position and
|
59
|
+
orientation. Having a good angle on a scene can make the difference
|
60
|
+
between an average looking scene and a strikingly interesting one. There
|
61
|
+
may be multiple camera definitions in a scene file, but the last camera
|
62
|
+
definition overrides all previous definitions. There are several
|
63
|
+
parameters that control the camera in , ``PROJECTION``, ``ZOOM``,
|
64
|
+
``ASPECTRATIO``, ``ANTIALIASING``, ``CENTER``, ``RAYDEPTH``,
|
65
|
+
``VIEWDIR``, and ``UPDIR``.
|
66
|
+
|
67
|
+
The first and last keywords required in the definition of a camera are
|
68
|
+
the ``CAMERA`` and ``END_CAMERA`` keywords. The ``PROJECTION`` keyword
|
69
|
+
is optional, the remaining camera keywords are required, and must be
|
70
|
+
written in the sequence they are listed in the examples in this section.
|
71
|
+
|
72
|
+
Camera projection modes
|
73
|
+
~~~~~~~~~~~~~~~~~~~~~~~
|
74
|
+
|
75
|
+
The ``PROJECTION`` keyword must be followed by one of the supported
|
76
|
+
camera projection mode identifiers ``PERSPECTIVE``, ``PERSPECTIVE_DOF``,
|
77
|
+
``ORTHOGRAPHIC``, or ``FISHEYE``. The ``FISHEYE`` projection mode
|
78
|
+
requires two extra parameters ``FOCALLENGTH`` and ``APERTURE`` which
|
79
|
+
precede the regular camera options.
|
80
|
+
|
81
|
+
::
|
82
|
+
|
83
|
+
Camera
|
84
|
+
projection perspective_dof
|
85
|
+
focallength 0.75
|
86
|
+
aperture 0.02
|
87
|
+
Zoom 0.666667
|
88
|
+
Aspectratio 1.000000
|
89
|
+
Antialiasing 128
|
90
|
+
Raydepth 30
|
91
|
+
Center 0.000000 0.000000 -2.000000
|
92
|
+
Viewdir -0.000000 -0.000000 2.000000
|
93
|
+
Updir 0.000000 1.000000 -0.000000
|
94
|
+
End_Camera
|
95
|
+
|
96
|
+
Common camera parameters
|
97
|
+
~~~~~~~~~~~~~~~~~~~~~~~~
|
98
|
+
|
99
|
+
The ``ZOOM`` parameter controls the camera in a way similar to a
|
100
|
+
telephoto lens on a 35mm camera. A zoom value of 1.0 is standard, with a
|
101
|
+
90 degree field of view. By changing the zoom factor to 2.0, the
|
102
|
+
relative size of any feature in the frame is twice as big, while the
|
103
|
+
field of view is decreased slightly. The zoom effect is implemented as a
|
104
|
+
scaling factor on the height and width of the image plane relative to
|
105
|
+
the world.
|
106
|
+
|
107
|
+
The ``ASPECTRATIO`` parameter controls the aspect ratio of the resulting
|
108
|
+
image. By using the aspect ratio parameter, one can produce images which
|
109
|
+
look correct on any screen. Aspect ratio alters the relative width of
|
110
|
+
the image plane, while keeping the height of the image plane constant.
|
111
|
+
In general, most workstation displays have an aspect ratio of 1.0. To
|
112
|
+
see what aspect ratio your display has, you can render a simple sphere,
|
113
|
+
at a resolution of 512x512 and measure the ratio of its width to its
|
114
|
+
height.
|
115
|
+
|
116
|
+
The ``ANTIALIASING`` parameter controls the maximum level of
|
117
|
+
supersampling used to obtain higher image quality. The parameter given
|
118
|
+
sets the number of additional rays to trace per-pixel to attain higher
|
119
|
+
image quality.
|
120
|
+
|
121
|
+
The ``RAYDEPTH`` parameter tells RAY what the maximum level of
|
122
|
+
reflections, refraction, or in general the maximum recursion depth to
|
123
|
+
trace rays to. A value between 4 and 12 is usually good. A value of 1
|
124
|
+
will disable rendering of reflective or transmissive objects (they’ll be
|
125
|
+
black).
|
126
|
+
|
127
|
+
The remaining three camera parameters are the most important, because
|
128
|
+
they define the coordinate system of the camera, and its position in the
|
129
|
+
scene. The ``CENTER`` parameter is an X, Y, Z coordinate defining the
|
130
|
+
center of the camera *(also known as the Center of Projection)*. Once
|
131
|
+
you have determined where the camera will be placed in the scene, you
|
132
|
+
need to tell RAY what the camera should be looking at. The ``VIEWDIR``
|
133
|
+
parameter is a vector indicating the direction the camera is facing. It
|
134
|
+
may be useful for me to add a "Look At" type keyword in the future to
|
135
|
+
make camera aiming easier. If people want or need the "Look At" style
|
136
|
+
camera, let me know. The last parameter needed to completely define a
|
137
|
+
camera is the "up" direction. The ``UPDIR`` parameter is a vector which
|
138
|
+
points in the direction of the "sky". I wrote the camera so that
|
139
|
+
``VIEWDIR`` and ``UPDIR`` don’t have to be perpendicular, and there
|
140
|
+
shouldn’t be a need for a "right" vector although some other ray tracers
|
141
|
+
require it. Here’s a snippet of a camera definition:
|
142
|
+
|
143
|
+
::
|
144
|
+
|
145
|
+
CAMERA
|
146
|
+
ZOOM 1.0
|
147
|
+
ASPECTRATIO 1.0
|
148
|
+
ANTIALIASING 0
|
149
|
+
RAYDEPTH 12
|
150
|
+
CENTER 0.0 0.0 2.0
|
151
|
+
VIEWDIR 0 0 -1
|
152
|
+
UPDIR 0 1 0
|
153
|
+
END_CAMERA
|
154
|
+
|
155
|
+
Viewing frustum
|
156
|
+
~~~~~~~~~~~~~~~
|
157
|
+
|
158
|
+
An optional ``FRUSTUM`` parameter provides a means for rendering
|
159
|
+
sub-images in a larger frame, and correct stereoscopic images. The
|
160
|
+
``FRUSTUM`` keyword must be followed by four floating parameters, which
|
161
|
+
indicate the top, bottom, left and right coordinates of the image plane
|
162
|
+
in eye coordinates. When the projection mode is set to ``FISHEYE``, the
|
163
|
+
frustum parameters correspond to spherical coordinates specified in
|
164
|
+
radians.
|
165
|
+
|
166
|
+
::
|
167
|
+
|
168
|
+
CAMERA
|
169
|
+
ZOOM 1.0
|
170
|
+
ASPECTRATIO 1.0
|
171
|
+
ANTIALIASING 0
|
172
|
+
RAYDEPTH 4
|
173
|
+
CENTER 0.0 0.0 -6.0
|
174
|
+
VIEWDIR 0.0 0.0 1.0
|
175
|
+
UPDIR 0.0 1.0 0.0
|
176
|
+
FRUSTUM -0.5 0.5 -0.5 0.5
|
177
|
+
END_CAMERA
|
178
|
+
|
179
|
+
Including Files
|
180
|
+
---------------
|
181
|
+
|
182
|
+
The ``INCLUDE`` keyword is used anywhere after the camera description,
|
183
|
+
and is immediately followed by a valid filename, for a file containing
|
184
|
+
additional scene description information. The included file is opened,
|
185
|
+
and processing continues as if it were part of the current file, until
|
186
|
+
the end of the included file is reached. Parsing of the current file
|
187
|
+
continues from where it left off prior to the included file.
|
188
|
+
|
189
|
+
Scene File Comments
|
190
|
+
-------------------
|
191
|
+
|
192
|
+
The ``#`` keyword is used anywhere after the camera
|
193
|
+
description, and will cause RAY to ignore all characters from the
|
194
|
+
``#`` to the end of the input line. The ``#``
|
195
|
+
character must be surrounded by whitespace in order to be recognized. A
|
196
|
+
sequence such as ``###`` will not be recognized as a comment.
|
197
|
+
|
198
|
+
Lights
|
199
|
+
------
|
200
|
+
|
201
|
+
The most frequently used type of lights provided by RAY are positional
|
202
|
+
point light sources. The lights are actually small spheres, which are
|
203
|
+
visible. A point light is composed of three pieces of information, a
|
204
|
+
center, a radius (since its a sphere), and a color. To define a light,
|
205
|
+
simply write the ``LIGHT`` keyword, followed by its ``CENTER`` (a X, Y,
|
206
|
+
Z coordinate), its ``RAD`` (radius, a scalar), and its ``COLOR`` (a Red
|
207
|
+
Green Blue triple). The radius parameter will accept any value of 0.0 or
|
208
|
+
greater. Lights of radius 0.0 will not be directly visible in the
|
209
|
+
rendered scene, but contribute light to the scene normally. For a light,
|
210
|
+
the color values range from 0.0 to 1.0, any values outside this range
|
211
|
+
may yield unpredictable results. A simple light definition looks like
|
212
|
+
this:
|
213
|
+
|
214
|
+
::
|
215
|
+
|
216
|
+
LIGHT CENTER 4.0 3.0 2.0
|
217
|
+
RAD 0.2
|
218
|
+
COLOR 0.5 0.5 0.5
|
219
|
+
|
220
|
+
This light would be gray colored if seen directly, and would be 50%
|
221
|
+
intensity in each RGB color component.
|
222
|
+
|
223
|
+
RAY supports simple directional lighting, commonly used in CAD and
|
224
|
+
scientific visualization programs for its performance advantages over
|
225
|
+
positional lights. Directional lights cannot be seen directly in scenes
|
226
|
+
rendered by , only their illumination contributes to the final image.
|
227
|
+
|
228
|
+
::
|
229
|
+
|
230
|
+
DIRECTIONAL_LIGHT
|
231
|
+
DIRECTION 0.0 -1.0 0.0
|
232
|
+
COLOR 1.0 0.0 0.0
|
233
|
+
|
234
|
+
RAY supports spotlights, which are described very similarly to a point
|
235
|
+
light, but they are attenuated by angle from the direction vector, based
|
236
|
+
on a “falloff start” angle and “falloff end”angle. Between the starting
|
237
|
+
and ending angles, the illumination is attenuated linearly. The syntax
|
238
|
+
for a spotlight description in a scene file is as follows.
|
239
|
+
|
240
|
+
::
|
241
|
+
|
242
|
+
SPOTLIGHT
|
243
|
+
CENTER 0.0 3.0 17.0
|
244
|
+
RAD 0.2
|
245
|
+
DIRECTION 0.0 -1.0 0.0
|
246
|
+
FALLOFF_START 20.0
|
247
|
+
FALLOFF_END 45.0
|
248
|
+
COLOR 1.0 0.0 0.0
|
249
|
+
|
250
|
+
The lighting system implemented by RAY provides various levels of
|
251
|
+
distance-based lighting attenuation. By default, a light is not
|
252
|
+
attenuated by distance. If the *attenuation* keywords is present
|
253
|
+
immediately prior to the light’s color, RAY will accept coefficients
|
254
|
+
which are used to calculate distance-based attenuation, which is applied
|
255
|
+
the light by multiplying with the resulting value. The attenuation
|
256
|
+
factor is calculated from the equation
|
257
|
+
|
258
|
+
.. math:: 1/(K_c + K_l d + k_q d^2)
|
259
|
+
|
260
|
+
This attenuation equation should be familiar to some as it is the same
|
261
|
+
lighting attenuation equation used by OpenGL. The constant, linear, and
|
262
|
+
quadratic terms are specified in a scene file as shown in the following
|
263
|
+
example.
|
264
|
+
|
265
|
+
::
|
266
|
+
|
267
|
+
LIGHT
|
268
|
+
CENTER -5.0 0.0 10.0
|
269
|
+
RAD 1.0
|
270
|
+
ATTENUATION CONSTANT 1.0 LINEAR 0.2 QUADRATIC 0.05
|
271
|
+
COLOR 1.0 0.0 0.0
|
272
|
+
|
273
|
+
Atmospheric effects
|
274
|
+
-------------------
|
275
|
+
|
276
|
+
RAY currently only implements one atmospheric effect, simple
|
277
|
+
distance-based fog.
|
278
|
+
|
279
|
+
Fog
|
280
|
+
~~~
|
281
|
+
|
282
|
+
RAY provides a simple distance-based fog effect intended to provide
|
283
|
+
functionality similar to that found in OpenGL, for compatibility with
|
284
|
+
software that requires an OpenGL-like fog implementation. Much like
|
285
|
+
OpenGL, RAY provides linear, exponential, and exponential-squared fog.
|
286
|
+
|
287
|
+
::
|
288
|
+
|
289
|
+
FOG
|
290
|
+
LINEAR START 0.0 END 50.0 DENSITY 1.0 COLOR 1.0 1.0 1.0
|
291
|
+
|
292
|
+
::
|
293
|
+
|
294
|
+
FOG
|
295
|
+
EXP START 0.0 END 50.0 DENSITY 1.0 COLOR 1.0 1.0 1.0
|
296
|
+
|
297
|
+
::
|
298
|
+
|
299
|
+
FOG
|
300
|
+
EXP2 START 0.0 END 50.0 DENSITY 1.0 COLOR 1.0 1.0 1.0
|
301
|
+
|
302
|
+
Objects
|
303
|
+
-------
|
304
|
+
|
305
|
+
Spheres
|
306
|
+
~~~~~~~
|
307
|
+
|
308
|
+
Spheres are the simplest object supported by RAY and they are also the
|
309
|
+
fastest object to render. Spheres are defined as one would expect, with
|
310
|
+
a ``CENTER``, ``RAD`` (radius), and a texture. The texture may be
|
311
|
+
defined along with the object as discussed earlier, or it may be
|
312
|
+
declared and assigned a name. Here’s a sphere definition using a
|
313
|
+
previously defined "NitrogenAtom" texture:
|
314
|
+
|
315
|
+
::
|
316
|
+
|
317
|
+
SPHERE CENTER 26.4 27.4 -2.4 RAD 1.0 NitrogenAtom
|
318
|
+
|
319
|
+
A sphere with an inline texture definition is declared like this:
|
320
|
+
|
321
|
+
::
|
322
|
+
|
323
|
+
Sphere center 1.0 0.0 10.0
|
324
|
+
Rad 1.0
|
325
|
+
Texture Ambient 0.2 Diffuse 0.8 Specular 0.0 Opacity 1.0
|
326
|
+
Color 1.0 0.0 0.5
|
327
|
+
TexFunc 0
|
328
|
+
|
329
|
+
Notice that in this example I used mixed case for the keywords, this is
|
330
|
+
allowable... Review the section on textures if the texture definitions
|
331
|
+
are confusing.
|
332
|
+
|
333
|
+
Triangles
|
334
|
+
~~~~~~~~~
|
335
|
+
|
336
|
+
Triangles are also fairly simple objects, constructed by listing the
|
337
|
+
three vertices of the triangle, and its texture. The order of the
|
338
|
+
vertices isn’t important, the triangle object is "double sided", so the
|
339
|
+
surface normal is always pointing back in the direction of the incident
|
340
|
+
ray. The triangle vertices are listed as ``V1``, ``V2``, and ``V3`` each
|
341
|
+
one is an X, Y, Z coordinate. An example of a triangle is shown below:
|
342
|
+
|
343
|
+
::
|
344
|
+
|
345
|
+
TRI
|
346
|
+
V0 0.0 -4.0 12.0
|
347
|
+
V1 4.0 -4.0 8.0
|
348
|
+
V2 -4.0 -4.0 8.0
|
349
|
+
TEXTURE
|
350
|
+
AMBIENT 0.1 DIFFUSE 0.2 SPECULAR 0.7 OPACITY 1.0
|
351
|
+
COLOR 1.0 1.0 1.0
|
352
|
+
TEXFUNC 0
|
353
|
+
|
354
|
+
Smoothed Triangles
|
355
|
+
~~~~~~~~~~~~~~~~~~
|
356
|
+
|
357
|
+
Smoothed triangles are just like regular triangles, except that the
|
358
|
+
surface normal for each of the three vertices is used to determine the
|
359
|
+
surface normal across the triangle by linear interpolation. Smoothed
|
360
|
+
triangles yield curved looking objects and have nice reflections.
|
361
|
+
|
362
|
+
::
|
363
|
+
|
364
|
+
STRI
|
365
|
+
V0 1.4 0.0 2.4
|
366
|
+
V1 1.35 -0.37 2.4
|
367
|
+
V2 1.36 -0.32 2.45
|
368
|
+
N0 -0.9 -0.0 -0.4
|
369
|
+
N1 -0.8 0.23 -0.4
|
370
|
+
N2 -0.9 0.27 -0.15
|
371
|
+
TEXTURE
|
372
|
+
AMBIENT 0.1 DIFFUSE 0.2 SPECULAR 0.7 OPACITY 1.0
|
373
|
+
COLOR 1.0 1.0 1.0
|
374
|
+
TEXFUNC 0
|
375
|
+
|
376
|
+
Infinite Planes
|
377
|
+
~~~~~~~~~~~~~~~
|
378
|
+
|
379
|
+
Useful for things like desert floors, backgrounds, skies etc, the
|
380
|
+
infinite plane is pretty easy to use. An infinite plane only consists of
|
381
|
+
two pieces of information, the ``CENTER`` of the plane, and a ``NORMAL``
|
382
|
+
to the plane. The center of the plane is just any point on the plane
|
383
|
+
such that the point combined with the surface normal define the equation
|
384
|
+
for the plane. As with triangles, planes are double sided. Here is an
|
385
|
+
example of an infinite plane:
|
386
|
+
|
387
|
+
::
|
388
|
+
|
389
|
+
PLANE
|
390
|
+
CENTER 0.0 -5.0 0.0
|
391
|
+
NORMAL 0.0 1.0 0.0
|
392
|
+
TEXTURE
|
393
|
+
AMBIENT 0.1 DIFFUSE 0.9 SPECULAR 0.0 OPACITY 1.0
|
394
|
+
COLOR 1.0 1.0 1.0
|
395
|
+
TEXFUNC 1
|
396
|
+
CENTER 0.0 -5.0 0.0
|
397
|
+
ROTATE 0. 0.0 0.0
|
398
|
+
SCALE 1.0 1.0 1.0
|
399
|
+
|
400
|
+
Rings
|
401
|
+
~~~~~
|
402
|
+
|
403
|
+
Rings are a simple object, they are really a not-so-infinite plane.
|
404
|
+
Rings are simply an infinite plane cut into a washer shaped ring,
|
405
|
+
infinitely thing just like a plane. A ring only requires two more pieces
|
406
|
+
of information than an infinite plane does, an inner and outer radius.
|
407
|
+
Here’s an example of a ring:
|
408
|
+
|
409
|
+
::
|
410
|
+
|
411
|
+
Ring
|
412
|
+
Center 1.0 1.0 1.0
|
413
|
+
Normal 0.0 1.0 0.0
|
414
|
+
Inner 1.0
|
415
|
+
Outer 5.0
|
416
|
+
MyNewRedTexture
|
417
|
+
|
418
|
+
Infinite Cylinders
|
419
|
+
~~~~~~~~~~~~~~~~~~
|
420
|
+
|
421
|
+
Infinite cylinders are quite simple. They are defined by a center, an
|
422
|
+
axis, and a radius. An example of an infinite cylinder is:
|
423
|
+
|
424
|
+
::
|
425
|
+
|
426
|
+
Cylinder
|
427
|
+
Center 0.0 0.0 0.0
|
428
|
+
Axis 0.0 1.0 0.0
|
429
|
+
Rad 1.0
|
430
|
+
SomeRandomTexture
|
431
|
+
|
432
|
+
Finite Cylinders
|
433
|
+
~~~~~~~~~~~~~~~~
|
434
|
+
|
435
|
+
Finite cylinders are almost the same as infinite ones, but the center
|
436
|
+
and length of the axis determine the extents of the cylinder. The finite
|
437
|
+
cylinder is also really a shell, it doesn’t have any caps. If you need
|
438
|
+
to close off the ends of the cylinder, use two ring objects, with the
|
439
|
+
inner radius set to 0.0 and the normal set to be the axis of the
|
440
|
+
cylinder. Finite cylinders are built this way to enhance speed.
|
441
|
+
|
442
|
+
::
|
443
|
+
|
444
|
+
FCylinder
|
445
|
+
Center 0.0 0.0 0.0
|
446
|
+
Axis 0.0 9.0 0.0
|
447
|
+
Rad 1.0
|
448
|
+
SomeRandomTexture
|
449
|
+
|
450
|
+
This defines a finite cylinder with radius 1.0, going from 0.0 0.0 0.0,
|
451
|
+
to 0.0 9.0 0.0 along the Y axis. The main difference between an infinite
|
452
|
+
cylinder and a finite cylinder is in the interpretation of the ``AXIS``
|
453
|
+
parameter. In the case of the infinite cylinder, the length of the axis
|
454
|
+
vector is ignored. In the case of the finite cylinder, the axis
|
455
|
+
parameter is used to determine the length of the overall cylinder.
|
456
|
+
|
457
|
+
Axis Aligned Boxes
|
458
|
+
~~~~~~~~~~~~~~~~~~
|
459
|
+
|
460
|
+
Axis aligned boxes are fast, but of limited usefulness. As such, I’m not
|
461
|
+
going to waste much time explaining ’em. An axis aligned box is defined
|
462
|
+
by a ``MIN`` point, and a ``MAX`` point. The volume between the min and
|
463
|
+
max points is the box. Here’s a simple box:
|
464
|
+
|
465
|
+
::
|
466
|
+
|
467
|
+
BOX
|
468
|
+
MIN -1.0 -1.0 -1.0
|
469
|
+
MAX 1.0 1.0 1.0
|
470
|
+
Boxtexture1
|
471
|
+
|
472
|
+
Fractal Landscapes
|
473
|
+
~~~~~~~~~~~~~~~~~~
|
474
|
+
|
475
|
+
Currently fractal landscapes are a built-in function. In the near future
|
476
|
+
I’ll allow the user to load an image map for use as a heightfield.
|
477
|
+
Fractal landscapes are currently forced to be axis aligned. Any
|
478
|
+
suggestion on how to make them more appealing to users is welcome. A
|
479
|
+
fractal landscape is defined by its "resolution" which is the number of
|
480
|
+
grid points along each axis, and by its scale and center. The "scale" is
|
481
|
+
how large the landscape is along the X, and Y axes in world coordinates.
|
482
|
+
Here’s a simple landscape:
|
483
|
+
|
484
|
+
::
|
485
|
+
|
486
|
+
SCAPE
|
487
|
+
RES 30 30
|
488
|
+
SCALE 80.0 80.0
|
489
|
+
CENTER 0.0 -4.0 20.0
|
490
|
+
TEXTURE
|
491
|
+
AMBIENT 0.1 DIFFUSE 0.9 SPECULAR 0.0 OPACITY 1.0
|
492
|
+
COLOR 1.0 1.0 1.0
|
493
|
+
TEXFUNC 0
|
494
|
+
|
495
|
+
The landscape shown above generates a square landscape made of 1,800
|
496
|
+
triangles. When time permits, the heightfield code will be rewritten to
|
497
|
+
be more general and to increase rendering speed.
|
498
|
+
|
499
|
+
Arbitrary Quadric Surfaces
|
500
|
+
~~~~~~~~~~~~~~~~~~~~~~~~~~
|
501
|
+
|
502
|
+
Docs soon. I need to add these into the parser, must have forgotten
|
503
|
+
before ;-)
|
504
|
+
|
505
|
+
Volume Rendered Scalar Voxels
|
506
|
+
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
507
|
+
|
508
|
+
These are a little trickier than the average object :-) These are likely
|
509
|
+
to change substantially in the very near future so I’m not going to get
|
510
|
+
too detailed yet. A volume rendered data set is described by its axis
|
511
|
+
aligned bounding box, and its resolution along each axis. The final
|
512
|
+
parameter is the voxel data file. If you are seriously interested in
|
513
|
+
messing with these, get hold of me and I’ll give you more info. Here’s a
|
514
|
+
quick example:
|
515
|
+
|
516
|
+
::
|
517
|
+
|
518
|
+
SCALARVOL
|
519
|
+
MIN -1.0 -1.0 -0.4
|
520
|
+
MAX 1.0 1.0 0.4
|
521
|
+
DIM 256 256 100
|
522
|
+
FILE /cfs/johns/vol/engine.256x256x110
|
523
|
+
TEXTURE
|
524
|
+
AMBIENT 1.0 DIFFUSE 0.0 SPECULAR 0.0 OPACITY 8.1
|
525
|
+
COLOR 1.0 1.0 1.0
|
526
|
+
TEXFUNC 0
|
527
|
+
|
528
|
+
Texture and Color
|
529
|
+
-----------------
|
530
|
+
|
531
|
+
Simple Texture Characteristics
|
532
|
+
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
533
|
+
|
534
|
+
The surface textures applied to an object drastically alter its overall
|
535
|
+
appearance, making textures and color one of the most important topics
|
536
|
+
in this manual. As with many other renderers, textures can be declared
|
537
|
+
and associated with a name so that they may be used over and over again
|
538
|
+
in a scene definition with less typing. If a texture is only need once,
|
539
|
+
or it is unique to a particular object in the scene, then it may be
|
540
|
+
declared along with the object it is applied to, and does not need a
|
541
|
+
name.
|
542
|
+
|
543
|
+
The simplest texture definition is a solid color with no image mapping
|
544
|
+
or procedural texture mapping. A solid color texture is defined by the
|
545
|
+
``AMBIENT``, ``DIFFUSE``, ``SPECULAR``, ``OPACITY`` and ``COLOR``
|
546
|
+
parameters. The ``AMBIENT`` parameter defines the ambient lighting
|
547
|
+
coefficient to be used when shading the object. Similarly, the
|
548
|
+
``DIFFUSE`` parameter is the relative contribution of the diffuse
|
549
|
+
shading to the surface appearance. The ``SPECULAR`` parameter is the
|
550
|
+
contribution from perfectly reflected rays, as if on a mirrored surface.
|
551
|
+
``OPACITY`` defines how transparent a surface is. An ``OPACITY`` value
|
552
|
+
of 0.0 renders the object completely invisible. An ``OPACITY`` value of
|
553
|
+
1.0 makes the object completely solid, and non-transmissive. In general,
|
554
|
+
the values for the ambient, diffuse, and specular parameters should add
|
555
|
+
up to 1.0, if they don’t then pixels may be over or underexposed quite
|
556
|
+
easily. These parameters function in a manner similar to that of other
|
557
|
+
ray tracers. The ``COLOR`` parameter is an RGB triple with each value
|
558
|
+
ranging from 0.0 to 1.0 inclusive. If the RGB values stray from 0.0 to
|
559
|
+
1.0, results are undefined. In the case of solid textures, a final
|
560
|
+
parameter, ``TEXFUNC`` is set to zero (integer).
|
561
|
+
|
562
|
+
Texture Declaration and Aliasing
|
563
|
+
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
564
|
+
|
565
|
+
To define a simple texture for use on several objects in a scene, the
|
566
|
+
``TEXDEF`` keyword is used. The ``TEXDEF`` keyword is followed by a case
|
567
|
+
sensitive texture name, which will subsequently be used while defining
|
568
|
+
objects. If many objects in a scene use the same texture through texture
|
569
|
+
definition, a significant amount of memory may be saved since only one
|
570
|
+
copy of the texture is present in memory, and its shared by all of the
|
571
|
+
objects. Here is an example of a solid texture definition:
|
572
|
+
|
573
|
+
::
|
574
|
+
|
575
|
+
TEXDEF MyNewRedTexture
|
576
|
+
AMBIENT 0.1 DIFFUSE 0.9 SPECULAR 0.0 OPACITY 1.0
|
577
|
+
COLOR 1.0 0.0 0.0 TEXFUNC 0
|
578
|
+
|
579
|
+
When this texture is used in an object definition, it is referenced only
|
580
|
+
by name. Be careful not to use one of the other keywords as a defined
|
581
|
+
texture, this will probably cause the parser to explode, as I don’t
|
582
|
+
check for use of keywords as texture names.
|
583
|
+
|
584
|
+
When a texture is declared within an object definition, it appears in an
|
585
|
+
identical format to the ``TEXDEF`` declaration, but the ``TEXTURE``
|
586
|
+
keyword is used instead of ``TEXDEF``. If it is useful to have several
|
587
|
+
names for the same texture (when you are too lazy to actually finish
|
588
|
+
defining different variations of a wood texture for example, and just
|
589
|
+
want to be approximately correct for example) aliases can be constructed
|
590
|
+
using the ``TEXALIAS`` keyword, along with the alias name, and the
|
591
|
+
original name. An example of a texture alias is:
|
592
|
+
|
593
|
+
::
|
594
|
+
|
595
|
+
TEXALIAS MyNewestRedTexture MyNewRedTexture
|
596
|
+
|
597
|
+
This line would alias MyNewestRedTexture to be the same thing as the
|
598
|
+
previously declared MyNewRedTexture. Note that the source texture must
|
599
|
+
be declared before any aliases that use it.
|
600
|
+
|
601
|
+
Image Maps and Procedural Textures
|
602
|
+
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
603
|
+
|
604
|
+
Image maps and procedural textures very useful in making realistic
|
605
|
+
looking scenes. A good image map can do as much for the realism of a
|
606
|
+
wooden table as any amount of sophisticated geometry or lighting. Image
|
607
|
+
maps are made by wrapping an image on to an object in one of three ways,
|
608
|
+
a spherical map, a cylindrical map, and a planar map. Procedural
|
609
|
+
textures are used in a way similar to the image maps, but they are on
|
610
|
+
the fly and do not use much memory compared to the image maps. The main
|
611
|
+
disadvantage of the procedural maps is that they must be hard-coded into
|
612
|
+
RAY when it is compiled.
|
613
|
+
|
614
|
+
The syntax used for all texture maps is fairly simple to learn. The
|
615
|
+
biggest problem with the way that the parser is written now is that the
|
616
|
+
different mappings are selected by an integer, which is not very user
|
617
|
+
friendly. I expect to rewrite this section of the parser sometime in the
|
618
|
+
near future to alleviate this problem. When I rewrite the parser, I may
|
619
|
+
also end up altering the parameters that are used to describe a texture
|
620
|
+
map, and some of them may become optional rather than required.
|
621
|
+
|
622
|
+
.. container:: center
|
623
|
+
|
624
|
+
+---------------------------+-----------------------------------------+
|
625
|
+
| Texture Mapping Functions | |
|
626
|
+
+===========================+=========================================+
|
627
|
+
| Value for TEXFUNC | Mapping and Texture Description |
|
628
|
+
+---------------------------+-----------------------------------------+
|
629
|
+
| 0 | No special texture, plain shading |
|
630
|
+
+---------------------------+-----------------------------------------+
|
631
|
+
| 1 | 3D checkerboard function, like a |
|
632
|
+
| | Rubik’s cube |
|
633
|
+
+---------------------------+-----------------------------------------+
|
634
|
+
| 2 | Grit Texture, randomized surface color |
|
635
|
+
+---------------------------+-----------------------------------------+
|
636
|
+
| 3 | 3D marble texture, uses object’s base |
|
637
|
+
| | color |
|
638
|
+
+---------------------------+-----------------------------------------+
|
639
|
+
| 4 | 3D wood texture, light and dark brown, |
|
640
|
+
| | not very good yet |
|
641
|
+
+---------------------------+-----------------------------------------+
|
642
|
+
| 5 | 3D gradient noise function (can’t |
|
643
|
+
| | remember what it look like |
|
644
|
+
+---------------------------+-----------------------------------------+
|
645
|
+
| 6 | Don’t remember |
|
646
|
+
+---------------------------+-----------------------------------------+
|
647
|
+
| 7 | Cylindrical Image Map, requires ppm |
|
648
|
+
| | filename |
|
649
|
+
+---------------------------+-----------------------------------------+
|
650
|
+
| 8 | Spherical Image Map, requires ppm |
|
651
|
+
| | filename |
|
652
|
+
+---------------------------+-----------------------------------------+
|
653
|
+
| 9 | Planar Image Map, requires ppm filename |
|
654
|
+
+---------------------------+-----------------------------------------+
|
655
|
+
|
656
|
+
Here’s an example of a sphere, with a spherical image map applied to its
|
657
|
+
surface:
|
658
|
+
|
659
|
+
::
|
660
|
+
|
661
|
+
SPHERE
|
662
|
+
CENTER 2.0 0.0 5.0
|
663
|
+
RAD 2.0
|
664
|
+
TEXTURE
|
665
|
+
AMBIENT 0.4 DIFFUSE 0.8 SPECULAR 0.0 OPACITY 1.0
|
666
|
+
COLOR 1.0 1.0 1.0
|
667
|
+
TEXFUNC 7 /cfs/johns/imaps/fire644.ppm
|
668
|
+
CENTER 2.0 0.0 5.0
|
669
|
+
ROTATE 0.0 0.0 0.0
|
670
|
+
SCALE 2.0 -2.0 1.0
|
671
|
+
|
672
|
+
Basically, the image maps require the center, rotate and scale
|
673
|
+
parameters so that you can position the image map on the object
|
674
|
+
properly.
|
675
|
+
"""
|
676
|
+
|
677
|
+
# ****************************************************************************
|
678
|
+
# Copyright (C) 2006 John E. Stone
|
679
|
+
#
|
680
|
+
# Distributed under the terms of the GNU General Public License (GPL)
|
681
|
+
# as published by the Free Software Foundation; either version 2 of
|
682
|
+
# the License, or (at your option) any later version.
|
683
|
+
# https://www.gnu.org/licenses/
|
684
|
+
# ****************************************************************************
|
685
|
+
|
686
|
+
import os
|
687
|
+
import re
|
688
|
+
|
689
|
+
from sage.cpython.string import bytes_to_str
|
690
|
+
from sage.features.tachyon import Tachyon
|
691
|
+
from sage.misc.pager import pager
|
692
|
+
from sage.misc.superseded import deprecation
|
693
|
+
from sage.misc.temporary_file import tmp_filename
|
694
|
+
from sage.structure.sage_object import SageObject
|
695
|
+
from sage.misc.cachefunc import cached_method
|
696
|
+
|
697
|
+
|
698
|
+
class TachyonRT(SageObject):
|
699
|
+
r"""
|
700
|
+
The Tachyon Ray Tracer.
|
701
|
+
|
702
|
+
Usage:
|
703
|
+
``tachyon_rt(model, outfile='sage.png', verbose=1, block=True, extra_opts='')``
|
704
|
+
|
705
|
+
INPUT:
|
706
|
+
|
707
|
+
- ``model`` -- string that describes a 3d model in
|
708
|
+
the Tachyon modeling format. Type ``sage.interfaces.tachyon?`` for a
|
709
|
+
description of this format.
|
710
|
+
|
711
|
+
- ``outfile`` -- (default: ``'sage.png'``) output filename;
|
712
|
+
the extension of the filename determines the type. Supported types
|
713
|
+
include:
|
714
|
+
|
715
|
+
- ``tga`` -- 24-bit (uncompressed)
|
716
|
+
|
717
|
+
- ``bmp`` -- 24-bit Windows BMP (uncompressed)
|
718
|
+
|
719
|
+
- ``ppm`` -- 24-bit PPM (uncompressed)
|
720
|
+
|
721
|
+
- ``rgb`` -- 24-bit SGI RGB (uncompressed)
|
722
|
+
|
723
|
+
- ``png`` -- 24-bit PNG (compressed, lossless)
|
724
|
+
|
725
|
+
- ``verbose`` -- integer; (default: 1)
|
726
|
+
|
727
|
+
- ``0`` -- silent
|
728
|
+
|
729
|
+
- ``1`` -- some output
|
730
|
+
|
731
|
+
- ``2`` -- very verbose output
|
732
|
+
|
733
|
+
- ``block`` -- boolean (default: ``True``); if ``False``, run the
|
734
|
+
rendering command in the background
|
735
|
+
|
736
|
+
- ``extra_opts`` -- passed directly to tachyon command
|
737
|
+
line. Use ``tachyon_rt.usage()`` to see some of the possibilities
|
738
|
+
|
739
|
+
OUTPUT: some text may be displayed onscreen
|
740
|
+
|
741
|
+
- The file outfile is created.
|
742
|
+
|
743
|
+
EXAMPLES:
|
744
|
+
|
745
|
+
.. automethod:: __call__
|
746
|
+
"""
|
747
|
+
def _repr_(self):
|
748
|
+
"""
|
749
|
+
Return a brief description of this interface object (the Tachyon
|
750
|
+
raytracer written by John Stone).
|
751
|
+
|
752
|
+
TESTS::
|
753
|
+
|
754
|
+
sage: from sage.interfaces.tachyon import TachyonRT
|
755
|
+
sage: t = TachyonRT()
|
756
|
+
sage: print(t.__repr__())
|
757
|
+
John Stone's Tachyon Ray Tracer
|
758
|
+
"""
|
759
|
+
return "John Stone's Tachyon Ray Tracer"
|
760
|
+
|
761
|
+
def __call__(self, model, outfile='sage.png', verbose=1, extra_opts=''):
|
762
|
+
"""
|
763
|
+
This executes the tachyon program, given a scene file input.
|
764
|
+
|
765
|
+
INPUT:
|
766
|
+
|
767
|
+
- ``model`` -- string; the tachyon model
|
768
|
+
|
769
|
+
- ``outfile`` -- string (default: ``'sage.png'``); the filename
|
770
|
+
to save the model to
|
771
|
+
|
772
|
+
- ``verbose`` -- 0, 1, (default) or 2; the verbosity level
|
773
|
+
|
774
|
+
- ``extra_opts`` -- string (default: empty string); extra
|
775
|
+
options that will be appended to the tachyon commandline
|
776
|
+
|
777
|
+
EXAMPLES::
|
778
|
+
|
779
|
+
sage: from sage.interfaces.tachyon import TachyonRT
|
780
|
+
sage: t = TachyonRT()
|
781
|
+
sage: import os
|
782
|
+
|
783
|
+
sage: # needs sage.plot
|
784
|
+
sage: tgen = Tachyon()
|
785
|
+
sage: tgen.texture('t1')
|
786
|
+
sage: tgen.sphere((0,0,0),1,'t1')
|
787
|
+
sage: tgen.str()[30:40]
|
788
|
+
'resolution'
|
789
|
+
sage: t(tgen.str(), outfile=os.devnull)
|
790
|
+
tachyon ...
|
791
|
+
Tachyon Parallel/Multiprocessor Ray Tracer...
|
792
|
+
|
793
|
+
TESTS::
|
794
|
+
|
795
|
+
sage: from sage.env import SAGE_EXTCODE
|
796
|
+
sage: filename = os.path.join(SAGE_EXTCODE, 'doctest', 'invalid', 'syntax_error.tachyon')
|
797
|
+
sage: with open(filename, 'r') as f:
|
798
|
+
....: syntax_error = f.read()
|
799
|
+
sage: t(syntax_error, outfile=os.devnull)
|
800
|
+
Traceback (most recent call last):
|
801
|
+
...
|
802
|
+
RuntimeError: Tachyon Parallel/Multiprocessor Ray Tracer...
|
803
|
+
...
|
804
|
+
Parser failed due to an input file syntax error.
|
805
|
+
Aborting render.
|
806
|
+
"""
|
807
|
+
if self.version() >= '0.99.2':
|
808
|
+
# this keyword was changed in 0.99.2
|
809
|
+
model = model.replace(
|
810
|
+
" focallength ",
|
811
|
+
" focaldist ")
|
812
|
+
modelfile = tmp_filename(ext='.dat')
|
813
|
+
with open(modelfile, 'w') as file:
|
814
|
+
file.write(model)
|
815
|
+
cmd = [Tachyon().absolute_filename(), modelfile]
|
816
|
+
ext = outfile[-4:].lower()
|
817
|
+
if ext == '.png':
|
818
|
+
cmd += ['-format', 'PNG']
|
819
|
+
elif ext == '.tga':
|
820
|
+
cmd += ['-format', 'TARGA']
|
821
|
+
elif ext == '.bmp':
|
822
|
+
cmd += ['-format', 'BMP']
|
823
|
+
elif ext == '.ppm':
|
824
|
+
cmd += ['-format', 'PPM']
|
825
|
+
elif ext == '.rgb':
|
826
|
+
cmd += ['-format', 'RGB']
|
827
|
+
cmd += ['-o', outfile]
|
828
|
+
cmd += extra_opts.split()
|
829
|
+
if verbose >= 2:
|
830
|
+
cmd += ['+V']
|
831
|
+
if verbose:
|
832
|
+
print(' '.join(cmd))
|
833
|
+
import subprocess
|
834
|
+
out = bytes_to_str(subprocess.check_output(cmd))
|
835
|
+
if verbose >= 1:
|
836
|
+
print(out)
|
837
|
+
if out.rstrip().endswith('Aborting render.'):
|
838
|
+
raise RuntimeError(out)
|
839
|
+
if outfile != os.devnull and os.stat(outfile).st_size == 0:
|
840
|
+
raise RuntimeError('tachyon did not abort but output file is empty')
|
841
|
+
|
842
|
+
def usage(self, use_pager=True):
|
843
|
+
"""
|
844
|
+
Return the basic description of using the Tachyon raytracer (simply
|
845
|
+
what is returned by running tachyon with no input). The output is
|
846
|
+
paged unless ``use_pager=False``.
|
847
|
+
|
848
|
+
TESTS::
|
849
|
+
|
850
|
+
sage: from sage.interfaces.tachyon import TachyonRT
|
851
|
+
sage: t = TachyonRT()
|
852
|
+
sage: t.usage(use_pager=False)
|
853
|
+
...
|
854
|
+
...tachyon... modelfile [options]...
|
855
|
+
<BLANKLINE>
|
856
|
+
Model file formats supported:
|
857
|
+
filename.dat ...
|
858
|
+
"""
|
859
|
+
with os.popen(Tachyon().absolute_filename()) as f:
|
860
|
+
r = f.read()
|
861
|
+
if use_pager:
|
862
|
+
pager()(r)
|
863
|
+
else:
|
864
|
+
print(r)
|
865
|
+
|
866
|
+
@cached_method
|
867
|
+
def version(self):
|
868
|
+
"""
|
869
|
+
Return the version of the Tachyon raytracer being used.
|
870
|
+
|
871
|
+
TESTS::
|
872
|
+
|
873
|
+
sage: tachyon_rt.version() # random
|
874
|
+
0.98.9
|
875
|
+
sage: tachyon_rt.version() >= '0.98.9'
|
876
|
+
True
|
877
|
+
"""
|
878
|
+
with os.popen(Tachyon().absolute_filename()) as f:
|
879
|
+
r = f.readline()
|
880
|
+
res = re.search(r"Version ([\d.]*)", r)
|
881
|
+
# debian patches tachyon so it won't report the version
|
882
|
+
# we hardcode '0.99' since that's indeed the version they ship
|
883
|
+
return res[1] if res else '0.99'
|
884
|
+
|
885
|
+
def help(self, use_pager=True):
|
886
|
+
"""
|
887
|
+
Deprecated: type 'sage.interfaces.tachyon?' for help.
|
888
|
+
|
889
|
+
TESTS::
|
890
|
+
|
891
|
+
sage: from sage.interfaces.tachyon import TachyonRT
|
892
|
+
sage: t = TachyonRT()
|
893
|
+
sage: t.help(use_pager=False)
|
894
|
+
doctest:...: DeprecationWarning: type 'sage.interfaces.tachyon?' for help
|
895
|
+
See https://github.com/sagemath/sage/issues/34066 for details.
|
896
|
+
"""
|
897
|
+
deprecation(34066, "type 'sage.interfaces.tachyon?' for help")
|
898
|
+
|
899
|
+
|
900
|
+
tachyon_rt = TachyonRT()
|
Binary file
|
sage/libs/tachyon.pyx
ADDED
@@ -0,0 +1 @@
|
|
1
|
+
# sage_setup: distribution = sagemath-tachyon
|
sage_wheels/bin/tachyon
ADDED
Binary file
|