view3dscene 4.2.0

Scene with outlines from glTF (by Luis Fernandez, https://sketchfab.com/3d-models/ftm-0970f30574d047b1976ba0aa6f2ef855)
glTF scene with Mixamo animations
Steampunk glTF scene
Spine Free-Form Deformation animated
Animated 2D Spine creature
Multiple views at the same 3D dungeon

view3dscene is a viewer for many 3D model formats: glTF, X3D, VRML, Collada, 3DS, MD3, Wavefront OBJ, STL and (2D) Spine JSON and sprite sheets (in CGE, Cocos2d, Starling XML formats).

Explore the virtual world with collisions, gravity, animations, sensors, shadows, mirrors, shaders and more. You can also convert all models to X3D.

If you already have Castle Game Engine, then just run view3dscene executable in CGE bin subdirectory. There's no need to download it separately.

Download Stable Version 4.2.0:
Windows (64-bit)
Windows
(x86_64)
Linux (64 bit, x86_64)
Linux
(x86_64)
Raspberry Pi (Linux Arm)
Raspberry Pi
(Linux Arm)
macOS (x86_64)
macOS
(x86_64)
Support on Patreon
Download (Snapshot) Version 4.3.0:
Windows (64-bit)
Windows
(x86_64)
Linux (64 bit, x86_64)
Linux
(x86_64)
Raspberry Pi (Linux Arm)
Raspberry Pi
(Linux Arm)
macOS (x86_64)
macOS
(x86_64)
Support on Patreon

Download also our collection of demo models to test view3dscene!

Documentation:

  1. Downloading and installing
  2. Features
  3. Navigation with keys & mouse
  4. Command-line options
    1. Capturing screenshots and movies of 3D scenes and animations
    2. Converting to X3D
    3. Other options
    4. Deprecated options
  5. Requirements

1. Downloading and installing

No installation is required. Just download and unpack these archives wherever you want, and run the view3dscene program inside. Included is also the tovrmlx3d program, useful for converting 3D models to X3D in batch (command-line) mode.

This is free/open-source software. Developers can download sources of this program. Or just get the code from GitHub.

Demo scenes: our demo models contains a lot of interesting models, you can open them all with view3dscene.

PLatform-specific notes:

2. Features

3. Navigation with keys & mouse

All navigation modes:

Examine navigation mode:

Mouse:
Rotate Left mouse dragging
Move Middle mouse dragging (or Left mouse + Shift)
Zoom Right mouse dragging (or Left mouse + Ctrl; or scroll wheel)
Keys:
Rotate Arrows
Stop rotating Space
Move Ctrl + Arrows
Scale + / -

Walk / Fly navigation modes:

Walk/Fly navigation controls
Mouse:
Forward / backward Drag up / down with left mouse button
Rotate Drag left / right with left mouse button
Move (strafe) left / right Drag left / right with right mouse button
Fly up / down Drag up / down with right mouse button
Raise / bow your head Mouse wheel
Keys:
Forward / backward W / S or Up / Down
Rotate Left / Right
Move (strafe) left / right A / D
Jump / Crouch (or fly up / down) Space / C
Run Shift
Turn Mouse Look On (Ctrl+M) to look around by moving the mouse.
It is usually comfortable to combine it with movement using AWSD keys.
Additional controls:
Increase / decrease moving speed + / -
Increase / decrease avatar height (preferred camera height above the ground) Insert / Delete
Rotate slower (useful to precisely set the camera) Ctrl + Left / Right

We also support 3D mouse devices, see the demo video about 3D mouse inside view3dscene.

There are many more operations with key shortcuts, that work in all navigation modes. Just explore the view3dscene menu, and look at the key shortcuts.

4. Command-line options

All options described below may be given in any order. They all are optional.

4.1. Capturing screenshots and movies of 3D scenes and animations

Command-line options: 

--screenshot  TIME  FILE-NAME
--screenshot-range  TIME-BEGIN  TIME-STEP  FRAMES-COUNT  FILE-NAME

These options allow you to capture a screenshot of the loaded scene. They know about animations stored in 3D files, that's why they take parameters describing the animation time to capture. They are used to take screenshots in "batch mode". (In interactive mode, you can use comfortable menu items Display -> Screenshot....)

For a still 3D scene, you usually just want to use the simpler --screenshot option with TIME set to anything (like zero) and not worry about anything else.

For animations, more possibilities are available. You can capture any frames of the animation by using many --screenshot options. You can also capture a movie by --screenshot-range (as a series of images or, if ffmpeg is installed and available on $PATH, even directly to a single movie file). The biggest advantage of recording movie this way is that the movie is guaranteed to be captured with stable number of frames per second. This is different than using some independent programs to capture OpenGL output, like the fine GLC (nice GLC overview here), as real-time capture usually means that the program runs slower, and often you loose movie quality.

You most definitely want to pass 3D model file to load at command-line too, otherwise we'll just make a screenshot of the default empty (black) scene. So to take a simple screenshot of a scene, at it's default camera, just call

view3dscene my_model.wrl --screenshot 0 output.png

The detailed specification how screenshot options work:

Examples:

Hints:

4.2. Converting to X3D

In interactive mode, you can use view3dscene menu items File -> Save As.. to save (converting if needed) all 3D model formats to X3D or VRML.

You can also change the X3D encoding (from classic to XML or the other way around). Changing encoding is a lossless operation, as the same nodes graph can be exactly expressed in both encodings.

All these conversions can be also performed in batch mode by command-line options described below. You can either use view3dscene with --write option, or you can use separate binary tovrmlx3d. Separate tovrmlx3d may be sometimes more desirable, as it's smaller, not linked with any GUI libraries (so it will work even on a stripped-down system) and has simpler command-line options (as it's purpose is only to convert).

