Contents
-
-
-
-
-
-
-
-
-
-
-
-
NURBS Modelling
(partitially new in Version 0.25beta)
-
-
-
other 3D-Modellierung related commands
-
-
White_dune is a graphical VRML97 editor, simple (NURBS) 3D modeller and
animationtool in development.
It can read VRML97 files, display and let the user change the
scenegraph, fields and routes.
This can be used to improve or make VRML97 3D-worlds, animations and
interactions.
The modelling features of white_dune are not strong enough (yet), to use
it alone. It makes sense, to let it work together with a 3D modelling tool
with static VRML97 export (like for example wings3D oder Art Of Illusion).
In difference to most 3D modelling tools the lightning/coloring and the
interal structure of white_dune is based on the VRML97 standard.
White_dune is work in development and it is not as stable as it should be.
If white_dune crashed, is your work lost ?
No not automatically !
"White_dune" will try to save the
VRML97 file short before crash. This is not always successful e.g. when the
error which caused the crash destroyed the internal data structure.
If the file is written sucessfully, white_dune will write
under Unix/Linux something like
Internal Crash !
Try to save Files
attempt to write file to /home/someone/.dune_crash_NUMBER_NUMBER.wrl
write sucessful
to standard error of the starting window and to system console
(eg. to the window of the xconsole application).
Under M$Windows you get (possibly after clicking "ignore")
a similar Messagebox

When you restart white_dune and use the file menu, you should see the filename
of this .dune_crash file.

