|
|
|
|
|
|
|
|
view3dscene is a viewer for 3D scene files.
Supported file formats:
VRML 1.0 and 2.0. Usual extensions for VRML files are .wrl and .wrz.
Almost complete VRML 1.0 support is done. VRML 2.0 (aka VRML 97) support is also quite advanced, many nodes and features are implemented (including full PROTO and EXTERNPROTO support), although some large features are still missing (like scripting, interpolators, sensors). See VRML implementation status for detailed list of supported features. See also Kambi extensions to VRML, Kambi VRML test suite, and finally the official VRML specifications.
Kanim (Kambi VRML engine animations) format is handled, animation is played.
Collada (.dae extension). All existing Collada versions (in particular, we support both 1.3.x and 1.4.x versions) are handled. Also, it can be used as converter from Collada to VRML 2.0.
As far as features go, we currently support only geometry with materials. It was tested on various Collada files, in particular on Collada files generated by Blender (both 1.3.1 and 1.4 exporters, some sample Collada models used are in Kambi VRML test suite in collada/ subdir) and on Basic Collada samples from collada.org.
Also many OpenInventor's 1.0 ASCII files (extension IV) are handled. Mainly it's because Inventor 1.0 and VRML 1.0 are very similar formats, but view3dscene handles also some additional Inventor-specific nodes.
3d Studio 3DS format. Not every information in 3DS is handled by view3dscene but most important things, like materials, texture coordinates and texture filenames are supported.
MD3. This is the format used for models in Quake 3 and derivatives (Tremulous etc.). Almost everything useful is read from MD3 file: geometry with texture (coordinates, and texture filename from associated xxx_default.skin file), animation is also read and played.
Wavefront OBJ files. Most useful things are supported: geometry (with texture coords, normal vectors), materials (colors, opacity, texture filenames).
GEO. Some simple format; I don't even know what program writes files in this format, it just happened that I had a few files in this format. No, it's not Videoscape GEO and it's not Houdini GEO.
Among many features are:
There are also very limited editing capabilities. They are intended to be used only as a post-processing of some model. We intentionally do not try to implement a full 3D authoring program here.
There's one small caveat with animations right now: some features (collision checking, mouse picking, ray-tracer — everything that requires some octree) always use the first animation frame, regardless of current animation frame displayed.
Here are archived binaries of the program. No special installation is required, just unpack these archives and run the program. This documentation is also included in the archives (look in documentation subdirectory) for offline viewing.
Sources of this program are available from this page, in case you're interested.
Demo scenes: In my VRML test suite you can find many simple VRML models that demonstrate what can be expressed in VRML 1.0 and 2.0 and what view3dscene can handle and display. These are not any big or beautiful scenes, you can find some (slightly) more impressive VRMLs in data files of my games The Castle, lets_take_a_walk, malfunction.
Simply run without any command-line parameters. Load your model file using "Open" menu item.
You can provide on the command-line file name to load. As usual, dash (-) means that standard input will be read (in this case the input must be in VRML (or Inventor) format).
Also read about view3dscene additional command-line options.
Controls in Examine navigation mode :
| Mouse: | |
|---|---|
| Left mouse dragging | rotate scene |
| Middle mouse dragging (or Left mouse + Shift) | move scene horizontally/vertically |
| Right mouse dragging (or Left mouse + Ctrl) | move scene closer/further |
| Keys: | |
| Arrows / PageUp / PageDown | rotate scene |
| Space | stop rotating scene |
| Ctrl + Arrows / PageUp / PageDown | move scene |
| + / - | scale scene |
| Home | restore default rotation, translation and scale |
Controls in Walk navigation mode :
| Basic: | |
|---|---|
| Up / Down | move |
| Left / Right | rotate |
| PageUp / PageDown | raise/bow your head |
| Home | restore head raise to initial position (neutralize any effect of PageUp / PageDown) |
| Insert / Delete | fly up / down |
| Comma / Period | strafe moving |
| A / Z | jump / crouch (only when Gravity works in Walk mode) |
Note: when mouse look is turned on then
| |
| Additional controls: | |
| + / - | increase / decrease moving speed (has effect on keys Up / Down, Insert / Delete, Comma / Period) |
| Ctrl + Left / Right | rotate slower (useful when you want to set up camera very precisely, e.g. to use this camera setting to render a scene image using ray-tracer) |
| Ctrl + PageUp / PageDown | raise / bow your head slower |
| Left mouse click | pick point, selecting triangle and object |
Now, there's a lot of keys that work independent of current navigation mode. But I will not list them all here. They all can be seen by looking at available menu items. Probably most useful keys (and menu items) are v (switch to next navigation mode), F1 (toggle status text visibility) and Escape (exit).
All options described below may be given in any order. They all are optional.
Take a screenshot of the loaded scene, save it to FILE-NAME, and exit. In other words, this is used to take screenshots in "batch mode". (In interactive mode, you can use comfortable menu item Other -> Screenshot...).
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. TIME (float value) is useful if you load an animation, if you have a static model you can specify anything (e.g. "0"). So to take a simple screenshot of a scene, at it's default camera, just call
view3dscene my_model.wrl --screenshot 0 output.png
Hints:
To control the look of your screenshot, you often want to use VRML nodes like Viewpoint, NavigationInfo, Background. For example, take a look at screenshot_header.wrl VRML file.
You can generate wanted Viewpoint node also by using view3dscene, just set your camera (in interactive mode) the way you like and use menu item Console -> Print Current Camera Node.
To control the size of resulting screenshot, just use --geometry command-line parameter (documented at standard options understood by our OpenGL programs). For example, take a look at mk_screenshot_for_kambi_www.sh script.
To make your screenshot look best, you may want to use anti-aliasing, see --anti-alias option below.
Generally, you can take a look at (complex) example how to make a screenshot from animation in screenshot_for_kambi_www/ drectory.
Option --write-to-vrml means "don't open any window,
just convert the input model to VRML,
write the result to the standard output and exit".
This way you can use view3dscene to convert
3DS, MD3, Wavefront OBJ, Collada and GEO files to VRML, like
view3dscene scene.3ds --write-to-vrml > scene.wrl ,
you can also use this to do some VRML file processing using
options --scene-change-* described below.
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 multisampling). 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.
Using one of these options changes the scene before it is displayed (or saved to VRML, if you used --write-to-vrml 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-to-vrml.
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: For VRML 1.0, all Normal and NormalBinding nodes are deleted. Values of normalIndex field in IndexedFaceSet and IndexedTriangleMesh nodes are deleted. For VRML 2.0, all normal fields are set to NULL.
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.
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 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 and it's not marked in the scene (by setting faceType to UNKNOWN_FACE_TYPE).
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-to-vrml > helicopter-corrected.wrl.
Set initial navigation mode. Default is Examine. You can change navigation mode while the program is running using key v or appropriate menu item.
When you are walking in the scene with Walk navigation model with collision detection on, for the sake of collision detection "user" is treated as a sphere with non-zero 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).
Sets initial state of "Lighting calculate" option. If this is "on", lighting calculations are performed. Every vertex may have different color, depending on surface material, lights set in the scene, camera position etc. If this is "off" scene is rendered without lighting: every triangle has always the same, single color.
Default is true, which is usually much more reasonable. There is also a menu item "Lighting calculate" that you can use to change this setting while the program is running.
These options control triangulating. Two --detail-quadric-xxx options control triangulating of spheres, cones and cylinders: how many slices (like slices of a pizza) and how many stacks (like stacks of a tower) to create. The 3rd option, --detail-rect-divisions, says how we triangulate faces of cubes. It's best to test how your models look in wireframe mode to see how these options work.
Note that my programs do two different variants of triangulation, and they automatically decide which variant to use in each case:
In this variant we do some more triangulation than in "normal" triangulation. E.g. in normal triangulation we don't divide cones and cylinders into stacks, and we don't divide cube faces (because this doesn't give any better approximation of an object). But when over-triangulating, we do such dividing, because it improves how objects look with OpenGL shading.
Set rendering optimization. It's difficult to describe in short what each value means, you can just try them all. They all produce identical results, but some are slower and some are faster.
For more technical details see documentation of TGLRendererOptimization type in VRMLFlatSceneGL unit.
These options specify parameters for constructing octrees. These will be used when loading every 3d file (given on command-line or loaded using "Open ..." menu item).
E.g. you can pass --triangle-octree-max-depth 0 parameter to say that whole triangle octree must always contain only one node (so this only node must be a leaf). This way you de facto turn off using octree. This way you can see that using octree can really speed up collision detection, not to mention ray-tracing.
Default parameters are 10 for triangle-octree-max-depth and 64 for triangle-octree-max-leaf-items-count.
As usual all standard options understood by my OpenGL programs are also allowed. See also notes about command-line options understood by my programs.
Using key s and menu item "Switch flat/smooth shading" you can switch between using flat and smooth shading. Default is to use smooth shading.
Flat shading means that each triangle has only one normal vector and only one solid color. Smooth shading means that adjacent triangles with a similar plane can share the same normal vectors at their common edges. In effect shapes that are approximating some perfectly smooth surfaces (e.g. spheres) may be rendered better with smooth shading. Moreover smooth shading allows triangle to have different material properties at each vertex (e.g. one vertex is yellow, the other one is blue), you can see example of this in my VRML test suite in file vrml_1/materials.wrl.
Group of planes are similar if angle between each pair of planes is smaller than creaseAngle value (of last seen ShapeHints in VRML 1.0, or of the given geometry node in VRML 2.0). For other 3D model formats we use default creaseAngle = 0.5 radians (a little less than 30 degrees).
Note: if VRML file already had some normal vectors recorded (in Normal nodes) then program will use them, in both flat and smooth shading. Usually it's not important but to be sure that proper normals are used you can use menu item "Edit -> Remove normals info from scene".
After pressing key r (or choosing "Raytrace !" menu item) and answering some questions program will render image using ray-tracing. I implemented two ray-tracing versions: classic (Whitted-style) and path tracing. view3dscene will ask you which algorithm to use, and with what parameters.
Rendered image will be successively displayed. You can press Escape to stop the process if it takes too long. After generating image program will wait for pressing Escape, you can also save generated image to file.
What to do to make this process less time-consuming ?
First of all, the simplest thing to do is to shrink the window.
Second, the quality of octree has great influence on rendering time
(and you should note that by default view3dscene uses rather poor-quality
octree, max-depth =10,
max-leaf-items-count =64).
If you want to play with ray-tracer from within view3dscene I suggest
you prepare a script like
view3dscene
--triangle-octree-max-depth 10 --triangle-octree-max-leaf-items-count 20 --geometry 300x300 "$@"
and use it to run view3dscene in "ray-tracer-optimal" mode.
More detailed description of how ray-tracer works is given in documentation of rayhunter.
Here's a link to view3dscene entry on freshmeat. You can use this e.g. to subscribe to new releases, so that you will be automatically notified about new releases of view3dscene.
| Copyright Michalis Kamburelis. This page is considered part of documentation of my programs, and you are free to modify and further distribute it on terms of GNU General Public License. |
Services for the vrmlengine project provided by
See also vrmlengine
project page on SourceForge.