home  

Shout3D™ 2.0 - New in 2.0

What's New?

Shout3D 2.0 contains a number of improvements over the 1.0 release of Shout3d. This document describes every one of those improvements. Click here to see a list of links to the new feature desciptions.

A note on the Shout3DWizard: The Shout3D 2.0 Shout3DWizard has several new enhancements.  This document contains a summary of these for quick reference. All of the documentation about the wizard (in the QuickStart Tutorial and in the User Guide ) is completely up to date.  Even if you've used the Shout3DWizard before, you might want to step through the new tutorials to try out the new "optimize archive" feature. 

A note on the documentation:     The documentation in this release is not quite complete.  This situation will be repaired in our final release.  The information in the javadocs is thin on many of the node classes, and the nodes reference in the Shout3D specification is not completely up to date.

New Features in 2.0

Some enhancements have been added with each incremental release of Shout3D. The items below are grouped by the release in which they were added, with the most recent changes first. Each item is followed by the release number in which it was added. 

New Demos in 2.0

3D Studio Max Plugin (2.0)

Shout3D 2.0 includes a new plugin for 3D Studio Max users.  This plugin allows you to export directly to Shout3D from 3D Studio Max.  The plugin lets you author lots of Shout3D's new rendering capabilities right in 3D Studio Max, with the assurance that your content will look the same in Shout3D as it does in Max.  Documentation for the plugin can be found in the Shout3D User Guide's 3D Studio Max Plugin page.

Interactive Render Demo (2.0)

This is an interactive demo that lets you explore some of the new features in Shout3D 2.0.   To launch the demo, click here.  For more information about the demo, go to the demo page .

Other New Demos (2.0)

There are lots of other new demos in Shout3D 2.0.   The demos pagelists all the standard demos from Shout3D 1.0.    Also, each new feature described in this document's New Features in 2.0 section contains a link to a relevant section or demo in the demos page.

New Features in 2.0

Multi Texturing with MultiAppearance (2.0)

Shout3D 2.0 includes a new kind of appearance node named MultiAppearance.  This node lets you perform multi texturing by combining diffuse textures with bump mapping, environment mapping, alpha mapping, and specular level mapping in any combination.  The MultiAppearance also supports specular highlights.   There are tons of demos in the directory Shout3d_runtime/demos/renderTests directory.  There is also an interactive demo that lets you play with all the different kinds of maps and parameters.   Click hereto launch the interactive demo, or click herefor more information about that demo.  Other demos are listed in the next section about the MultiMesh geometry.

!!! Note !!! - there is no other documentation about these nodes yet, but you can hunt down demos in the demo directory. 

MultiMesh geometry (2.0)

Shout3D 2.0 contains a new kind of geometry called MultiMesh.  This geometry allows you to:

  • define smoothing groups
    Smoothing groups are sets of polygons whose edges are smooth shaded.  This allows finer grain control of shading than the VRML97 creaseAngle.
  • assign different appearances to different sets of polygons
  • assign different texture mappings to different sets of polygons
  • export your content from 3D Studio Max without loss of information

Most of the examples in the demos\renderTests directory use MultiMesh geometries. Here are a few examples, but there are lots more:   demos\android\android.html,
demos\interactiveRenderDemo\interactiveRenderDemo.html,
demos\renderTests\select_a_panorama_teapot.html,
demos\renderTests\multimesh_battered_chrome.html,
demos\renderTests\multimesh_specbumpmap.html.

!!! Note !!! - there is no other documentation about these nodes yet, but you can hunt down demos in the demo directory. 

Panorama Backgrounds (2.0)

Shout3D 2.0 is capable of rendering Panoramic Backgrounds, by inserting a Panorama node into the scene.  The images for the backgrounds are specified with an EnvironmentCubeMap -- a collection of six image in the left/front/right/back/up/down directions.   Each time Shout3D renders, it takes the current Viewpoint's orientation into account and renders the panoramic background behind the geometric elements of the scene, so the background appears to envelop the world in which the viewer is located.  Examples of this feature may be found by following these links: demos\multiTexturedTemple.html, demos\renderTests\select_a_panorama_teapot.html, demos\renderTests\select_a_panorama_curl.html

Skeletal Deformation (2.0)