Examples:

# Convert Collada to X3D
view3dscene input.dae --write > output.x3dv
# Same as above, but by tovrmlx3d binary
tovrmlx3d   input.dae         > output.x3dv

# Convert VRML 2.0 to X3D in classic encoding.
# You could add --encoding=classic, but it's not needed
# (it is the default anyway).
view3dscene input.wrl --write --write-force-x3d > output.x3dv
# Same as above, but by tovrmlx3d binary
tovrmlx3d   input.wrl               --force-x3d > output.x3dv

# Convert VRML 2.0 to X3D in XML encoding.
# You could add --[write-]force-x3d, but it's not needed
# (it is implied by XML encoding anyway).
view3dscene input.wrl --write --write-encoding=xml > output.x3d
# Same as above, but by tovrmlx3d binary
tovrmlx3d   input.wrl               --encoding=xml > output.x3d

Detailed docs of view3dscene command-line options for converting:

--write

Do not open any window, only write the 3D model to the standard output as VRML/X3D and exit. Other --write-xxx options affect the generated output. Model will also be processed by --scene-change-* options, if specified (see their docs lower on this page).

--write-encoding classic|xml

Choose encoding of the output file. By default, we use classic encoding.

This option is meaningful only when --write option is also used.

--write-force-x3d

Force output to be an X3D file. This is really useful only when input model is VRML 2.0.

Conversion to X3D is also automatically forced (no need to specify it explicitly by this option) if the chosen encoding is XML (that is, you used --write-encoding=xml). That's because only X3D supports XML encoding.

Summarizing, you only need to use this option when you want to convert VRML 2 to X3D in classic encoding.

When this is used on VRML 1.0 or Inventor models, we'll also convert parts of them to X3D. But the result is not really useful: you will get a file encoded using X3D keywords, but using VRML 1.0/Inventor node names. Real conversion from VRML 1.0/Inventor to X3D is not implemented (yet).

This has no effect when used on 3D models that are already X3D, or that can be only output as X3D (Collada, 3DS, etc.).

