home # Shout3D™ 1.0 - New in 1.0.2 |

# What's New? Shout3D 1.0.2 contains a number of improvements over the 1.0 release of Shout3d. Some enhancements were added in the 1.0.1 release, while others were added in the 1.0.2 release. Each item is followed by the release number in which it was added. The changes are broken into the following sections, starting with the changes for version 1.0.2. New Features in 1.0.2: Registration Codes can work on multiple hosts and domains (1.0.2) Switch Node (1.0.2) New JavaScript demos (1.0.2) getNodeByName() no longer throws exceptions (1.0.2) Shout3DWizard no longer converts files by default (1.0.2) Bug Fixes new in 1.0.2 Other bug fixes (1.0.2) Shout3DWizard for Macintosh (1.0.1) New Features in 1.0.1: 8-bit Texture Transparency (alpha texturing)(1.0.1) New Node: ColorInterpolator (1.0.1) More tips for 3D Studio Max Users (1.0.1) Improved WalkApplet (1.0.1) Bug Fixes new in 1.0.1 Wizard bug fixes (1.0.1) Preview and File Reading bug fixes (1.0.1) IndexedFaceSet bug fixes (1.0.1) Other bug fixes (1.0.1) ## 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 branding 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, branding-strip-free, from multiple domains. For more information, read the new sections of the user guide about Multiple Domains and 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.com will 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 here to 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, Shout Interactive, Inc.