Shout3D 2.0 contains the ability to perform skeletal deformation, including that which is authored with 3D Studio Max's Character Studio package.  Shout3D's new 3D Studio Max Exporter Plugin will export the Physique and Biped correctly (see 3D Max Pluginand 3D Max Plugin User's Guidefor more information).  Following this, the exported file will employ the new PhysiqueSkeletalDeformer node to recreate the skeletal deformation effect within Shout3D.  Examples of this exported content may be found at Shout3d_runtime/demos/biped/hopscotch.htmland Shout3d_runtime/demos/biped/pixel_doubled_hopscotch.html

Weighted Morphing (2.0)

Shout3D 2.0 allows multiple morph targets to be combined to form a weighted combination of those targets.  The targets are specified as deltas (or offsets) from a starting set of coordinates.  The result is a flexible and space-efficient way of representing a model that smoothly changes sections of the overall shape in a variety of combinations.  Common applications of this technique are for facial expressions and lip synching.

Shout3D's 3D Studio Max Exporter Plugin will successfully export multiple morph targets into Shout3D files that will play back exactly the same in the Shout3D 2.0 applets.

The technique is performed with the new ChannelDeformer and TranslationArrayDefChannel nodes.  A ChannelDeformer contains a starting set of coordinates and a set of one or more TranslationArrayDefChannel nodes.  Each TranslationArrayDefChannel has a set of offset translations relative to the starting coordinates, and also a weight with which to apply those offsets to the starting coordinates.  The ChannelDeformer combines the effects of all TranslationArrayDefChannels to produce a new shape.  By animating the weights of several TranslationArrayDefChannels, complex shape changing may be realized.

Examples of this technique, exported from 3D Studio Max with our new exporter, may be found at: Shout3d_runtime/demos/morphtargets/morph_box.htmland Shout3d_runtime/demos/android/morph_android.html.  Other examples may be found in the Shout3d_runtime/demos/morphtargets directory.

H-Anim Suport (2.0)

Shout3D 2.0 contains an implementation of nodes required for the H-Anim 1.1 Specification.  The nodes provided are in the shout3d.hanim package.  and are named Displacer, Humanoid, Joint, Segment, and Site.   The new HAnimExamineApplet is a special applet which will print a description, H-Anim style, of any scene loaded into it that contains an H-Anim humanoid.   The printout is sent to the Java Console, and source code of this applet (as well as its associated HAnimExaminePanel) is provided in the Shout3d_runtime/codebase/applets directory.

To see an example, click to launch Shout3d_runtime/demos/H-Anim/H-Anim.html, then open the Java Console to see the printed information.

Progressive Antialiase (2.0)

Shout3D 2.0 comes with a new kind of antialiasing, called progressive antialiasing.  This method produces an antialiased image over the course of successive renders.  To use it, you just need to insert a StillCamProgAntialias node into your scene.  The scene will become antialiased whenever the camera stops moving.

Examples may be found in the interactiveRenderDemo, as well as many of the demos in demos\renderTests.

VRML Geometries (2.0)

The following geometry nodes from VRML97 are now included in Shout3D 2.0:

  • Box
  • Cone
  • Cylinder
  • Sphere
  • ElevationGrid
  • Extrusion

These have the same specification as their VRML counterparts, with the following additions:

  • Cone - numSides specifies the number of sides in the cone (default 16)
  • Cylinder - numSides specifies the number of sides in the Cyinder (default 16)
  • Sphere
    • numSidesU specifies the number of sides around the Y axis (i.e., longitudinal sections), (default 16)
    • numSidesV specifices the number of vertical sections along the Y axis (i.e., latitudinal sections), (default 8)

The demo demos\primitiveTest.html lets you change the number of sides in the primitives.

Other demos that use these are demos\multiTexturedTemple.html, demos\primitiveTest.html, demos\elevationGridTest.html, demos\extrusionTest.html, and demos\renderTests\primitives_with_multiAppearance.html

!!! Note !!! - there is no other documentation about these nodes yet, but you can hunt down demos in the demo directory.  They work just like in VRML97. 

NurbsSurface and NurbsLineSet (2.0)

Shout3D contains two new geometries for that draw nurbs.   These are NurbsSurface and NurbsLineSet.  They can be placed within any Shape node just like other geometry nodes.

!!! Note !!! - there is no other documentation about these nodes yet, but you can hunt down demos in the demo directory.

KeyframeInterpolator and timeScale field (2.0)

Shout3D 2.0 contains a new abstract class KeyframeInterpolator serves as the base class for all the pre-2.0 Interpolators as well as all the other new interpolators, with the exception of EulerXYZInterpolator (which aggregates 3 KeyframeInterpolators and is subclassed directly from Interpolator).

The KeyframeInterpolator has a new field, timeScale, which is inherited by all the other KeyframeInterpolators.  The timeScale field allows you to think of your animations in terms of total number of seconds or frames, and therefore to set your "key" time values relative to this total number of seconds or frames.  For more information, see the documentation about the timeScale field in the Javadoc for KeyframeInterpolator .

New Spline (TCB & Bezier) and EulerXYZ Interpolators (2.0)

Shout3D 2.0 contains support for spline interpolation of two flavors: TCB (which stands for tension/continuity/bias) and Bezier.   You can also interpolator the separate XYZ channels of three euler angles with an EulerXYZInterpolator.  The following new node classes add this functionality:

  • BezierScalarInterpolator
  • BezierVecInterpolator
  • EulerXYZInterpolator
  • TCBOrientationInterpolator
  • TCBScalarInterpolator
  • TCBVecInterpolator

3D Studio Max uses will be pleased to know that all of these interpolators will export seamlessly from the appropriate animation controllers with Shout3D's new 3D Studio Max Exporter Plugin, provided with this release.

Demos for these may be found in the demos\animTests directory.  One example may be found by following this link to demos\animTests\tcb_boxes.html.

!!! Note !!! - there is no other documentation about these nodes yet

Step Interpolators (2.0)

Shout3D 2.0 includes a complete new set of step interpolators.  These interpolators change instantaneously from one value to the next in sudden "steps" without smoothly interpolating the values.  They are useful for scripting sudden changes in a scene, like changing the choice below a Switch node, swapping one node for another, or jumping the camera to a new location.

Also included is the CurrentTimeStepInterp.  This node sends out the current time through its output whenever a the time of a key is reached.  This is useful for triggering other animations or starting the play of sounds in coordination with other animations that may be in progress. 

The complete set of step interpolator nodes is:

  • BooleanArrayStepInterp
  • BooleanStepInterp
  • CurrentTimeStepInterp
  • DoubleArrayStepInterp
  • DoubleStepInterp
  • FloatArrayStepInterp
  • FloatStepInterp
  • IntegerArrayStepInterp
  • IntegerStepInterp
  • NodeArrayStepInterp
  • NodeStepInterp
  • StringArrayStepInterp
  • StringStepInterp

Two examples of these interpolators may be found at: Shout3d_runtime\demos\stepInterpolatorTest\intStepInterpTest.html and currentTimeStepInterpTest.html.  Other demos for these interpolators may be found in the Shout3d_runtime\demos\stepInterpolatorTest directory.

CoordinateNodeInterpolator (2.0)

Shout3D 2.0 contains the CoordinateNodeInterpolator.  It performs the same kinds of tasks as the CoordinateInterpolator, but uses a much more compact format.  The key values are given as references to nodes (in file format this is done with DEF/USE) instead of restatements of the lists of points.  An example may be found here at this link:  demos\coordinateNodeInterpolatorTest.html.

!!! Note !!! - there is no other documentation about this node yet.

FractionRemapper node (2.0)

The new FractionRemapper node lets you take the fraction from a TimeSensor and remap it to drive only a subsection of an interpolator's keyframes.  It is used by the 3D MAX exporter to properly export animations that do not begin at frame 0 in MAX.  But it may also be used to play any subsection of any Interpolator.

The node has 6 fields, inFraction, isPunchedIn, timeScale, startKey, endKey, and outFraction.

FractionRemapper watches for changes to it inFraction field, which is ordinarily routed from a TimeSensor and falls in the range [0,1]. If isPunchedIn is false (the default) the outFraction is remapped to play the specified range of keyframes (startKey to endKey) over the entire animation interval. If isPunchedIn is true, then outFraction is not remapped, however it is only passed through to the interpolator during the specified subsection of the keyframes.  The timeScale field should be set to match the timeScale in the destination interpolator. This way, the startKey and endKey may be expressed using the same timeScale as keys in the interpolator.

SimpleInline Node (2.0)

Shout3D 2.0 contains a new, simple version of the VRML Inline node, named SimpleInline. The SimpleInline has a "url" field that denotes an .s3d or .wrl file.  The contents of that file are fetched, parsed, and set as the children of the SimpleInline file whenever the url field's value changes, and also when the SimpleInline node itself is read in from file.  Following this, the children of the SimpleInline are treated like the children of any other Group node.  When the url field value changes, the new file is read/parsed, and the old children of the Inline are replaced by the children that were read/parsed from the file.

A simple example of one file that contains two SimpleInline nodes may be found at ../Shout3d_runtime/demos/simpleInlineTest.html .

The SimpleInline node differs from the VRML version in the following ways:

  • SimpleInline contains no bboxCenter or bboxSize field.
  • SimpleInline reads the contents of the file and sets the result as the children of the SimpleInline node. These nodes can be searched, picked, edited, and generally treated like any other nodes in the scene. This differs from VRML, where the contents of an Inline were treated as a "black box" to which programmers had no access.

createNodeFromString() method (2.0)

The Shout3DApplet and Shout3DPanel each have a new method:

public Node createNodeFromString(String stringToParse)

This method creates and returns a Shout3D node by parsing the string given as an argument. The string should be the same format as a Shout3D s3d or VRML file. 


If the string denotes a node that has children, those children will be added as well. If the string contains more than one top-level node, the returned node will be a Transform node containing all of the top-level nodes in the string. This method always loads the resource in the same thread as the main thread, regardless of the setting of isLoadResourcesInSeparateThread().

A javascript example that parses 3 different strings and loads them into the applet may be found at ../Shout3d_runtime/demos/javascript_createFromStringTest.html.

Resizable Applets (2.0)

Shout3D Applets and Panels may be resized now. 

  • resizing via Java: The panel will change properly if it is resized via the standard Java resize() method. 
  • new applet parameter "panelAutoFillsApplet" - this is false by default.  When true, the panel will always resize to fully fill the Shout3DApplet containing it.
  • API to control the auto fill behavior - setPanelAutoFillsApplet() and getPanelAutoFillsApplet() control this behavior.
  • resizing when users change the browser application size:  To do this, just set the applet size as a percentage of the page, and also set the panelAutoFillsApplet parameter to true.

Demo: there are demos that show how these features work at demos\javascript_resize.html. demos\resizable_full_screen.html,and demos\javascript_pixelDouble_and_resizable.html.

!!! Note !!! - there is no other documentation about this feature yet.

Node Search Path (2.0)

Shout3D 2.0 lets you specify a node search path Node Search Path that specifies where it will look for nodes when reading a file. 

This allows you to place your custom nodes in your own packages instead of just the custom_nodes directory as was required in Shout3D 1.0.  You can even keep your classes in the same directory as your models!

New methods setNodeSearchPath() and getNodeSearchPath() are available for the Shout3DApplet and Shout3DPanel classes. There is extensive documentation on node search paths in the JavaDocs pages for those two classes.

A new applet parameter "nodeSearchPath" allows you to set the path in your html file.

Demos for working with the node search path may be found in the directory demos\nodeSearchPathTests

Render Loop Control (2.0)

In Shout3D 2.0, you pause or unpause the render thread, and while the rendering is paused you can render frames one at a time.  New API on Shout3DViewer (and hence Shout3DApplet and Shout3DPanel) allows you to control this:

  • setRenderLoopPaused() sets whether the rendering loop should be paused.
  • getRenderLoopPaused() returns whether the rendering loop is paused.
  • renderOnce() will render one frame if the render loop is paused.  If the render loop is not paused, there is no effect.

There is an example of this API in action at this link:  demos\pausable_viewer_test.html

ExamineApplet enhancements (2.0)

The ExamineApplet has many new enhancements and some new demos.

  • Three ways to move:
    1. rot = drag
    2. pan = <shift> drag
    3. zoom = <control> + drag
  • Drag Styles
    Mouse motion is interpreted via one of two dragStyles. The dragStyle may be changed with an applet parameter.
    1. "by speed" changes values over time by a velocity. The velocity is proportional to how far the mouse has been moved since mouse down.
    2. "by offset" changes the value once per mouse-movement. The value is saved upon mouse-down, and with each move, the new value is set to be the initial value plus an offset that is proportional to how far the mouse has been moved since mouse down.
  • Rotation Center.
    by default, the camera rotates about the center of the scene's bounding box. The rotationCenter applet parameter lets you change this center.
  • Framing the Scene:
    The starting distance from the camera to the rotation center is calculated to include the entire scene within frame limits, within an offset of backupSlack to allow adjustment. See the backupSlack applet parameter below.
  • Cameras & Scenes:
    Works fine if you bind a new camera or change scenes.
  • resetCamera() is a new method that returns to the original setting of the camera.
  • Applet Parameters:
    • dragStyle (default = "by speed")
      Values are "by speed" or "by offset", corresponding to the drag styles described above
    • rotationCenter (default = undefined, meaning use scene bbox center)
      If present, the parameter should be 3 floats, for example: "0 0 0" If present, rotation is about this worldspace point instead of the scene's bbox center
    • backupSlack (default = 0.1)
      For framing the scene in the panel. If 0, then the scene will fit the frame as exactly as possible. If > 0, then the camera will be backed up further to show more. The value is multiplied by the original framing distance to get a new one. For example, if a distance of 10 frames perfectly, then a backupSlack of 0.1 means that the new distance will be 11.
    • bySpeedZoomDragFactor (default = .05)
    • bySpeedPanDragFactor (default = .025)
    • bySpeedRotateDragFactor (default = .033)
      The above three parameters only apply when dragStyle is "by speed." They specify the amount of zoom, pan, or rotate velocity per pixel moved. For example, dragging 100 pixels * in zoom mode moves the camera at 5 units/second.
    • byOffsetZoomDragFactor (default = .01)
    • byOffsetPanDragFactor (default = .005)
    • byOffsetRotateDragFactor (default = .016)
      The above three parameters only apply when dragStyle is "by offset." They specify the total change in zoom, pan, or rotation per pixel moved. For example, dragging 100 pixels * in zoom mode moves the camera by 5 units.

The new examine applet demos are:

  • examine_demo_offset_style.html
    Shows examiner with "by offset" instead of default "by speed" dragStyle
  • examine_demo_offcenter.html
    Willy with the rotationCenter set off to the side
  • examineWithButtonsDemo.html
    Shows the examineWithButtonsApplet.  This is an applet with buttons to control the dragStyle and rotation center.

WalkApplet enhancements (2.0)

The ExamineApplet has many new enhancements and some new demos.

  • look-around:
    Hold down the <control> key while dragging or click-drag with the right mouse.  The interaction will change to a temporary "look-around" mode, in which left/right and up/down motion will both change the direction of view.  As soon as you release the <control> key or right mouse, the direction of view will return to where it was when you entered "look around" mode.
  • collision detection:
    Camera will collide with and slide along walls. True whether or not terrain following is on.
  • terrain following and gravity:
    By default, camera will follow the terrain and drop via gravity if too high above ground. Terrain following may be turned off via an applet parameter
  • camera space may be rotated:
    The up direction is always based on the local up direction of the camera, so cameras can walk on walls if the transforms above them turn them sideways.
  • robust:
    The applet will continue to work properly if the camera or scene is changed
  • Applet Parameters:
    The following describes applet parameters and their affects:
    • avatarHeight, collideHeight, avatarRadius:
      These are always expressed as lengths in world space.
      • avatarHeight (default 2)
        how far the camera is placed above the ground. When terrainFollowing, this adjusts the camera vertically to hug the ground. When not terrainFollowing, the height stays constant in the camera's local space.
      • collideHeight (default .25)
        Collisions with walls are done in the plane that lies at the level of "collideHeight." When terrainFollowing, collideHeight implies the maximum height of what you can step over.
      • avatarRadius (default 2)
        the closest the camera's collide point may get to a wall.
    • speed controls:
      These control how fast the camera moves in response to mouse drags.
      • forwardDragSpeed (default .05)
        Specifies amount of forward velocity per pixel moved. So dragging 100 pixels moves at 5 units/second.
      • headingDragSpeed (default .0025)
        Specifies amount of rotational velocity per pixel moved. So dragging 100 pixels rotates at .25 radians/second.
    • terrain following controls: 
      • terrainFollowing (default true)
        If true, then the height is kept to be avatarHeight above the ground, where the ground is considered the point of intersection that lies below the camera (where "below" means downward in the camera's local space). If the camera is navigated to a point higher than that above the ground, it will drop based on the value of "gravity." If terrainFollowing is false, then the camera just remains at a constant height of avatarHeight in local space and gravity is ignored.
      • gravity (default -9.8 units/sec-squared)
        If terrainFollowing is true, this controls how quickly the camera will drop when it is higher than avatarHeight above the ground. If terrainFollowing is false, this is ignored.
      • maxClimbAngle (default 0.785 radians or about 45 degrees)
        If terrainFollowing is true, slopes less than this amount may be climbed (i.e., you can walk up them) and higher slopes are treated as walls. If terrainFollowing is false, this is ignored.

The new walk applet demos are:

  • demos/walk_terrain.html
    shows terrain following
  • demos/walk_on_ship.html
    shows walking within a moving/rotating coordinate system.

Viewpoint fovMapping field (2.0)

The Viewpoint node has a new fovMapping field. The field controls which dimension of the applet will correspond to the given field of view.  The fovmapping field has 4 possible values:  "SHORTEST", "HORIZONTAL" "VERTICAL" and "DIAGONAL."

  • SHORTEST:  This is the default value, which matches Shout3D 1.0 as well as VRML.
    Here, the Viewpoint's fieldOfView is used in the shorter of the applets two dimensions, and the other angle is scaled to match. So, if the applet is shorter than it is wide, the vertical angle will match the Viewpoint's fieldOfView, and the horizontal angle will be wider.  And if the applet is taller than it is wide, the horizontal angle will match the Viewpoint's fieldOfView, and the vertical angle will be taller.
  • HORIZONTAL: Here, the fieldOfView is always that of the horizontal view angle, and the vertical angle is adjusted depending on the applet dimensions.
  • VERTICAL: Here, the fieldOfView is always that of the vertical view angle, and the horizontal angle is adjusted depending on the applet dimensions.
  • DIAGONAL: Here, the fieldOfView matches on the diagonal. The vertical and horizontal view angles are adjusted based on the aspect ratio of the applet.

There is a new demo, in demos/javascript_change_fovMapping.html, that lets you play with the 4 different settings.

PostRenderEffect (2.0)

Shout3D 2.0 allows you to create nodes that process the image before it is painted to the screen.  To do this, derive a node from the PostRenderEffect node and then implement the filter() method to change the image.  Examples of how to do this are provided in the custom_nodes directory, and described below.  The PostRenderEffect allows you to process the image in two ways:

  • image process the pixels:
    PostRenderEffect allows you to directly edit the pixelArray of the rendered 3D image.  Two examples are provided:
    • fogEffectTest.html adds an atmospheric effect.  Background pixels and far-away pixels are drawn in a fogColor.  As pixels get closer to the camera, they fade out of fogColor and into view.  The source code for the fog effect may be found at: Shout3d_runtime\codebase\custom_nodes\FogEffect.java.
    • InvertSceneEffect.htmlinverts the color of each pixel in the image.  The source code for the PostRenderEffect that does this may be found at Shout3d_runtime\codebase\custom_nodes\InvertSceneEffect.java.
    • wavySceneEffect.htmlshifts rows of pixels to the left and right to produce a scene that appears to have waves running through it.The source code for the PostRenderEffect that does this may be found at Shout3d_runtime\codebase\custom_nodes\WavySceneEffect.java.
  • draw Java Text or 2D graphics on top:
    PostRenderEffect also passes you a Graphics that you can use to draw 2D Text or 2D shapes on top of the scene using standard Java calls.  or by using Java calls to draw 2D geometry and text over the top of the image.  These examples show how:
    • labelEffectTest.htmldraws a text label on top of the scene.  The source code for this effect, which contains field for changing the font, background, and other characteristics of the label, may be found at Shout3d_runtime\codebase\custom_nodes\LabelEffect.java
    • DEFNamePickerTest.htmldoes a pick into the scene whenever the mouse moves over it.  If the mouse is over an object in the scene and that object has a DEFName, then the effect will draw a label containing that name onto the screen, just above the cursor.  The source code for this effect, may be found at Shout3d_runtime\codebase\custom_nodes\DEFNamePickerEffect.java
    • spriteEffectTest.html draws the contents of an image file as a sprite on top of the scene.  Fields allow you to control the x/y location on screen.  The source code for this effect may be found at Shout3d_runtime\codebase\custom_nodes\SpriteEffect.java.

You can also combine the two types of effect in one PostRenderEffect node.  The following example shows how:

  • invertPlusCrawlingTextTest.htmldinverts the pixels of the scene (image processing of the pixel array) and also draws text on top of the scene (Java calls to the Graphics). The source code for this effect, may be found at Shout3d_runtime\codebase\custom_nodes\InvertPlusOverlayTextEffect.java

Pixel Doubling (2.0)

Shout3D has a new Pixel Doubling feature. When pixel doubling is enabled, the applet will internally render the image at half size, then when it draws the image to screen, it will blow the image back up to full size. 

There are two kinds of pixel doubling: regular and smooth.  The regular pixel doubling just copies each pixel into a 2x2 block of 4 pixels.  Smooth pixel doubling adds filtering for a smoother appearance.  While smooth pixel doubling looks better for many scenes, it is also a little bit slower than regular pixel doubling.

Pixel doubling is controlled by new API on Shout3DViewer.  The new API on Shout3DViewer is comprised of three new methods, setPixelDoubling(boolean enabled, boolean smooth), isPixelDoubling(), and isPixelDoublingSmooth().  These methods are documented in the javadocs for Shout3DViewer, Shout3DPanel, and Shout3DApplet. 

Pixel doubling may also be controlled through the html file via a new applet parameter named "pixelDoubling."   This applet parameter may be set to one of 4 values:

  1. "false" means no pixel doubling
  2. "regular" means regular pixel doubling
  3. "smooth" means smooth pixel doubling
  4. "true" means regular pixel doubling

Examples of regular pixel doubling are provided in the demos directory at: demos\javascript_pixelDouble_and_resizable.html, demos\biped\pixel_doubled_hopscotch.html, demos\renderTests\pixel_doubled_multimesh_battered_chrome.html, demos\renderTests\pixel_doubled_multimesh_multimap.html.

Examples of smooth pixel doubling are provided in the demos directory at: demos\biped\smooth_pixel_doubled_hopscotch.html, demos\renderTests\smooth_pixel_doubled_multimesh_battered_chrome.html, demos\renderTests\smooth_pixel_doubled_multimesh_multimap.html.

VisibilityLimit (2.0)

The visibilityLimit field of the NavigationInfo node is now implemented.  This field sets a far clipping plane for rendering.  The far clipping plane is a plane perpendicular to the view direction, located at a distance of visibilityLimit from the Viewpoint.  Triangles which are fully behind the far clipping plane are not rendered. 

The visiblityLimit used is always that of the currently bound NavigationInfo node.  If the visibilityLimit is 0, then an infinite visibilityLimit is assumed.  A simple test which shows an animated visibilityLimit is provided in the demos section at visibilityLimitTest.html.

Line Numbers With Parsing Output To Console (2.0)

The Shout3D parser produces error and warning messages while parsing and prints these messages to the Java Console.   Examples of these messages are "skipping field" "skipping node" and "failed to parse file."   In Shout3D 2.0, these messages are all preceded by current line number of the file at the time the message is produced.  The messages are the same as in earlier versions, only the line numbers are new.

Texture API for editing Pixels (2.0)

Shout3D 2.0 adds the ability to examine and change the pixels in a texture. This allows for either image processing of the images loaded into the url of an ImageTexture, or for the algortithmic generation of textures without any fetching of texture files at all.

A new class, PixelBasedTexture, has been added as a derived class of the Texture node.  The ImageTexture node is now derived from PixelBasedTexture.  PixelBasedTexture contains the following API for examining the current texture:

  • getWidth()
  • getHeight() 
  • getChannel( int which, boolean getCopy )

The 'which' argument of getChannel may be either RED,GREEN,BLUE, or ALPHA.  And if getCopy is true, it returns a copy of the pixels, otherwise a reference to the pixels.  Using these calls, the texture may be examined (and in the case of an ImageTexture, the results will be the pixels that were loaded from the url).  

PixelBasedTexture also contains a method for establishing new pixels in the texture:

  • setCustomPixels( int width, int height, byte[][]red, byte[][]green, byte[][]blue, byte[][]alpha)

When this method is called, the given pixels will replace the ones in the texture.

The above API provides a way to perform the following types of task:

  • new generated texture nodes -- New nodes may be created that generate textures based on fields.  The new GradientTexture node, with source code provided in the custom_nodes directory, shows how to do this.  The node is subclassed from PixelBasedTexture, and when the gradientColors, width, or height field changes, a new set of pixels is generated and set using setCustomPixels.  See the next section for more info.
  •  generating textures in an applet -- Programmers can create custom textures in an applet by creating an instance of PixelBasedTexture, generating some pixels algorithmically, and setting them in the texture using setCustomPixels()
  • new image processed ImageTexture nodes -- New nodes may be created, derived from ImageTexture, that have the ability to perform image processing on the original fetched texture.  The new TintedImageTexture node, with source provided in the custom_nodes directory, shows how to do this.  The node is subclassed from ImageTexture, and when the tintColor field changes, it creates a new texture based on the original (a copy of the original is stored whenever a new texture is fetched in order to generate the tinted version from the original).  See the next section for more info.
  • image processing of textures in an applet - Programmers can image process the texture in an ImageTexture node by creating an ImageTexture, setting the url field to fetch the texture, and then processing the pixels of the fetched texture after it has been fetched.

GradientTexture and TintedImageTexture nodes (2.0)

Shout3D 2.0 includes the source code (in the custom_nodes directory) for two new nodes derived from PixelBasedTexture   These were created using the new Texture API for editing pixels (see previous section).

Examples of these textures (whose fields may be animated to produce animated textures) may be found in:

demos/textureManipulation/fourGradientTextures.html, demos/textureManipulation/threeTintedTextures.html, demos/textureManipulation/gradientAndTintedMultiAppearance.html

JavaSound nodes can play .wav files (2.0)

JavaSound nodes used to be restricted to playing only sound files of the ".au" format. Now they can play files of the ".wav" format as well.

Picker API Additions (2.0)

The Picker interface has a number of new API additions.  These fall into two categories:

  1. Access to information stored in the Picker
    • POLYGON_INDEX is a new valid parameter for getPickInfo() and setPickInfo(). It refers to the index of the picked polygon within the coordIndex of the picked geometry.
    • getPickPath() returns the path from the last pick performed, or null if no pick has been performed
    • getScene() returns the scene being picked (if not picking from a path set with setPath())
    • getPath() returns the path being picked (if picking from a path set with setPath())
    • isPickPixelBased() returns true if the last pick was based on a pixel, false if it was using a from/to pair of coordinates.
    • getPixelX() and getPixelY() return the values of the last pixel used to perform a pick, 0 if none has been performed.
    • getFromPoint() and getToPoint() return the values of the last from point and to point used to perform a pick.  If the last pick was pixel based, these will correspond to the worldspace location of the camera and a point on the picture plane corresponding to the selected pixel (in world space) respectively.
  2. Utilities for interchange between screen space and world space.
    • getWorldRay() calculates a worldspace ray corresponding to a pixel.  The ray passes from the worldspace camera location through the worldspace location of the pixel on the camera's picture plane. 
    • getProjectedPixel() and getProjectedPixelByNode() calculate the (x,y) pixel of a point in the scene.  Inputs specify a local space coordinate and a path (or node) in whose space the point is specified.  The output is an (x,y) screen location of that point.
    • getProjectedBounds() and getProjectedBoundsByNode() calculate the (xmin,ymin,xmax,ymax) bounds of a node onto the screen.  The result is a screenspace box that is sure to contain the contents of the node at the end of the path. 

Various API Additions (2.0)

Shout3D 2.0 contains a number of small but useful API additions to make programming Shout3D a bit easier.  All of these are documented further in the Javadocs for their respecitive classes. The API additions are:

  • Field.fieldNotify()
    Notifies all fieldObservers watching the field and routes that receive values from the field that the value of the field has changed.  Convenient to call if you manipulate component values of an array field and then you want to just notify the rest of the applet that a change has occured, without calling setValue() directly.
  • TimeSensor.restart()
    This new method will stop any TimeSensor and then start it from the beginning of the animation.  The method works whether the TimeSensor is looping or not, and does not change the looping status.  The method also works even if the the TimeSensor is currently stopped; in this case it has the same net effect as a simple call to start().
  • MouseInput.ENTER and MouseInput.EXIT have been added to the MouseInput class. These new kinds of device input will be passed to registered device observers whenever the mouse enters or exits the Shout3DPanel.  In this case, the DeviceInput will be a MouseInput, with the value of the "which" member variable equal to MouseInput.ENTER and MouseInput.EXIT, respectively.
  • Picker.POLYGON_INDEX is a new valid parameter for getPickInfo() and setPickInfo(). It refers to the index of the picked polygon within the coordIndex of the picked geometry.
  • Picker.getPickPath() returns the path from the last pick performed, or null if no pick has been performed
  • Picker.isPickPixelBased() returns true if the last pick was based on a pixel, false if it was using a from/to pair of coordinates.
  • Picker.getPixelX() and getPixelY() return the values of the last pixel used to perform a pick, 0 if none has been performed.

Shout3DWizard Changes (2.0)

The Shout3DWizard has been changed to provide numerous changes and enhancements. Below is a summary of these changes, however all documentation about the wizard in the QuickStart Tutorial and the User Guide is up to date.

No Wizard for the Mac Yet

This release of Shout3D 2.0 does not yet have a version of the Shout3DWizard that will run on the Macintosh platform. This will be remedied for our final release.

"Optimize Archive" option - generates minimal zip archive of classes for your applet

The new Shout3DWizard is capable of creating a custom zip file when it publishes your applet.  This zip file will contain the exact set of class files required to run the applet you are publishing -- nothing more and nothing less. This custom archive feature allows you to distribute content that downloads to those who visit your site in the most efficient manner possible.

If the "optimize archive" option is set to false (the default), then no custom archive is generated -- a default archive named shout3dClasses.zip will be used.  This is much the same was as it was in Shout3D 1.0.   In this case, publishing is a one-step process: just press the publish button and the published directory will be created.

If the "optimize archive" option is set to true, then the wizard will generate a custom archive for you, as follows:

  1. When you click "publish,"  the wizard will not immediately write out the results to the published directory, rather:
  2. The wizard will launch your applet in a special testing window.
  3. In order to insure that all the required classes are included in the archive, you'll  need to put your applet through its paces and exercise all the functionality of the applet.  So, if you are using an ExamineApplet, you should make sure to click in the applet and rotate the view.  And if you've got a TouchSensor that kicks off an animation, make sure to click on that TouchSensor so that the proper classes are all loaded and run.
  4. If you miss something, the consequences are not dire.  Your applet will never crash, but when a user visits your website and tickles the overlooked functionality, the required classes will need to be fetched in separate trips to the server from the archive.
  5. When you have exercised all the features of your applet, close the window containing the applet.
  6. The Shout3DWizard will now publish your applet with a special archive.  All classes not in the archive will still be present in the published directory.  You should upload the entire directory to your server when preparing your web site.  But if you've exercised all the features of your applet during the testing phase, these classes won't be downloaded to your users' machines.
No Distinction Made between File Types on Input

When you read a file into the Shout3DWizard, you can read in either a .wrl file or a .s3d file.  There's only one option in the File--Open pulldown, and with that command you can read in either kind of file.  The Shout3D 1.0 version of the wizard required you to select either "open vrml" or "open s3d."  This distinction is no longer made and you can read either kind of file using "File-->Open"

Model Directory Remembered from Session to Session

In Shout3D 1.0, the Shout3DWizard would not remember the last directory from which you loaded a model.  The Shout3D 2.0 wizard will remember the directory from the last session.

"Optimize Model" replaces old "convert to s3d" option

The Shout3DWizard will now write out only one version of your model into the published directory.  If "Optimize Model" is false, it will copy the file (.wrl or .s3d) exactly from where it is read.  If "Optimize Model" is true, the Shout3DWizard will strip out all Nodes, Fields, and comments that it ignores upon parsing, and it will gzip the results into a smaller file with the extension .wrz.

"Pixel Doubling" option

The Shout3DWizard has a new "Pixel Doubling" option, with three settings: none, regular, and smooth.  For documentation about Pixel Doubling and these three settings, follow this link.

Changes between 1.0 & 2.0 (2.0)

DiffuseColor no longer modulates texture by default (2.0)

In previous versions of Shout3D, the diffuseColor of Materials would always tint the color of any applied textures.  This was confusing for our users because most modeling packages, as well as VRML97, do not behave this way.  Hence, we have made the default behavior of Shout3D to be that the diffuseColor will NOT affect the color of an applied texture.

However, we have added a field to the Material node named modulateTextureWithDiffuse. The value of the field is false by default.  If you set the field to true, then you will get the old Shout3D behavior wherein the diffuseColor will tint the applied Texture.

API change -- appearance field in Shape is now an array (2.0)

Why: The new MultiMesh geometry allows you to specify different appearances for different sets of polygons within a single mesh.   In order to accomodate this, the appearance field of the Shape node has been changed from a NodeField to a NodeArrayField.  

No Problems with parsing Files: This will NOT cause any problems with reading old Shout3D files, or files that specify a single appearance for a Shape.  The reason that parsing will continue to work is because any ArrayField is capable of reading a value of dimension 1 without putting brackets around it.

Programming API for appearance is affected: If, in your Java code, you are setting or getting the value of an appearance field, you will now get compiler errors because the programming API for setting/getting values of NodeArrayFields differs from that of NodeFields.  In order to port your old code to Shout3D 2.0, you will need to make the following two changes.

Setting the appearance field -- porting from 1.0 to 2.0:  Where you were setting the appearance in Shout3D 1.0 like this:

    myShape.appearance.setValue(myApp);

you would now set the value in Shout3D 2.0 like this:

    myShape.appearance.setValue(new Appearance[] { myApp });

Getting the appearance field -- porting from 1.0 to 2.0:  Where you were getting the appearance in Shout3D 1.0 like this:

    myApp = myShape.appearance.getValue();

you would now get the value in Shout3D 2.0 like this:

    if (myShape.appearance.getValue() == null)
        myApp = null;
    else
        myApp = myShape.appearance.getValue()[0];

Known Bugs & Limitations (2.0)

The following known bugs and limitations will be fixed before the final release of Shout3D 2.0.  In the meantime, you will need to work around them.

  • Color-Per-Vertex not implemented in combination with MultiAppearance or MultiMesh - this feature still works for IndexedFaceSet nodes (and classes derived from IndexedFaceSet) so long as you use a regular Appearance and not a MultiAppearance. 
  • Previewing from the Shout3DWizard into Netscape.  Click here for more info.

Bug Fixes in 2.0

Incorrect Behavior (2.0)

The following features of Shout3D worked incorrectly in previous releases, but have been fixed as of the Shout3D 2.0 release:

  • Group.getCameraBBoxMin() & Group.getCameraBBoxMax() incorrect:  These two methods were failing to transform the bounding box into the space of the Viewpoint node at the end of the pathToViewpoint provided as an input parameter.  Fixed in 2.0.
  • MatUtil.getMatrixAlongPath() incorrect if path included Viewpoint: This method was always assuming an identity matrix for Viewpoint nodes located on the path being evaluated, instead of the correct Viewpoint matrix.  Fixed in 2.0.
  • Picking of non-ccw polygons: The IndexedFaceSet field ccw specifies whether polygons in the geometry are described by the coordIndex as counterclockwise (the default) or clockwise.  If ccw is true, the are counterclockwise.   Picking was incorrect for all polygons in any IndexedFaceSet with ccw set to false.  This had the side effect of incorrect collision detection in the WalkApplet (which depends on picking to do the collision detection).
  • Changing the value of NavigationInfo's headlight field: In earlier versions, changing this field after initially reading the file would have no effect unless you subsequently set the isBound field to true as well. Fixed in 2.0.
  • Case Sensitive Registration Codes: In Shout3D 1.0, the registration codes were case sensitive.  So, for example, if you bought a license to remove the logo strip from www.MY-SITE.com, then this license would not work if the actual domain returned at runtime turned out to be www.my-site.com . This has been fixed with the 2.0 licenses, which will work for any combination of upper/lower case letters.  Licenses for Shout3D 1.0 will remain case sensitive.
  • TimeSensor.stop() followed by TimeSensor.start(): Successive calls to a TimeSensor's stop() method followed by it's start() method, should result in the same behavior as a TimeSensor that has been started from a stopped state. This should be the case whether the TimeSensor was running or not prior to those two calls. Prior to Shout3D 2.0, a running TimeSensor would not behave correctly in response to these calls -- it would just continue to run with re-starting.  This is fixed in 2.0.
  • PointSet -- fixed spec mismatch.  The Shout3D specification says a PointSet will perform color-per-vertex is the number of colors in the Color node is >= the number of points.  Previously, color-per-vertex was only used if the number of colors was exactly equal.  Now, the PointSet behaves correctly in both the == and >= cases.

Exceptions (2.0)

The following cases used to throw exceptions, but have been fixed as of the Shout3D 2.0 release:

  • FieldObservers - Exception removing last FieldObserver: Adding FieldObservers to a given field and then removing all of them could result in an Exception.  Fixed in 2.0.
  • Interpolators - Exception when fraction set if keyValue null: All Interpolator classes would throw an exception in the case where keyValue was set to null and then a value was set on the fraction field.  Fixed in 2.0.
  • Interpolators - Exception when key or keyValue 0 dimension: All Interpolator classes had cases where they would throw exceptions in the case where the key or keyValue field had a dimension of 0 or if the value was null. Fixed in 2.0.
  • ResourceObservers - Exception removing last resourceObserver: Adding resourceObservers and then removing all of them could result in an Exception.  Fixed in 2.0.
  • Routes - Exception deleting a Route in case of fan-out:  If a field was routed out to more than one other field (aka "fan-out"), then deleting any route but the last route that was connected would cause an Exception to be thrown.  Fixed in 2.0.
  • ArrayFields - Exception in getLength() if value null: All 6 ArrayField classes would throw a null pointer exception in the case where the value was null and getLength was called.  Fixed in 2.0.
  • ArrayFields - Exception in getValueByString() if value null: The 5 ArrayField classes BooleanArrayField, DoubleArrayField, FloatArrayField, IntArrayField, and StringArrayField would throw a null pointer exception in the case where the value was null and getValueByString() was called.  Fixed in 2.0.

Minor Errors (2.0)

The following minor errors have all been fixed as of the Shout3D 2.0 release:

  • Netscape on Macintosh error to Java Console when changing cursors: An error was printing to the Java Console in Netscape on the Macintosh the first time that the applet tried to change the cursor.  This would occur when a the cursor was moved over a TouchSensor, Anchor, or the Shout3D logo strip.  The message referred to a caught exception.  The problem has been fixed and the message will no longer be displayed.
  • TimeSensor cycleTime spurious output: The TimeSensor is only supposed to output values to the cycleTime field at the beginning of each cycle.  It was incorrectly outputting a value at the end of the last cycle in the case where looping was not infinite.  Fixed in 2.0.

New Features in 1.0.3

Shout3D works with Spazz3D! (1.0.3)

Shout3D is now integrated into the Spazz3D authoring system. With Spazz3D, you can author interactivity, behaviors, and built-in animations without any programming. The resulting files produced by Spazz3D make use of Shout3D's new Logic Nodes, described in the next section.

Within Spazz3D, you can now just click on "export to Shout3D" to create optimized Shout3D content. Or, to preview and/or publish Shout3D applets directly from Spazz3D, you can click on "launch Shout3DWizard" from within the "File" menu. For more information about Spazz3D, go to www.spazz3d.com.

New Logic Nodes with Demos(1.0.3)

Shout3d has a new set of six logic nodes, complete with a demo showing how each of them can be used. These logic nodes allow input events to trigger the generation of output events. They can be used to specify logic and behavior in a Shout3D file without the use of additional Java or JavaScript programming. The new nodes are listed below. Click the word "doc" to the right of each name to see the new documentation in the Shout3D Specification, or click the word "demo" to see the new "Logic Nodes" section of the demo page.

New Javascript demos (1.0.3)

Shout3d 1.0.3 contains two new javascript demos:

switchTest.htmlThis is a simple demo that switches between two dancing figures by changing the whichChoice field of a switch node. For more info, click here.

segmentedAnimationTest.html  This demo shows how to take one long animation and play back different sections of that animation at different times.  It is particularly useful for users who model and export their animations from 3D Studio Max, because this program exports multiple animations end-to-end as one long animation.  So users who want to switch between those sections can follow this example. Click herefor more info on the demo, and click herefor more info on modeling hints for 3D Studio Max users.

Field values are not copied the moment Routes are created (1.0.3)

In prior releases, the value of a field was copied to the destination field the moment a Route was created. This created incosistencies with the behavior of some VRML97 files. Shout3D now waits until the value of the "source" field is set before copying the value of that field to the "destination" field.

New Node::getViewer() method (1.0.3)

The base node class has a new method, getViewer(), which may be used to retrieve the Shout3DViewer in which the node is being displayed.(1.0.3) See Node.html for more info.

Bug Fixes new in 1.0.3

Missing Polygons (1.0.3)

Some polygons within non-uniformly scaled IndexedFaceSet nodes were being incorrectly culled from the scene, resulting in occasional polygon drop-out as well as incorrect shading. This problem is fixed in the 1.0.3 release.

Funny-colored Polygons (1.0.3)

In the case where an IndexedFaceSet node had a ccw field with a value of false (the default value is true), certain polygons would be rendered in an incorrect color. This is fixed as of the 1.0.3 release.

Fan-In from Interpolators (1.0.3)

Fan-in from Interpolator nodes to other fields was broken. This meant that you could not route multiple Interpolators into the same Transform field, leave the routes in place, and change animations by starting one of several TimeSensors (which in turn controlled different sets of Interpolators). This is fixed as of the 1.0.3 release.

Picking of Billboards (1.0.3)

There was a bug in picking which caused crashes in certain cases where Billboard nodes were used. This showed up when attempting to view Billboards in the WalkApplet, for example. The bug is fixed as of the 1.0.3 release.

Animating Texture Coordinates (1.0.3)

Previous versions of Shout3d would not successfully display animation of texture coordinates. The initial set of coordinates would always be used. As of the 1.0.3 release, you can change Texture Coordinates on the fly (either with CoordinateInterpolator nodes or by setting the values via Java or JavaScript) and they will animate correctly.

New Features in 1.0.2

Registration Codes can work on multiple hosts and domains (1.0.2)

Background: Purchasers of the Profession and Education Editions of Shout3D receive a license to serve Shout3D applets that are free of the Shout3D logo strip displayed along the bottom edge of the applet.  With each license, a registration code is provided that works for a single user on a single domain.

Multiple Domains: In previous versions of Shout3D, each html file could contain only one registration code.  This was problematic, because users would need to upload unique content with unique registration codes to serve the same applets from different domains.  This problem is now fixed, and multiple registration codes may be used in a single html file, allowing the applet to be served, logo-strip-free, from multiple domains.  For more information, read the new sections of the user guide about Multiple Domainsand Multiple Registration Codes.

Multiple Hosts:  A single html file might be served from more than one host on a given domain.  For example, a purchaser of a license for www.manyhosts.com might want their content served from both www1.manyhosts.com and server7.manyhosts.com.  In previous versions of Shout3D, a single domain license would not successfully work for these multiple hosts.  This problem is now fixed. So, for example, a license for www.manyhosts.comwill work for all the above cases.  For more information, read the new sections of the user guide about Multiple Hosts.

Switch Node (1.0.2)

Shout3D 1.0.2 now contains a Switch node in the core library.  This node corresponds exactly to the Switch node from the VRML97 specification.  For an exact specification of the Switch node, see the new section of the Shout3D specification.

New JavaScript demos (1.0.2)

Shout3D 1.0.2 includes two new JavaScript demos, created in answer to questions from the Shout3D message board. Both are located in the Shout3d_runtime\demos directory.  The first, jump_after_animate.html, shows how to jump to a new web page after an animation has finished running.  The second, wheres_the_camera.html, shows how to display the position and orientation of the camera when the user clicks a button.  For descriptions of all the JavaScript demos, see the JavaScript section of the Shout3D demo guide.

getNodeByName() no longer throws exceptions (1.0.2)

The getNodeByName(String name) method on CoreShout3DViewer (implemented in both Shout3DApplet and Shout3DPanel) searches for a node with the given name.  If no node can be found in the scene with the given name, this method used to throw an exception.  This behavior has been changed to simply return null when the node can not be found.  This new behavior allows you to test for a node's presence without the risk of throwing an exception.   In practice, it is now a good idea to always test the results of getNodeByName().  In some cases, the correct behavior is to throw an exception, as when the program can do nothing useful if the given node does not exist.  In other cases, graceful action may be taken by the program, such as skipping an action but continuing on.  The source code of the following demos have all been changed to test the results of getNodeByName():  Shout3d_runtime\codebase\applets\ModDunkPanel.java, Shout3d_runtime\codebase\applets\LightTestPanel.java, and Shout3d_runtime\demos\javascript_demo.html.

Shout3DWizard no longer converts files by default (1.0.2)

Background: Many of our users were confused by how the Shout3DWizard converts files.  When adding a node of a customized type to a scene (such as a Pyramid), or when adding the hasAlphaTexture field to an ImageTexture node, most people would assume they could edit these things into their VRML files and then run them through the wizard.  Unfortunately, the converter assumes that the input file is correct VRML and strips out any fields or nodes which are not legal VRML97.  So these users would find that the additions they had worked hard to add would be removed.

What has changed:  To avoid the above confusion, we have changed the default behavior of the Shout3DWizard.  The wizard contains a parameter called "convert to s3d."  This parameter was true by default in prior versions, but as of version 1.0.2, the parameter is false by default.  The result is that, when running the Shout3DWizard on a VRML file, that file will not be converted, but rather copied as is into the publish directory.

Compression of VRML files has been added: Because the above change means that much more people will be publishing their content as .wrl files, we have added an automatic feature to the Shout3DWizard.  When the .wrl file is copied to the publish directory, a gzipped version of the same file will be placed there as well, and the applet parameter "gzip_src" will point to that file.  The result is that, when the html file is visited by somebody browsing the web (i.e. with a 4.0 browser or higher), their browser will fetch the smaller, gzipped file instead of the larger file.  This behavior was always present in the Shout3DWizard for files published in the .s3d format, but has been added for files published in the VRML format.

Bug Fixes new in 1.0.2

Other bug fixes (1.0.2)

The following assorted bugs have all been fixed as of the Shout3D 1.0.2 release:

  • TimeSensor's cycleInterval is now a DoubleField: Prior versions of Shout3D specified this field as a FloatField.  This has been changed to match the VRML97 specification, which classifies this field as an SFTime.  The VRML97 SFTime field is equivalent to a Shout3D DoubleField.
  • BeatMonkBash geometry is fixed:  The VRML and Shout3d versions of the content for the BeatMonkBash demo had some subtle errors (missing guns and other bits of geometry).  The files beatMonkBash.wrl, beatMonkBash.s3d, and beatMonkBash.s3z have all been fixed.

Shout3DWizard for Macintosh (1.0.1)

Shout3D 1.0 did not contain a version of the Shout3DWizard that would run on Macintosh machines. The Macintosh release of Shout3D now contains a fully functional, double-clickable, version of the Shout3DWizard. It is located within the Shout3d_wizard directory of the release, and named Shout3DWizard.exe. For a quick tutorial on how to use the wizard, try going through the Shout3D QuickStart Tutorial.

New Features in 1.0.1

8-bit Texture Transparency (alpha texturing) (1.0.1)

Shout3D provides a way to associate different 8-bit levels of transparency with the pixels in a texture, a technique called alpha texturing. The feature is enabled through a field in the ImageTexture node. Complete documentation is provided in the Shout3D specification and Shout3D includes a new demo to illustrate the feature. Click hereto see the documentation and click here to find a link to the demo. Note: This feature was actually present in the first version of Shout3D 1.0, but it was never documented.

New Node: ColorInterpolator (1.0.1)

Shout3D now contains a ColorInterpolator node. It works just like the VRML ColorInterpolator node.

More tips for 3D Studio Max Users (1.0.1)

The User Guide now contains more information to help users of 3D Studio Max export their VRML files effectively for Shout3D. Click hereto see the new, expanded section.

Improved WalkApplet (1.0.1)

The WalkApplet demo source code has been improved as follows:

  • The collision algorithm has been improved
  • There is a new applet parameter, "collideHeight," which allows you to specify the height above the ground plane at which collisions are performed. Click here for more information, located within the user guide.

Bug Fixes new in 1.0.1

Wizard bug fixes (1.0.1)

The following bugs, concerning the running of the Shout3DWizard, have all been fixed as of the Shout3D 1.0.1 release:

  • Wizard wouldn't load files ending in .WRL instead of .wrl: The Shout3DWizard would not recognize files ending in the upper case .WRL suffix instead of the lower case .wrl suffix. This problem is fixed as of Shout3D 1.0.1.
  • Wizard wouldn't load gzipped VRML files: VRML files that were gzipped were not recongnized by the wizard. This problem is fixed as of Shout3D 1.0.1.
  • Wizard wouldn't load files ending in .wrz or .wrlz: Files ending in the suffixes .wrz or .wrlz were not recognized by and would not be loaded into the wizard.This problem is fixed as of Shout3D 1.0.1.

Preview and File Reading bug fixes (1.0.1)

The following bugs, concerning the preview and reading of files by the Shout3DWizard, have all been fixed as of the Shout3D 1.0.1 release:

  • Failure reading 3D Studio Max (version 3.0) output containing animations: When 3D Max 3.0 exports to VRML, it places the Route statements in an unconventional location (within nodes, instead of at the end of the file). Shout3D 1.0 would fail to read these routes -- in some cases it would crash and in others it would simply fail to perform the animation. This problem is fixed as of Shout3D 1.0.1.
  • Failure reading files containing '?' character in DEF names: Files that contained the character '?' in a DEF name would fail to load in Shout3D 1.0. A crash would result. This problem is fixed as of Shout3D 1.0.1.
  • Failure reading files in which normals are specified: This was not a problem if the Shout3DWizard was used to convert VRML into s3d format. It only showed up when you tried to read the VRML file directly into Shout3D (by setting "convert to s3d" to false in the Shout3DWizard, or by editing the html file to make the applet's "src" attribute be a VRML file). Files that contained a value for the IndexedFaceSet's normal field would fail to read and cause a crash. This problem is fixed as of Shout3D 1.0.1.
  • Failure reading files where last line is a comment: Shout3D 1.0 would crash attempting to read any file whose last line was a comment (i.e., a line beginning with the '#' character.) This problem is fixed as of Shout3D 1.0.1.

IndexedFaceSet bug fixes (1.0.1)

The following bugs, which effected the behavior of IndexedFaceSet nodes, have all been fixed as of the Shout3D 1.0.1 release:

  • Crash if <3 coords in a polygon: Polygons in an IndexedFaceSet with less than three coordinates would crash Shout3D 1.0. This problem is fixed as of Shout3D 1.0.1.
  • Prelit Color-per-vertex broken: If an IndexedFaceSet is given color per vertex and in addition the Appearance or Material node is null, then the Shape should be rendered as a pre-lit shape, with the colors being the full value of those in the IndexedFaceSet's Color node. In Shout3D 1.0, such shapes would be rendered completely white. This problem is fixed as of Shout3D 1.0.1.
  • Color-per-vertex with no colorIndex field broken: Color-per-vertex should work for IndexedFaceSets that do not have a filled colorIndex field. In this case, the indices are to be taken from the coordIndex field, so long as each coordIndex is a valid index into the color node. This behavior was not supported in Shout3D 1.0, but is properly supported as of Shout3D 1.0.1.
  • ccw field broken: The IndexedFaceSet's ccw field was being completely ignored. So if the ccw field was set to false (which is not the default) then Shout3D would render the wrong set of polygons. As of the 1.0.1 release, the ccw field works correctly.
  • Incorrect Bounding Box calculation: There was an error in the calculation of bounding boxes for certain cases of IndexedFaceSet, specifically those in which the local space origin was not contained within the bounds of the IndexedFaceSet's coordinates. This could result in incorrect starting positions of the ExamineApplet as well as inefficient rendering caused by incorrect culling of groups.

Other bug fixes (1.0.1)

The following bugs, which effected the behavior of Shout3D applets once a scene was successfully loaded and displayed, have all been fixed as of the Shout3D 1.0.1 release:

  • Crash if Transform's rotation axis not normalized: Rotations such as those in the Transform node's rotation field should be normalized, but this is not a strict requirement.. For example, a rotation of (1,0,0, .5) is the preferable specification of a rotation of .5 radians about the axis (1,0,0), but a value such as (333333, 0, 0, 0.5), which is functionally equivalent but not normalized, should be acceptable. In Shout3D 1.0, such non-normalized values could crash a Shout3D applet. This problem is fixed as of Shout3D 1.0.1.
  • Anchors and frames broken: In VRML, the parameter field of an Anchor node may be used to specify a target frame within an html page. This is done by setting the parameter field to have a string value of the form "target=framename." In Shout3D 1.0, this feature was not implemented, but it has been correctly implemented as of Shout3D 1.0.1.
  • ExamineApplet has bad starting position and orientation: The ExamineApplet should start with the same orientation as the bound Viewpoint (if specified in the file) and then the position to encompass the entire scene. This was incorrect in Shout3D 1.0, and the problem was augmented by an occasional bug that caused incorrect calculation of bounding boxes. Both are fixed as of Shout3D 1.0.1 and the bundled source code for ExaminePanel.java has been updated to reflect these changes.
  • Sound node does not play if loop is TRUE: Sound nodes with the loop field set to TRUE would fail to play at any time. This problem is fixed as of Shout3D 1.0.1.
  • Routed TimeSensor with loop=TRUE and startTime -1 mistakenly plays: A TimeSensor with the loop set to TRUE and a startTime of -1 should not generate output values upon initial readin. However, if such a TimeSensor was connected from a TouchSensor (by connecting the TouchSensor's touchTime to the TimeSensor's startTime) then the TimeSensor would mistakenly send values to its output fields prior to when the TouchSensor was clicked. This problem is fixed as of Shout3D 1.0.1.
  • Interpolators 'stuck' if first value of key field not exactly 0: If the first entry of the key field in any Interpolator node is greater than 0, the interpolator's value field should remain at the value of the first keyValue until the input fraction becomes >= that first key value. In Shout3D, the behavior was incorrect -- a non-zero value of the first entry of key would result in an interpolator that was 'stuck' at the final keyValue for the duration of the animation. This problem is fixed as of Shout3D 1.0.1.


Copyright© 1999-2000, Eyematic Interfaces, Inc.