Just click to it and save to another file.
This Method can fail, if the error that led to crash
has damaged the internal data structure of the program.
In this case it is worth to search in directory of VRML-files for
temporary files (".dune_*"), that are produced during the execution of
File->Preview or File->Textedit.
These Files will be deleted at a normal program end, but not in case of a
program crash.
For example if the program crashs immediately after changing or creating
the ECMAscript part of a scriptnode in a texteditor, after the
file with the ECMAscript program was written, this file is still part
in the filesystem. You can find this file (via name and creation date)
and reuse the content per cut and paste.
White_dune can be started with menues in foreign languages.
For example, to start white_dune with the german language, the
commandlineoption "-german" must be used.
Cause it is not very usefull, always to type in a commandline, this can
be done with a shellscript (Linux/UNIX/MacOSX) or batchfile (Micro$oft
Windows.
If you can not find a matching file (e.g. germandune for the german
language), you can create one (e.g. for the german language) with the
commandlines:
For MacOSX you must modify in the file
white_dune.app/Contents/MacOS/dunestarter the lines with the
options for the program start:
DUNEOPTIONS=" "
export DUNEOPTIONS
and add e.g. the -german option for the german language:
DUNEOPTIONS="-german "
export DUNEOPTIONS
For other exotic UNIX desktops you will find similar options in the following
files
-
SGI IRIX/4Dwm: desktop/irix*/duneoptions.m4
Read the file README_IRIX.desktop for more information
-
IBM AIX/cde: /usr/local/bin/white_dune.dt
-
Sun Solaris/cde: /opt/White_Dune/bin/white_dune.dt
-
Redhat Linux/kde: /usr/share/applications/dune.desktop
If you are interested to translate the white_dune menus and errormessages
into a new foreign language (no programming skills required), please read the
step by step instructions about localisation in the developer documentation.
-
White_dune is not a full featured VRML browser (yet) and can not
display all
It has features to create interactions and script programming, but you still
need File -> Preview
(or you have to save the file and open it in a VRML Browser) to test
the results.
-
What is (still) missing in white_dune is the support for
for self defined VRML nodes
(PROTO bzw. EXTERNPROTO)
White_dune recognise PROTOs and writes PROTOs back unchanged when
saving files. You can create new VRML nodes of the matching PROTO-type
and change the fieldvalues (the default values of PROTOs in files
(EXTERNPROTO) are not (yet) correct recognised). PROTOs
are not shown correctly in the 3D Preview Window in all cases (yet).
There is no way (beside using File -> textedit ) to change the
PROTO definition itself (yet).
-
White_dune is not a general purpose modelling tool (yet)
It has easy input features for primitive VRML97 shapes like Box, Sphere,
Cone and Cylinder and shapes like ElevationGrid and Extrusion, but not for
other shapenodes like IndexedFaceSet (a shape made of multiple
facets), IndexedLineSet and PointSet.
The most common shape in 3D modelling is the "mesh". Most 3D modelling
programs currently export "mesh" data to VRML97 as IndexedFaceSets.
-
A also common shape in 3D modelling is the "NURBS" shape, which can
be used in white_dune.
Nodes like NurbsSurface, NurbsGroup or NurbsCurve are not part of
the traditional VRML97 standard from 1997, but they are part of the VRML97
Amendment 1 Standard from 2002.
Currently, this nodes are supported by VRML97 browsers like
bitmanagement/blaxxun cc3d/contact, but not implemented in no longer
supported VRML browsers like cosmoplayer 2.1.
There is a (slow and not complete) implementation
for cosmoplayer 2.1 via a VRML PROTO.
You can find more information about this
here.
-
White_dune finally allows the conversion of all surface shapes to
a IndexedFaceSet. A IndexedFaceSet can be converted to a
IndexedLineSet, a IndexedLineSet can be converted to a PointSet.
But take care about the fact, that these convertions are working
in only one way. A conversion back is not possible inside white_dune.
You can find some typical VRML examples (you can load into white_dune)
here, but take care about
the fact, this examples do not show modelling or animation features, they
show mainly VRML97 examples about interaction and scripting. These are
features, which can be not shown in white_dune directly (yet).
The examples are the start base to build interactive 3D worlds with white_dune,
which are used later with a "real" VRML browser.
White_dune is a lowlevel tool to make/change VRML97 Files.
It is supposed, the user knows the basic structure of VRML97.
You can find detailed technical information about VRML97
in the official ISO specification at
http://www.web3d.org/x3d/specifications/vrml/ISO-IEC-14772-IS-VRML97WithAmendment1
.
For the use of white_dune, especially the node reference
http://www.web3d.org/x3d/specifications/vrml/ISO-IEC-14772-IS-VRML97WithAmendment1/part1/nodesRef.html
is important.
A good, simple tutorial about VRML97 for beginners you can find
(beside in a range of books) at
http://web3d.vapourtech.com/tutorials/vrml97/.

Beside some toolbars with icons and messages "white_dune" essentially contains
5 windows. Beside the "3D Preview" window you can switch on/switch off
this windows via the menu "View". Switch on/off this windows,
when they match your current work status.
-
Scene Tree
This window contains the scenegraph. This shows the structure
of a VRML file, the information, how the VRML nodes are arranged.
-
Field View
This window contains the fieldvalues, the numbers (or
character strings) in a VRML file. Only the fields
of the current selected node are shown.
-
Route View
This windows contains the ROUTEs, the ways of information
different VRML nodes can send messages between them.
According to the Settings in options -> RouteView Settings
there are either only the current ROUTEs are shown (like ROUTEs are
stored in a VRML file) or the Routes and all existing nodes are shown.
To show all nodes makes it easier to build new ROUTEs in small VRML files,
but can be very confusing in very big VRML files.
-
Channel View
This window is only valid for interpolator nodes.
Interpolator nodes are most important for animations
in VRML97.
-
3D Preview window
This Window can not be switched off and shows a
preview of the graphical output of a VRML file.
In difference to the other windows, the implementation
of the VRML97 standard in this window is (still) incomplete.
Some VRML97 nodes like "MovieTexture" or the self defined "EXTERNPROTO",
nodes are not shown at all. The icons of not shown nodes are either
empty (EXTERNPROTOs) or surrounded by a black frame.
The nodes from the not widely used VRML97 Amendment 1 Standard
(ISO/IEC 14772:2002) has the most failures, despite the fact that the
nodes NurbsSurface, NurbsCurve and NurbsGroup from Amendment 1 are currently
responsible for the most powerfull 3D modelling features of white_dune.
Not all fields are shown correctly, e.g. the "Text" node under
Linux/UNIX/MacOSX should be seen as "better than nothing" (especially,
if the program is compiled without support from the GLUT library).
The fieldvalues of the "FontStyle" node (which belongs to the "Text" node
is also not correct (yet).
The field "convex" is (still) ignored too. When "convex" is set to "false",
nonconvex polygons are displayed correctly.

Correct and false image of a IndexedFaceSet with nonconvex polygons
with "convex false" in FreeWRL (links)
and white_dune (rechts)
The problem with "convex false" exist also in Extrusion-based
nodes. The are more rendering errors when using Extrusions.
The display of multiple transparent shapes is also errornous.
There are also errors in the display of some PROTOs.
Of course, such a false image of a VRML object in the 3D Preview
do not mean, there is a error in the VRML file.
If in doubt, use File->Preview to start a VRML browser.
To navigate in the 3D Preview Window, you have two differ between
different walk modes.
-
Shift-Mouse 1: Zoom View
-
ctrl-Mouse 1: Rotate View
-
Shift-ctrl-Mouse 1: Move View
Additional you have from version 0.16 a SGI like navigation.
Please note, that a misconfigured windowmanager can eat up all mouse
input, that uses the Alt key....
-
Alt-Mouse1: Rotate View
-
Alt-Mouse2: Move View
-
Alt-Mouse1-Mouse2: Zoom View
When a 6D inputdevice is active and the Scene icon
is selected in the Scene Tree
you can navigate depending on the transform icons
in the VRML file.
The most simple way to change the scenegraph is to add new node
by clicking to the matching VRML node icon.
To identify a VRML node icon, move the mouse to it and wait. A descriptive
text will occure in the status bar at the bottom of the white_dune window.
White_dune tries either to include the new node at the point of selection in
the scenegraph,

or to the root of the scenegraph ("Scene" icon).
White_dune will gray out all node icons, that are impossible to add.

The following table shows the requirements for this nodes in the
VRML97 standard:
- Appearance need Shape
- Material need Appearance
- ImageTexture need Appearance
- MovieTexture need Appearance (or Sound)
- PixelTexture need Appearance
- TextureTransform need Appearance
- Coordinate need IndexedFaceSet or IndexedLineSet or PointSet
- Color need IndexedFaceSet or IndexedLineSet or PointSet
- Normal need IndexedFaceSet
- TextureCoordinate need IndexedFaceSet
- FontStyle need Text
- AudioClip need Sound
For example a Appearence node need to be selected, to include a
ImageTexture node, or a Shape node need to be selected to include
a Appearence node.
All of the matching node fields in the VRML97 are of type SFNode,
therefore only one node can be inserted. A icon is also grayed,
if there is already a matching node.
For example you can not include two ImageTexture Nodes
to a Appearence node. Therefore the ImageTexture is also grayed,
if a Appearence node is selected, but a ImageTexture node is already there.
According to the VRML97 Standard the shape nodes Box, Sphere, Cone,
Cylinder, IndexedFaceSet, IndexedLineSet, PointSet, ElevationGrid,
Extrusion and Text need a Shape node. In most cases, the needed structure
for the usage of this Shape.geometry nodes is clear.
Therefor the click on the icons and the usage of the
Create -> Shape -> menuitems build a complete Shape-structure
(including a surrounding Transform node).
(New in Version 0.29beta) If the selection in case of a creation of such
a node is not a node a Shape node can be part of, the surrounding Transform
node is filled in a way, that the new node is shown directly in front of the
actual viewpoint.
The commands Edit -> copy, Edit -> paste and
Edit -> delete work similar to the same commands in many programs.
If the last mouseclick was in the Scene Tree, they can be used to
change the scenegraph as expected.
A unusual command is the Edit -gt; copy branch to root command.
It copies all nodes along the path to the root of the current scenegraph branch
into the paste buffer. This can be very handy, if you need to double and
split a scenegraph branch.
Another way to change the scenegraph is to drag parts of it with the
mouse.
White_dune will show you with a icon of a stop sign,
if the target node is not possible

If the target node is possible, white_dune will show the normal mousepointer.

The target is not possible, if there are multiple SF/MFNode fields of the
target node.

Nodes with multiple fields of type SF/MFNode (e.g. the collision node)
always display the field names in the scenetree (despite a opposite setting in
the Options -> Preferences dialog), so you can use the field names
as targets in this case.
Similar to the local copy/move in the explorer program of
M$Windows2000 and similar filemanagers it is possible to change
the behaviour, if the keyboard is used when the mouse is still dragged:
-
Move:
no key pressed or Shift key pressed (icon do not change)

- Copy:

Crtl key pressed (icon add "+" picture)

-
DEF/USE:

Crtl key and Shift key pressed together (icon add "arrow" picture)

(new in Version 0.29beta)
Beside the drag and drop method above, there is a additional way to use the
USE construct. The USE construct is something like a undistinctable pointer,
the reuse of a already existing node. The node to be USEd need a DEF name
which can be applied with Edit -> DEF. The usage of
Edit -> USE (if possible) adds a new USE of the last DEFd node
at the point of the selected node.
If you change the DEFd node, the USEd node is changed as well.
If you change the USEd node, the DEFd node is changed as well.
In white_dune (unlike when using a text editor on a VRML97 file), you can
legally delete the DEFd node. The first written formerly USEd node becomes
the new DEFd node, cause the DEF/USE construct is about undistinctable
pointers.
Using USE is useful for keeping VRML files small (faster downloadable),
increases maintainabilty and can be used to for faster rendering by a
smart VRML browser.
Additional commands, that can create USE constructs are the
array tool and some of the "create" scenegraph operations following.
(new in Version 0.27beta)
There is no way to move multiple nodes in the scenegraph (yet).
As a workaround there are operations which can be applied to all nodes
in the scenegraph branch following the selection (including the
selection itself).

The are commands available via Actions -> Rest of scenegraph branch:
-
Move to
This command move the nodes into a grouping node (like Group,
Transfrom etc.)
It is also possible, to bring nodes into a new VRML97 file and
use this file via the Inline command, but only if there is no
ROUTE has one of this nodes as target or a USE is used.
-
Move 1 level up
This command moves the nodes into the same scenegraph branch as
the parent of the selected node.
-
Actions -> Move rest of scenegraph branch 1 level up
This command moves the nodes into the same scenegraph branch as
the parent of the selected node.
-
Create
This command creates the new node
(ImageTexture, Material, Appearance, Normal etc.)
at every possible place in the scenegraph branch.
The created nodes are all belong to the Shape node.
It has to be differed between nodes, which belong to the appearance
field of Shape (ImageTexture, Material und Appearance) and nodes,
which belong to the geometry field of Shape (Normal, TextureCoordinate).
For nodes, which to the appearance field, a new node is created at the
first possibility in the scenegraph and for all following possibilities
the node is reused via USE.
This makes it possible to change the color, the material and the
texture of a whole scenegraph branch with little effort.
Nodes which belong to the geometry field of shape will be generated
according to the data of the Shape (e.g. a IndexedFaceSet).
-
Set
This command changes some fields (creaseAngle, transparency, etc.) in the
scenegraph branch, which influence the view of a shape and can be
easily changed.
-
Remove
This command remove some nodes
(ImageTexture, Material, Appearance, Normal etc.) in the
scenegraph branch. Most of the nodes are corresponding to the nodes in the
Create command, because the Create Command can only insert
nodes, if the matching field is not blocked by a already existing node.
So the Remove command can be the first step to change values in
the scenegraph branch.
-
Show polygons/primitives in status bar
This command is a informational command and do not change anything in
the Scenegraph. It can be used to find the part of the scenegraph,
which contain the biggest number of polygons/primitives. This is
very important for finding performance problems in realtime 3D data.
Primitives are nodes like Box, Cone, Cylinder and Sphere. For Primitives,
the number of polygons used in the VRML Browser depends from
the VRML Browser itself. For example, a VRML Browser can use 16 Polygons
to draw the top surface of a Cylinder of a low quality view with
a lot of edges or can use 32 Polygons for better quality.
A Sphere usually use very much more polygons than a Box.
To find the part of the scenegraph, that contain the biggest number
of polygons/primitives, you can use a binary search algorithm:
Click to the scene icon at the root of the scenegraph and use
Actions -> Rest of scenegraph branch ->
Show polygons/primitives in status bar.
The result are the number of polygons/primitives in the whole VRML file.
Select a node approximatly in the mid of the current level of the
scenegraph branch and use
Actions -> Rest of scenegraph branch ->
Show polygons/primitives in status bar.
If the number is greater than the half of the result of the last
command, the majority of polygons/primitives is in the upper part
of the current level of the scenegraph branch. Continue with the
command at the approximatly mid of the upper part of the current
level of the scenegraph branch.
If the number is less than the half of the result of the last
command, the majority of polygons/primitives is in the lower part
of the current level of the scenegraph branch. Continue with the
command at the approximatly mid of the lower part of the current
level of the scenegraph branch.
Continue with this scheme of using the mid of the remaining range of
the last command, till you find either a node or a range of nodes
which contain the most polygons/primitives in your file.
The node (or range of nodes) (e.g. if it is a Group or Transform node)
can itself contain multiple other nodes. If you click to the plus
sign in the Scene Tree of such a node you open a new level of the
scenegraph branch. If you need to continue the search for the
part with the most polygons/primitives of the scenegraph branch,
use Actions -> Rest of scenegraph branch ->
Show polygons/primitives in status bar and continue with the
second step.
Unfortunatly some of these operations are (still) very slow.
In white_dune, there are two different settings, which drive the way to
insert a ROUTE.
-
In Options -> RouteView Settings... the checkbox for
"Show all nodes in Routeview" is set:
All nodes in the scene are shown in the routeview.
This is usefull for working with small VRML files, but for VRML files
with a lot of nodes, it can be horrible to find the right icon.
-
In Options -> RouteView Settings... the checkbox for
"Show all nodes in Routeview" is not set:
Only nodes with already existing routes are shown in the routeview.
To let a node without ROUTEs occure in the Routeview, you need to select
the node in the scene tree window and use the
Route -> show node on top command.
ROUTEs are made in white_dune by finding the right icon in the
RouteView Window (if you click to the icons, the matching
icon in the scene tree windows is selected
(using Route -gt; Move node to top can be usefull) and click to
the boxes of the matching events. The name of the matching
event is shown, and you can draw a line to the next icon/event.

As required by the VRML standard, only events with the same
type (same color of boxes) can be connected.
To erase ROUTEs, simply cut the line.


As a sugestion for beginners, some event boxes are marked with a small
red point. The red point marks a important/often used event.
Of course the importance/usage of events differ with the task of your
VRML world. All sensor nodes (the original source of most eventprocessing)
have event boxes with red points.
In complex VRML worlds with a lot of objects (for example the VRML export
from a 3D-Modelling program like Wings3D, Blender, AOI, Catia,
3D Studio Max, Maya etc.) it can be difficult to find the wanted VRML nodes
in the RouteView window.

There are operations to jump to the selected node (with
Routes -> Unzoom/jump to selection )

or zoom out of the Routeview (with Routes -> Zoom out)

but in such cases, the usage of the Inline VRML node
is recommended. It can be used to put static objects (for example parts
of the environment or parts of rigid shapes) in their own VRML files.
In result the complete VRML world can only consist of very few VRML nodes.

Commands with automatic generation of ROUTEs
There are two commands to automatically generate new ROUTEs.
-
Action -> animate
With this commands the ROUTEs for
TimeSensor -> *Interpolator -> selected node
will be generated. After using the command, a Dialog is opening, which
ask for a new TimeSensor should be build or a already existing TimeSensor
should be used.
The dialog also asks what target event (field) in the selected node should
be used. Depending on the Type of the target event a new Interpolator
is generated.
-
SFFloat: ScalarInterpolator
-
SFVec3f: PositionInterpolator
-
SFRotation: OrientationInterpolator
-
SFColor: ColorInterpolator
-
MFVec3f: CoordinateInterpolator (except the target node is
a Normal node, then a NormalInterpolator is generated)
When the value of the target event can be read, a new first key/keyValue
pair with key=0.0 and keyValue=value_target_field will be set.
-
Action -> add Interaction(new in Version 0.29beta)
In this case, the ROUTE
Sensor -> selected node
will be generated.
Cause there are more than one possible target events in the selected
node and different to the Interpolators the assignment between
target event type and sensor is ambigious there are very much possibilities,
a lot of them make seldom sense. Therefore there are two Listboxes:
one Listbox you can use to select between recommended events and
all events and a listbox, you can select already existing sensors.
In a window there are checkboxes will all sensor events/target events
combinations for a new interaction, according to the selection of the
listboxes.
There is more than one way to change fieldvalues:
-
Keyboard input
By clicking with the mouse to the matching value and releasing the
button. A text input window will open to input values from
the keyboard.
-
Mouse input
By pressing the left mousebutton on the matching value and not releasing the
button, but moving the mousepointer to left or right. This will
decrease or increase the value.

-
Changing "MF"-FieldValues(new in version 0.27beta)
In the fieldview Window, a "+"-sign at the left side mark a "MF"-field
like MFFloat, MFInt32, MFVec3f, MFRotation, MFString etc.
"MF"-Fields are arrays of data, you can count their content: first,
second, third, etc.
To show/change the content of a "MF"-field, you need to click on the
"+"-character on the left side.
As in a VRML file a "MF"-field with only one data is shown similar
a normal single data "SF"-field.
To add data to a "MF"-field, you need to click to the second column of
"+"-characters. New data is inserted at the next point of the array.
To insert at the first point, click to the right side of the fieldview
before the first of a opened "MF"-field.
To delete from a "MF"-Field, click on the left side of the fieldview
at the row with the data you want to delete and use the menuitem
Edit -> delete.
-
Changing FieldValues in the 3D Preview window
Changing in the 3D Preview window is also a chainging of the fieldvalues.
Mainly transform nodes are changed.
During interactive work with the mouse in the 3D Preview window, the icons
select between a
- translation
- rotation
- scale
- changing center
(new in version 0.19beta)
Please note, you can not use this tools, when there
is no transform node
in the branch
of the scenegraph.
Beside the Transformnode, other fieldvalues can be changed in
the 3D Preview window. This is about moving small white boxes, like
in Box, Cone, Cylinder, Sphere, ElevationGrid, Extrusion, PointLight
or the VRML97 Amendment 1 NurbSurface/NurbsCurve Nodes.
-
6D Input (new in version 0.19beta)
Since version 0.19beta white_dune supports 6D inputdevices
(6D is about the 6 degrees of freedom) under Unix/Linux.
is pressed, you can move a Transform node (and the containing objects)
in all 6 degrees of freedom. The icon
limits the movement to translations, the icon
limits to rotations.
The classic
6D inputdevice is the spaceball, a sort of joystick which allows
only small excursions, but in all directions, including rotations.

If you press the top of the spaceball for example, the object moves
down. When you twist the spaceball, the object will follow this
movement.
The configuration of 6D inputdevices (still) works exclusively
via commandlineparameters. Beside the type of the 6D inputdevices
a scale of the inputvalues is needed for example:
white_dune -xinput spaceball -allxyz=20,200 -allrot=40,400
It is also possible to change the scale of the inputdevices when
the program is running. Use
Mode -> Inputdevice -> Increase input device
(icon
) or
Mode -> Inputdevice -> Decrease input device
(icon
).
If you limit the movement to translations (
), only
the "allxyz" scale
is changed. If you limit to rotations
,
only the "allrot" scale is changed.
Beside the support via the Xinput protocol, Linux joystick and
libsball are also supported. For details to the commandlineparameters
see the man page.
Another 6D inputdevice are the dials (e.g. available under SGI IRIX).
Per default, the inputaxes are awkward placed.

Via Commandlineparameters
dune -xinput dialbox-1 -x=0 -y=2 -z=4 -xrot=1 -yrot=3 -zrot=5 -all=100,100,wheel
you can exchange the axes.

-
6D Local Mode Input: Do you know RC planes ?
(new in version 0.19beta)
When the 6Dlocal icon
is pressed, you can steer via
the local axes of a transform node.
For example, if you move a spaceball into z-direction ("into the screen")
the transform node (and the containing objects) move to the direction
of it's local z axis, it follows the blue z-arrow.
For example, if you move a spaceball into y-direction ("up")
the transform node (and the containing objects) move to the direction
of it's local y axis, it follows the green y-arrow.

This is usefull, when object and transformnode are similar arranged.
Normally the object is not in the direction of the arrows of it's
transform node.

Therefore the transform node should be put into another and the
transform node of the object should be rotated accordingly.


When you use this type of steering, you will see a effect, which
is not surprising for users of RC planes:
If the object is moving "toward you", a roll to the left of the
spaceball leads to a roll to the right of the object.
A similar transformnode is the rocket
mode.
In rocket mode, translations are only in the local z-direction allowed.
This is useful, if you want to steer a object on a path while allowing
all types of rotation.
A other similar transformmode is the hover
mode.
In hover mode, rotations are allowed only around the local y-axis.
This is usefull, if you want to steer a object in-plane.
Other transformmodes, that work in a local mode (changes in direction of
the local axes) are the scale
and
changing center
modes.
-
Mindstorms NXT dials Input:
A selfmade device very similar to the SGI dials can be build easily
with the Mindstorms NXT set.

Just attach a wheel/gear to each of 3 Mindstorm NXT motors, connect the
motors with the NXT brick, connect the NXT brick with your Computer
via USB and and you can use the result as a USB driven dials device.
The access is done with libusb, which may need additional configuration,
eg. a pseudo-filesystem known as 'usbdevfs` or 'usbfs` mounted under
/proc/bus/usb under Linux.
To access the libusb functions without root rights, you may need
additional configurations, e.g. a modification of the udev configuration
under Linux (google for the terms "usblib udev nxt").
The matching commandline to use the first ("0") brick connected to the
USB port is
dune -nxtdials 0 -all=,,wheel
-
Linux joystick Input:
Unfortunatly, 6D inputdevices are not very widespread.
So white_dune under Linux has support for joysticks.
There are a lot of different devices (including the spaceball), that
can be used under Linux as joystick.
You have to differ between 6D (e.g. Labtec Spaceball), 4D (e.g. gamepads
with 2 thumbsticks), 3D (z.B. joystick with a twisting stick (e.g.
Micro$oft Sidewinder Pro))
and "normal" 2D joysticks.
-
6D joysticks (e.g. Labtec Spaceball) are used like all other 6D
inputdevices.
-
4D joysticks (e.g. gamepads with 2 thumbsticks) do not allow 6D and
6D Local mode. Beside translation
,
rotation
, scaling
and
changing of the center
they support the
hover
mode and the rocket
mode.
Depending from the mode, rotation and translation will be
assigned to the appropriate axes.
-
When using 3D joysticks (e.g. joystick with a twisting stick) things
are more complicated. In the default configuration, a input via the
3. axis (a twist of the stick) cause a movement assigned to the z-axis.
-
When using a 2D joystick, there are not enough axes to make
3D input data. Therefore you have to switch between the
interpretation of the 2. axis as z-direction (near/far
mode) and as y-direction
(up/down
mode) via the icons.
On rotations the near/far
mode is interpreted
as rotation around the y-axis, the up/down
mode is interpreted as a rotation around the z-axis.
-
The rocket
mode need 4 axes in a sense.
To make it available with a 3D joystick, the rotationinformation of
the near/far
Mode and up/down
mode is used here.
Beim 2D Joystick steht der
The rocket
mode is not available for 2D joysticks.
Sometimes, a joystick axis looks not very useful
(e.g. the extra controler of the Micro$oft Sidewinder Pro).

Therefore, the number of axes can be limited. To use e.g. the
Micro$oft Sidewinder Pro as 3 axis joystick, you can use the
-axis option in the commandline.
white_dune -joystick /dev/input/js0 -axes=3
Gamepads are often overcrowded with less useful axes.
For example the Logitech Wingman Cordless Gamepad report 9 axes when
testing with the jstest programm. To use the 6 good axes
(2 thumbsticks and the cross-hairs), you need to change the
assignment of axes in the commandline.
white_dune -joystick /dev/input/js0 -y=4 -z=-1 -xrot=6 -yrot=3 -zrot=5
You have to interpret the option "-z=-1" in this way:
the z-axes will be assigned to axis number 1 (this is the 2. axes,
counting begins with 0), but the inputdirection is reverted.
-
M$Windows joystick Input:
The support of a M$Windows joystick is very similar to a Linux
joystick.
The special qualities of joystick drivers delivered with M$Windows
should not make you wonder, if e.g. the 2. thumbstick of a gamepad
do not deliver values or a joystick axis will be reported, but
can deliver only errors.
Beside this, the wisdom of the authors of the M$Windows joystick
API leaded to the fact, a error of a axis must be interpreted
as full turn (a similar problem leaded to the explosion of the
first Ariane 5 rocket....).
Therefore you should begin to test under M$Windows with only 2 axes.
For the first M$Windows joystick (number 0) the commandline may look
like:
white_dune.exe -joystick 0 -axes=2 -none=2 -allxyz=20,,,0.000001 -allrot=0.2,,,0.0000001
-
Changing FieldValues in the ChannelView Window
The ChannelView Window is used to show or change
interpolator nodes.
In a interpolator node, input values between 0 and 1 are assigned to
a range of output values.
Interpolators are used in VRML for simple animations in the form
ROUTE TimeSensorDEFNAME.fraction_changed TO ???InterpolatorDEFNAME.set_fraction
ROUTE ???InterpolatorDEFNAME.value_changed TO ???DEFNAME.set_???
The output "fraction_changed" of a TimeSensor node
(deliver values between 0 and 1) ist routed into the "set_fraction"
input event of a interpolator node. The interpolator node select a
matching intermediate value between the output values. The
result can be routed into a another VRML node, this leads to
a animation without jerk.
In the following example:

the output of a PositionInterpolators with the input values
0, 0.3, 1 and the output values x=1 y=0 z=3, x=1 y=2 z=3, x=3 y=3 z=0
is routed to the set_translation Input for a transform node.
For example, the transform node (and the containing object) will
move in the timecycle from 0 to 0.3 from y=0 to y=2 (to the top).
-
Easy usable are all SF-interpolators:
-
ColorInterpolator:
Interpolate between Colors.
Route targets for colors you will find at Shape->Appearance->Material
-
PositionInterpolator:
Interpolate between Positions.
Route target can be Transform.set_translation for example.
-
OrientationInterpolator:
Interpolate between rotations.
Route target can be Transform.set_rotation for example.
-
ScalarInterpolator:
Interpolate between single (floating point) numbers.
Single numbers are possible EventIn's of multiple VRML Nodes.
There are multiple possibilities of usage.
-
The following MF-interpolators are not easy to display in the ChannelView,
there is a lot data that can simply flood the window. Therefore only
changes of the MF-Values over the time is displayed. If there are not
changes, the first value is always displayed

to allow to set additional
keys with the mouse

(e.g. to repeat the first timestep as last timestep)
.

There is a upper
limit in the number of displayed values. See "Limit keys in Channelview"
in the Options -> Preferences dialog. Set this limit
accordingly to the speed of your system.
-
CoordinateInterpolator:
Interpolates typically between points in a IndexFaceSet.
Animations, which use the CoordinateInterpolator are usually called
"morphing".
-
NormalInterpolator:
Interpolate between the Normales of a IndexFaceSet.
Some interpolator animation can be created in white_dune via
changes in the 3D Preview window.
PositionInterpolator/Transform.set_translation
and OrientationInterpolator/Transform.set_rotation based animations
can also created with the recording of 6D inputdevices.
If you want to work with the tools
like a VCR recorder (record and playback animations) the following
must be true:
Since ersion 0.27beta there is a menuitem
Actions -> Animate in white_dune, which create this structure
for the selected node (only when the node has EventIn/ExposedField-Felder
of a type matching a intepolator).
In the Actions ->Animate dialog is asked

if a new TimeSensor with what animation time should be created or
a already existing TimeSensor should be used and what fields should
be animated.
When only the recordbutton is pressed
,
during the creation of a animation, you have to change the timecursor
first and then input a value (via
keyboard, mouse or 6D inputdevice).
When the recordbutton is pressed together with the playbutton
, the change of the values
(via mouseinput or 6D inputdevice) is recorded
continuesly.
The recording of the mouseinput require a calm hand.
It is not uncommon to want to delete some of the recorded values.
You need to select a time range by pressing the left mousebutton and
dragging the mouse left/right in the channelview window and then use
either the
Edit -> delete menuitem or the delete icon.
The matching values will be deleted.
ColorCircle (new in Version 0.19beta)
There is a special inputwindow for colors, it takes place of the
fieldView Window. To get it, a colorfield must be selected in the
fieldView Window and the Colorcircle Icon must be pressed.

With a mouseclick, you can select a color in the color circle and
in the bar beside it, you can select a darker variant.

Currently, when not using a true/directcolor display on Unix/Linux,
the display of the color circle is slow....
When the "OK" button is pressed, the normal fieldView window returns.
Script Editor (new in Version 0.22beta)
There are two ways to start the scripteditor:

-
To create a new scriptnode:
Via the "Script" icon (menuitem Create -> Programming -> Script),
-
To change a existing scriptnode.
If a script node is selected, via the "Object Edit" icon
(menuitem Actions -> Object edit),
The scripteditor dialog

allows it, to add new fields/events to the scriptnode (add),
to change them (change) or to delete them (delete).
Press "OK" to finish the work on the script node.
URL Editor (new in Version 0.22beta)
The "url"-field (it can contain the ECMAscript (javascript) code
of a scriptnode) can be changed in a texteditor.
Via the menuitem options -> Texteditor Settings
it is possible to select the texteditor.
When the "url"-field is empty, a scheme of a ECMAscripts will be created.
To start the textedit, select a Script Node and use the "URL Edit" icon
(menuitem Actions -> Url edit).

Field pipe(new in version 0.29beta)
One of the most powerfull ways to change field values is the field pipe.
It allows you to change field values by any external program.
Usually there is no matching external program yet, so the field pipe is
mainly important for a user with programming capabilities.
If you select a SFField or MFField in the fieldview window and use
Actions -> field pipe one line with the fieldvalue is written to
a file in case of a SFField. In case of a MFField as much lines as the
number of SF-values in the MFField are written to the file.
For example, if you select the following TextureTransform.scale field

(a SFVec2f field) the values
1 1
are written to the file.
For example, if you select the following Color.color field

(a MFColor field) the values
0 0.5 0
0.5 0 0
0 0 0.5
0.5 0.5 0
0.5 0 0.5
0 0.5 0.5
are written to the file.
The file ends with a newline character.
When using Actions -> field pipe, a dialog is opened, that asks
the user for a commandline. This commandline can be used to start a
compiled program (e.g. written in programming languages like Ada, C, C++
or Fortran) or a interpreter with a program in a interpreted language
(e.g. written in programming languages like awk, perl or python).
The given commandline is internally started with
commandline < file > outputfile
which processes each line of the file as standard input with the given
commandline and writes the standard output result to the outputfile.
If the written outputfile has the same/matching structure as the
processed field/inputfile (e.g. for the SFVec2f example
2 1
or for the MFColor example
1 0.5 0
0.5 1 0
0 0 0.5
0.5 0.5 0
0.5 0 0.5
0 0.5 0.5
where it is important, that Color values are floating point values
in the range between 0 and 1. The content of the outputfile is
used as new fieldvalue and the intermediate input/output files are
removed.
The most simple example of a field pipe is simply using the "echo" system
command.
The commandline
echo some th ing
simply writes back the arguments
some th ing
In a very simple example, this can be used to change the values "1 1" to
"2 1" by useing
echo 2 1
as the commandline in the field pipe dialog.
For the following more complicated (but more realistic) example, the
awk programming language is
used, a interpreted language rather similar to the C language. Awk is
very handy for this task, cause it splits a input line automatically into
values and accepts complete programs given on the command line.
If you use the following commandline
awk '{print $1 + 0.1 , $2 + 0.2 , $3 + 0.35}'
as field pipe for the following MFColor field
0 0.5 0
0.5 0 0
0 0 0.5
0.5 0.5 0
0.5 0 0.5
0 0.5 0.5
the result would be
0.1 0.7 0.35
0.6 0.2 0.35
0.1 0.2 0.85
0.6 0.7 0.35
0.6 0.2 0.85
0.1 0.7 0.85
E.g. if this MFColor field would be used as the colors of the corners
of a IndexedFaceSet Box, the command would make all the corner colors a bit
more bright, a bit more green and more blue.
The same example in the C language would require to write a program like
the following:
#include
int main(int argc, char** argv)
{
while(!feof(stdin)) {
float c1, c2, c3;
scanf("%f %f %f", &c1, &c2, &c3);
printf("%g %g %g\n", c1 + 0.1, c2 + 0.2, c3 + 0.35);
}
return 0;
}
If this file is named main.c you would need to compile the file (e.g. with
a command like
cc -o /tmp/a.exe main.c
on the commandline) and you would have to use something like
/tmp/a.exe
in the field pipe dialog.
Before you can use the scripteditor dialog, you need plan what
are the datatypes and eventIn/eventOut informations of the nodes
you want to connect. To do this, you need to read the
node description of the
VRML standard (e.g. you can use the menuitem
Help -> name of currently selected Node or use
a advanced book).
For fast experimenting, you may find it more convenient to use a
simplified scriptbuilding method.
Create a new "empty" scriptnode with the "Script" icon (or the
menuitem Create -> Programming -> Script).
Following the
"get out of the way!" philosophy of the orginal dune project,
simply press "OK" on the scripteditor dialog (see above).
Now you can use the RouteView window for further work.

Scriptnodes have a special "connect anything" eventOut.
If you click and drag this with the mouse, a white route will be drawn.

Keep the mousebutton pressed while routing and you see (like "normal" routing),
you can connect this route to eventIns of other nodes,

but (unlike "normal" routing) the color of the route (marking the datatype)
can change with the probed eventIn.

When you release the mousebutton, the route will be established.

In a similar way, you can use the special "connect anything" eventIn
of the scriptnode

and connect it to a eventOut of a other node.

Now you need to edit the "url" field of the script node.
Beside using urledit you can also
select the script node in the SceneTree window, the "url" field in
the FieldView.

and press the "Object Edit" icon (or use the menuitem
Actions -> Object edit).

Now "white_dune" will try to start a external editor - UNIX die-hards use
"xterm -e vi", this is the default under Linux/UNIX ("xedit" for MacOSX,
"edit" for M$Windows)
if $WINEDITOR was not set at first run. You can change the editor with the
Options -> Texteditor Settings ... menuitem.
In the editor window, you will see a schema of the needed
javascript code.
Use Options -> ECMAscript settings to control, if you want
extended comments in the schema.

Use the editor to complete the javascript code and save/quit the
editor - in case of the vi editor use the keystrokes :wq
NURBS Modelling
(partitially new in Version 0.25beta)
-
When used in computergraphics, the term NURBS means a
complicated mathematical formula,
which can be used to store random surfaces and curves in a very compact way.
Especially for a networkstandard like VRML the suppport of NURBS is a
great advantage, cause it avoids the transfer of the data of all
vertices of a surface mesh. Instead only a relative small amount
of numbers have to be transfered. The numbers can be used to account
the data of the vertices.
This is a advantage, cause computerpower raised very much more than
network speed (for example: the computer which sended 1969 the
first Character ("L" from "LOGIN") over the Internetprotocol
was a Honeywell DDP-516 minicomputer with 12KB memory,
a clock of 1.1 Mhz (but needed much clockticks for one assemblercommand)
and the weight of a half ton. This computer used a networkconnection
with 50000 baud. This is approximatly the same as the computerpower of
a simple calculator and networkconnection of a modern telephon modem.
According to "The NURBS book" (by Pigel/Tiller) NURBS reads as
"Noone Understands nonuniform Rational B-Splines".
You do not need to understand completely this mathematics to work with a NURBS
modeller. But it can be useful for the usage of a programm like
white_dune (which has access to all numbers of NURBS surfaces and
curves) to understand the basics.
When you produce a NURBS curve (with
Create->VRML97 Amendment 1 Node->NurbsCurve /OK) and move the little
white boxes and open all numbers in the fieldView

you can see, that a NURBS curve use essentially 4 types of data.
-
controlPoints:
This is the main part of the positions of the points marked with white boxes
(the other part of the positions is the weight).
When you move a box, a part of the curve moves similarly.

controlPoints are the most important elements in white_dune, to
influence NURBS.
-
weight:
These values is responsible for the influence of each controlpoint to the
whole
curve. The word "weight" remembers to the time before the computerage
as curves were made with thin pieces of wood and weights.
When the controllpoint stays at place and the weight is increased,

the curve will be pulled nearer to the controlpoint.
Despite the controlpoint is a the same place, its value has been
changed. The reason is related to the fact there are two equivalent
mathematical
formulas to store NURBS (homogeneous and inhomogeneous form).
-
knot:
Knot values are responsible (among other things) if a controlpoint
hits a line and if there is edge. To force this, the values
has to be repeated "degree" "(order - 1)" times.

-
order: (also (degree+1))
This number is responsible how far reaches the influence of a
controlpoint.

The remaining value "tessellation" has no mathematical, but a
practical background. It is responsible for the number of points/edges
the curve is shown.

The change of this value allows a easy fitting to the graphicspower
of a computer.

Per default (value "0"), white_dune (which should also run on weak computers)
uses too small values of "tessellation".
A example shows a NurbsSurface, that was converted from a sphere.
Some controlpoints were pulled out.

Only with a high value of "tessellation" you see the "real" shape of the object.

-
White_dune let you create a NurbsSurface (e.g. with
Create -> VRML97 Amendment 1 -> NurbsSurface -> plain/OK).
You can change this surface with the mouse,simply drag the white boxes
around.

This changes the controlpoints of the NurbsSurface.

In this type of operation white_dune is most useful to form landscape with
dunes

but is not very useful for most other tasks.
A lot of objects to model require some symetric modelling,
one half of the object should look similar to the other side of the object.
In white_dune, this can be done with Actions -> X symetric modelling.
When this is active, any movement of the controlpoints of one side

will be also applied to the other side,

and it is rather easy to build a rather complicated symetric NurbsSurface.

The X direction for symetric modelling has been choosen cause of the
local input modes.
It is possible to limit the movement of the controlpoints to a line or
a plain.
With only one of the settings Mode -> only x, Mode -> only y
or Mode -> only z (or their icons with one arrow in x (red), y (green)
or z (blue) direction) the movement of the points is limited into this
direction. The direction is not the direction in the global space, it is
the direction of the matching geometry. Only the x, the y or the z value
of the moving controlpoint is changed.
If for example only the Modus -> only y (the second of the
arrow icons) ist used

the movement of the controlpoints is limited to the y-direction.
This is the direction the green arrow of the last Transform node which
match the geometry is pointing to.

When two of the settings Mode -> only x, Mode -> only y
or Mode -> only z (its icons with only one arrow to x (red), y (green)
or z (blue) is used, the points can be moved in the matching plain.
If for example only the Mode -> only x and Mode -> only z
or the first and the third of the arrow icons is used

the movement of the the controlpoints is limited to the xz-plain.
When all or no icon is used,

there is no limit, the movement of the point with the mouse can change
the x, y or z values.
The decision if to move the symetric part of a NurbsSurface is driven
by the decision if the values of the symetric controlpoints/weights is
nearly the same.
They are nearly the same, if the distance of the absolute values is
smaller then a value "Epsilon". The value of "Epsilon" can be set
in the Options -> Preferences dialog.
When symetric modelling has been choosen, multiple points at nearly the
same place snap together and move together.
This can be used to close open NurbsSurfaces,
but multiple controlpoints at one place of a NurbsSurface result in a edge/peak.

A new created nurbssurface exists (according to the
VRML standards) per default only one sided (which is important, when the
surface is not closed): field "solid" is TRUE.

In most cases this is not very useful.
Change the field "solid" in the FieldView to FALSE, to
make the surface double sided.

Often even a two sided surface is not useful to form a shape with a volume.
In this case it is recommended to create a Group

Move the Shape with the NurbsSurface into the Group.

Then copy the Shape with the NurbsSurface once again into the Group.
To do this, drag the Shape icon into the Group icon and then
hold down the control-key ("Ctrl") while the mousebutton is still pressed.

Cause the field "solid" is still FALSE in this example, a common problem of
realtime 3D can be demonstrated when the color of one shape is changed:

Too thin walls (also called "z-fighting").
When you move one controlpoint of one NurbsSurface a bit upward,
to give the shape
more volume, your rendering hardware and software is not capable to
decide, which of the close two surfaces with which color face the viewer.

This effect is not predictable, it can change with the viewing angle,
the used software (e.g. VRML browser or used graphics driver) and even
with the used graphics hardware (graphics card).
To avoid the problem, you have to switch back the both "solid" field to
TRUE and use the "ccw" field ("Counter Clock Wise") to differ between
the upper side and lower side of a one sided surface.

Now you can now move the nonborder controlpoints of the lower NurbsSurface
to give the shape more volume.
You should move the Shapes with the NurbsSurfaces from the Group into a
NurbsGroup.

The NurbsGroup node is in the VRML standard responsible to draw the borders
of the contained
NurbsSurfaces connected, when the controlpoints of the border of the
NurbsSurfaces are identical.
In white_dune, a NurbsGroup also allow X symetric modelling. Changes of
a controlpoint are distributed to all NurbsSurfaces that are directly
(or via a shape node) contained in a NurbsGroup.
This allows to move the controlpoints on the border and keep the whole
thing closed.

At the end, you should not forget to move the NurbsGroup back into
a Transform node, otherwise you can make no move/rotation/scale etc.
animation.

-
When building closed NurbsSurfaces, it can be usefull to start with a already
close shape. White_dune do not allow you to convert a IndexedFaceSet node
to a NurbsSurface (yet), but allows you to convert the VRML primitives
(box, cone, cylinder and sphere) to a NurbsSurface. It also allows
you to convert a NurbsCurve to a NurbsSurface (by revolve).
Since version 0.27beta it also allows to convert a NurbsCurve to a
Superextrusion PROTO (see below) and it allows to convert a SuperEllipsoid
PROTO or SuperShape PROTO (see below) to a NurbsSurface by approximation.
-
box
To convert a box to a NurbsSurface, first select a box in the
Scenegraph

and use the menuitem Convert -> Convert to NurbsSurface.

If you switch off the "6 Plains" checkbox, you get a single NurbsSurface.

If the "6 Plains" checkbox is pressed, you get 6 plains in a NurbsGroup
forming a box.

-
cone, cylinder and sphere
Convertion of this primitives is similar to the convertion of a box,
but the objects are build internally with a revolving line (better NurbsCurve).
For example, in the result of a cylinder conversion

you see that there are controlpoints that reach the surface. This
has been done by the repeat of values in the knotvectors. As a consequence,
a edge will be created at the matching places when the controlpoints are
moved.

-
Creating a NurbsSurface via a revolving NurbsCurve
Currently this method offers the most modelling features.
First a NurbsCurve node has to be selected in the scenegraph

When creating a NurbsCurve (e.g. via
Create -> VRML97 Amendment 1 -> NurbsCurve )
you should take into account, if you want to
continue with X symetric modelling or not.
The NurbsCurve creation dialog

offers you three options: Curve along x, along y, along z axis.
Only if you revolve a curve along the y or z axis, x-symetric modelling
is possible. So you may prefer to create a NurbsCurve only along the
y or z axis.

Drag now the curve points to form the side view of the revolved shape.

Now use Convert -> Convert to NurbsSurface to continue.

To make X symetric modelling possible, you should keep the checkbox
"Flatten Curve before rotation" pressed. It moves all points into one
plain, but keeps the distance from the origin.

As with a converted Sphere, Cylinder and Cone a edge may be created,
when the controlpoints are moved.

-
During modelling with NURBS nodes you may wish to insert new
controlpoints in one direction.

With the menuitem
Actions -gt& NURBS operations -> Elevate (U/V) Degree up
is this possible, without changing the shape.

With the new controlpoints you can make a new notch.

-
NURBS surfaces are often seen as rounded faces. But beside multiple
controlpoints and knotvector values, the setting of
u/vTesselation values
can easily be used to build a object with edges (IndexedFaceSet).

For example, if you convert a sphere node with
Convert -> Convert to NurbsSurface

and set u/vTesselation to low values, you get a only a few faces.

With Convert -> Convert nurbs to IndexedFaceSet you can can
convert the result to a IndexedFaceSet node.

To get rid of the normalssetting, which smooth the colors of the
faces, you need to delete the Normal node from the IndexedFaceSet.

The following table shows what basic-like shapes can be converted from
primitives, when setting u/vTesselation in NurbsSurface
Shape | Converted | uTesselation | vTesselation |
Tetraeder | Cone | 3 | 4 |
4-edged Pyramid | Cone | 4 | 4 |
Hexaeder | Sphere/Cylinder | 3 | 2 |
Octaeder | Sphere/Cylinder | 4 | 2 |
n-egded prism | Cylinder | n | >1 |
| | | |
The implementation of IndexedFaceSet in white_dune do not have
handles (e.g. white boxes to drag things around with the mouse) yet.
When you create a NurbsSurface
Plain (Convert -> VRML97 Amendment 1 -> NurbsSurface -> Plain (Nurbs))
with degree 1

and set the uTesselation to uDimension-1 and set vTesselation to vDimension-1,
the visible edges and the position of the handles (of the nurbsSurface)
are identical, exactly as in a IndexedFaceSet.

With Convert -> Convert nurbs to IndexedFaceSet you can can
convert the result to a IndexedFaceSet node.

To get rid of the normalssetting, which smooth the colors of the
faces, you need to delete the normals node from the IndexedFaceSet.

Unfortunatly,
the convertion from a IndexedFaceSet back to a NurbsSurface is
not implement yet...
-
White_dune has support for 3D-modelling based
on the so called "superformula"
pow(pow(fabs(cos(m * angle / 4.0) / a), n2) +
pow(fabs(sin(m * angle / 4.0) / b), n3), -1.0 / n1)
This formula has been found by a biologist a few years ago and can be used to
form n-symetric shapes similar to shapes in nature like flowers, leafs, insect
bodies, shells or starfishs.

See this range of shapes,
which are all done with the SuperShape PROTO.
Superformula based shapes are not part of VRML97 by itself and are
implemented by a PROTO (self defined VRML97 node) with scripting
("scripted PROTO").
Superformula based shapes can be converted either to a
Extrusion node or to a IndexedFaceSet node. IndexedFaceSet based scripted
shapes can also be approximated to a NurbsSurface node as a starting point
for further NURBS-modelling.
-
The SuperExtrusion PROTO uses the superformula to account a 2D polygon
in the X-Z-plane and form a shape by repeating this polygon in the
Y direction along a curve. The curve is similar to a NurbsCurve and can
be changed by moving the controlpoints. This shape can be converted to
a Extrusion and some of its parameter work similar to a Extrusion.
Unlike the Extrusion node, the scale parameters are not applied to
each spine point, they are smeared over the whole spine.
-
The SuperShape PROTO uses the superformula to account a 2D polygon
in the X-Z-plane and form a shape using the superformula also in
the Y-Z-plane similar to spherical coordinates.

This shape can be converted to a IndexedFaceSet.
-
White_dune also has a PROTO for the superellipsoid, a special case of a
supershape. It can be used to form a sphere,

a box, a cylinder,

a octaeder and rounded forms of this shapes


with only 2 parameters.
Like the SuperShape PROTO the SuperEllpsoid PROTO has a field "border",
e.g. to form a half sphere.

This shape can be converted to a IndexedFaceSet.
Since version 0.29beta also Coordinate based nodes
(like IndexedFaceSet ("Mesh"), IndexedLineSet or PointSet)
can be changed interactivly in the 3D preview window in the same way
as changing the controlpoints of a NURBS shape.
For nodes with very much vertices, this only usefull to change small details.
There are a few handy modelling actions in the Action menu:
-
Flip (x/y/z)
The Flip command can be used for whole scenegraph branches. It changes
all values of the Transform and Shape (sub-)nodes from x to -x, y to -y
or z to -z. This is usefull to mirror a branch of objects after doubling
the branch. When used on difficult objects like Cone or IndexedFaceSets,
flip tries keep things constistent. A Cone can not be flipped in the
y-direction, therefore the cone of a y-flip command is converted to a
NurbsSurface first. For a Surface node like the IndexedFaceSet, flip
takes care about the normal and ccw fields. A Coordinate node in the
IndexedFaceSet also support the Flip command, but you have
to take care about the normal and ccw field by yourself.
-
Swap (xy/yz/xz)
The Swap command can also be used for whole scenegraph branches.
E.g. the xy command exchanges the x and y values in all matching nodes.
-
Flatten (x/y/z)
This command only works for NURBS and Coordinate nodes. It
sets all points in the x, y or z direction to the average of all nodes
in this direction.
-
Flatten to zero (x/y/z)
This command only works for NURBS and Coordinate nodes. It
sets all points in the x, y or z direction to zero.
-
Set Center to (mid min/max x/y/z)
This command requires the combination
Transform -> Shape -> geometrynode
where the geometrynode (e.g. Box, Sphere, IndexedFaceSet etc.) is selected.
The command set the center (rotation point) of the Transform node to the
mid or the borders of the bounding box of the geometry. This is usefull
when working with modelling tools, which export VRML objects with the
rotation point wide away from the object.
Array tool(new in Version 0.27beta)
White_dune allows to multiply objects. In difference to similar functions
in some 3D-Modellers (like the "Art of Illusion" program) it do not create
N copies of the same object. It creates N VRML Transform nodes (for
translation, rotation etc. in respect to the Array dialog below.)
with a VRML USE construct. A USE construct is a compact way to repeat
things in VRML. It is a sort of "pointer without difference" similar
to a hardlink to a UNIX file (if you know only M$Windows: a more smart way
of a shortcut to a file). A USEd node also changes, when it orginal
changes.
To use the Array tool, select the object you want to multiply

and use Actions -> Array. A dialog will occure

where you can input the number of objects and the parameters for the
transform node.

When you change the orginal, all USEd nodes change too.

(new in Version 0.29beta)
In VRML/X3D it is amaizingly different to build sequences of animations,
usually called "movie". According to the realtime 3D nature of VRML/X3D
animations can be started interactivly and independendly from each, so
it there is difficult to define a overall timeline, just like the cutting
of a movie.
One approach to ease this problem in white_dune is the usage of the
scripted PROTO node VrmlCut. It has a Field "scenes", where single
animation VRML/X3D data can be put into other scripted PROTO nodes named
VrmlScene. The content of such a VrmlScene node can be seen similar to
a single scene in a movie. The VrmlCut node switches from one VrmlScene to the
next VrmlScene and try to jump to the first camera viewpoint and try to start
all the animations in the current VrmlScene node.
Just like the SuperShape, SuperEllipsoid, etc. node the VrmlCut node is not a
buildin VRML node. It is a PROTO, a sequence of VRML nodes, that is composed
by a Switch node and a Script node and TimeSensor node.
Like a Script node it has a changable set of fields/events. Cause multiple
VrmlCut nodes would have multiple different sets of fields/events, you can
have only one Proto definition of VrmlCut and therefore you can have only
one VrmlCut node per VRML-file.
The VrmlCut switches between a sequence of VrmlScene nodes (basically a
Group-like node with some scripting for routing) driven by the internal
TimeSensor and the Script.
All information between the VrmlCut, VrmlScene, TimeSensors (for animations)
and Viewpoints (cameras) are passed via ROUTE commands. This makes the
concept flexible (for example the ROUTE sources can be reused to drive other
nodes like Sound or Fog) but building much ROUTEs is much work.
To reduce the work, the following method can be used:
-
Build single scenes, each in one VRML file
-
Open a VRML file with common background (or empty)
-
Use Create -> Scripted PROTOs -> VrmlCut to create a VrmlCut node
-
Directly use Create -> Scripted PROTOs -> VrmlScene to create a
VrmlScene node
-
Directly use File -> Import to include a VRML file into the
scene. All timesensors and the first viewpoint gets ROUTEs from the VrmlScene
node. The loop field in the timersensors are switched off. The longest
cycleTime of the timesensors are copied into the matching offset of the
scenelengths field of the VrmlCut
-
Directly use Create -> Scripted PROTOs -> VrmlScene to create
the next VrmlScene node.
-
Directly use File -> Import to include the next VRML file.
-
Continue with this steps
At the end, you can use the "play" icon or File->previewto start the
sequence of animations.
With the sceneNumber, numberPreviousScenes and numberNextScenes fields of
VrmlCut can be used play a reduced range of scenes. This is usefull to optimize
the lengths of the scenes in the sceneLengths field of VrmlCut.
(new in Version 0.27beta)
White_dune has a command (menuitem File -> Upload) to upload a VRML
file to a internet server.
When you upload files to the internet, you are usually ask about a access
password. White_dune has the ability to store the password in a memory
protected from swapspace by mlock/vlock calls.
The swapspace is a
region on the disk where the content of the computer memory can be
swapped out to make space for other running programs.
A intruder can inspect
the swapspace to search for passwords.
Passing a password from one application (white_dune) to a other application
(the upload command) in a secure way is not a easy task in respect to things
like swapspace.
In the upload settings dialog (see Options -> Upload settings...)

the upload command can have two parameters. Each parameter of the upload
commandline is set with the characters "%s".
-
In case of one "%s", this parameter
is replaced by the path of the VRML file, which is created from the
the current white_dune data.
If no password is used, the upload program can either ask for a
password each upload or use a advanced authentication mechanism like
ssh passphrase.
-
If there is one "%s" and there is a password, this password is sended
via standardin to the upload program. Usually the content of
standartin/standardout is not protected from spacespace, so there
is possibly a security risk when using this option.
-
Using two "%s" send the password via a commandline option. On most
Operationsystems, this is a high security risk, cause commandline
options can be read by any other user on the same system.
The last line in the upload settings dialog gives you the ability
to reload a HTML-webpage after the upload. To use it, you have to
type in the HTML tags that will be copied into a HTML file.
For example, the following dialog will copy the data by
white_dune to a VRML file with a static name and will display this
VRML file together with the string "hello" in the webbrowser on the next
File -> upload command.

The HTML tags line can contain "%s" characters, which would be replaced
by the password. This would result in a HTML file with the password in it.
This is a very high security risk, do not use
this feature without knowing exactly what you are doing !