This option is meaningful only when --write option is also used.

--no-x3d-extensions

Do not use Castle Game Engine extensions to X3D.

For example we will not use Tangent, flipVertically, gravityTransform in the generated X3D when importing glTF. This makes X3D output valid (but a little less functional) and suitable for other X3D browsers.

This option works at loading, and it is meaningful regardless of whether you used --write. Both view3dscene and tovrmlx3d have this option.

tovrmlx3d has analogous options for converting, but without the write- prefix (as tovrmlx3d is only useful for converting). More precisely:

4.3. Other options

--hide-menu

Hide the top menubar. Useful for full-screen presentations.

--anti-alias AMOUNT

Use full-screen anti-aliasing. You can also configure it from the menu File -> Startup Preferences -> Anti aliasing. Using this command-line option is mainly useful together with --screenshot option.

Argument AMOUNT is an integer >= 0. Exact 0 means "no anti-aliasing", this is the default. Each successive integer generally makes method one step better. But also more demanding — program may run slower (if your graphic card cannot provide context with sufficient number of samples needed for multi-sampling). See Anti aliasing in interactive mode for the meaning of AMOUNT values. Currently, highest value is 4. So AMOUNT numbers above 4 are exactly the same as 4.

There is no guarantee what specific values of AMOUNT exactly mean, as this depends on your graphic card capabilities. The graphic cards themselves don't provide methods to reliably set some specific FSAA method (only hints, like glHint(GL_MULTISAMPLE_FILTER_HINT_NV, ...)) since the general idea is that better GPU models may provide the same or even better results using different methods. From your (user) point of view, you can test each method and just decide which looks best and isn't too slow on your 3D model and graphic card.

--viewpoint VIEWPOINT-NAME

Specifies the name or a number of the viewpoint that will be bound (used) when the scene is loaded.

By default, when this option is not used, we follow VRML/X3D standard and use the first viewpoint found in the file (but not in the inlined files). Of course you can always add nodes to the scene to trigger binding other viewpoints at the beginning (for example, add ProximitySensor with very large size that sends the enter event to the set_bind of chosen viewpoint). Or you can just exchange the order of viewpoint nodes. But sometimes it's not comfortable to edit the scene. Especially if you want to use the --screenshot options to capture a scene, it's useful to be able to choose a viewpoint by this command-line option.

If you use this option: when the given VIEWPOINT-NAME is a number, it is treated as the index of viewpoint to be used (0 means the first viewpoint, 1 means the 2nd viewpoint and so on). Otherwise, VIEWPOINT-NAME is treated as a node name (node name is given by "DEF Xxx" in VRML/X3D, and it cannot start with a digit, so this is unambigous).

In interactive mode, remember that you don't need this option — instead you can use comfortable Navigation -> Viewpoints menu.

As usual all standard options understood by OpenGL programs, OpenAL (3D sound) programs, all programs are also allowed. Run with command-line --help to get full list.

4.4. Deprecated options

--scene-change-no-normals
--scene-change-no-solid-objects
--scene-change-no-convex-faces

Using one of these options changes the scene before it is displayed (or saved to X3D or VRML, if you used --write option). These options are useful when you suspect that some of the informations in scene file are incorrect.

These options change only the scene which filename was specified at command-line. Later scenes (that you open using "Open" menu item) are not affected by these options. Instead, you can use "Edit" menu commands to perform any of these scene changes at any time. Really, these command-line options are usable mostly when you're using parameter --write.

Below is the detailed description of what each scene change does. This is also a documentation what corresponding command in "Edit" menu of view3dscene does.

  • --scene-change-no-normals :

    Scene change: Clear normal and normalIndex fields, remove Normal and VRML 1.0 NormalBinding nodes.

    Effect: view3dscene will always calculate by itself normal vectors. Useful when you suspect that normals recorded in scene file are incorrect (incorrectly oriented, incorrectly smoothed etc.)

  • --scene-change-no-solid-objects :

    Scene change: For VRML 1.0, in all ShapeHints nodes we will set shapeType to UNKNOWN_SHAPE_TYPE. UNKNOWN_SHAPE_TYPE is the default value of this field, so the purpose of this modification is to cancel SOLID values for this field. For VRML >= 2.0, all solid fields are set to FALSE (on all geometric nodes, like IndexedFaceSet, actually all X3DComposedGeometryNode, Extrusion, etc.).

    Effect: program will not use back-face culling optimization. This optimization often saves us time because we don't have to render faces that would be seen from "inside" if these faces are part of some solid object. Unfortunately, many VRML models have objects incorrectly marked as solid. There are also some scenes that were prepared for some special viewing (e.g. as game levels) and so some amount of "cheating" to optimize these scenes was allowed, e.g. to mark some non-solid objects as solid.

    To view such models properly you have to tell view3dscene (using this command-line option) that such objects are not really solid.

  • --scene-change-no-convex-faces :

    Scene change: For VRML 1.0, in all ShapeHints nodes we will set faceType to UNKNOWN_FACE_TYPE. Moreover we will wrap whole scene in Group node and we will add at the beginning node 

    ShapeHints { faceType UNKNOWN_FACE_TYPE }
    For VRML >= 2.0, all convex fields are set to FALSE.

    Effect: All IndexedFaceSet and Extrusion faces will be treated as potentially non-convex. This means that we will load the scene a little longer but all faces will be correctly interpreted and displayed. It's useful when you suspect that some scene faces are non-convex but it's not correctly marked in the scene by VRML author.

Example: I have here some model helicopter.wrl that looks incorrectly when it is displayed because all parts of model are marked as SOLID while they are not solid. So to view this model correctly I can use command
  view3dscene --scene-change-no-solid-objects helicopter.wrl
I can also correct this model once using command
  view3dscene --scene-change-no-solid-objects helicopter.wrl --write > helicopter-corrected.wrl.

Deprecated: I don't think the --scene-change-* options are useful. Doing this operation interactively is sometimes useful (to check bad models), doing it from command-line probably not (you better fix your exporter). Please report if you have a good reason to keep this working.

--camera-radius <float>

When you move in the scene with collision detection, the "user" is treated as a colliding sphere with given radius. Default radius of this sphere is the average size of scene bounding box divided by 100. Using this command-line option, you can set the radius of this sphere to any value (greater than 0). This can be very useful, but be careful: too large radius will make moving (with collision detection turned on) impossible (because every possible move will produce a collision). Too little radius may produce precision-errors in depth-buffer (this can lead to some strange display artifacts).

Deprecated: instead of using this option, consider adding/editing a NavigationInfo node in your scene (camera radius is taken from the first float on NavigationInfo.avatarSize). Editing your scene (or creating a VRML/X3D file that includes the original scene, by Inline node, and only adds some customization) is much more flexible.

--navigation EXAMINE|WALK|FLY|NONE...

Set initial navigation type. Default is EXAMINE. This can be overridden in particular VRML/X3D scene by using the NavigationInfo node. Valid values for this option are the navigation type names for VRML/X3D NavigationInfo.type, see link above.

You can always change navigation mode later, while the program is running: use the menu Navigation.

Deprecated: instead of using this option, consider adding/editing a NavigationInfo node in your scene. Editing your scene (or creating a VRML/X3D file that includes the original scene, by Inline node, and only adds some customization) is much more flexible.

5. Requirements

To play movies (in VRML/X3D MovieTexture nodes) and to record movies (by --screenshot-range option) you have to install ffmpeg and make sure it's available on $PATH.

Copyright Michalis Kamburelis and Castle Game Engine Contributors.

This webpage is also open-source and we welcome pull requests to improve it.

We use cookies for analytics. See our privacy policy.