16-9-2003 03:32 Sydney Australia Time
Seamless 2.028 Update ****

Major Re-Write to Vertex Processing Code
Sorry for not having a sooner update for the inevitable bugs that followed 2.027 but I ended up doing another major re-write to the core code. The code that processes vertices and triangles has been redesigned so that only vertices and triangles that belong to relevant parts get processed as opposed to processing every part for the simplest of tasks. By keeping processing more local to where its needed much greater efficiency can be hoped for in any 3d model that contains many parts. I am hoping to make the need for many conventional VRML nodes obsolete by this new approach. Before I thought Transform, Shape, IndexedFaceSet, Coordinate, Color etc. nodes (quite a lot just to make a single shape) would still be needed because skin animation is slower to render than non skin animated objects but with this new design Part nodes should be just as suitable for non skin animation as well as skin animation since nothing is stopping seamless behind the scenes being able to know when to use skin animation and when to not. The advantage of using Part nodes instead of standard VRML nodes is part nodes are much more straight forward to use and clutter the scene tree much less so should be better for both beginners as well as well seasoned vrml artists as far as I can see. Though 2.028 can still only do color per vertex it's design is moving towards being able to have any Part with its own material and or texture effect. Skin animation is possible by allowing the triangles owned by different parts to use a vertex owned by a different part. In future versions of seamless I plan to have it so that a part can use vertices with parts that have their triangles rendered with different effects as well. For example, a part could be set up so that its triangles are rendered using color per vertex but owning triangles that contain vertices owned by a part that is textured or chromed textured or perhaps the same using color per vertex but with a different shine setting. This will make it possible for skin animated avatars to have animated mouths with glossy lipstick without the skin also being glossy.

Evolution to "The Lowest Bidder Owns the Shared Triangle"
In Seamless the triangles between parts have vertices owned by different parts which I call "shared triangles". In all versions of seamless until now, shared triangles were owned by the part who owned the highest in index order vertex. The index order for vertices begin with index 0 which will be in the first part in the top of the skeleton (top line) and increase in order to the highest index which will be in the last part in the skeleton (bottom line). Only days ago it came to my attention when thinking about animated lips with a different shininess settings for the lips to the rest of the skin that there would be a problem with this convention. The lips part being a descendent of the head part means that the shared triangles would be owned by the lips. These triangles would want to be skin colored same as the head and with the same shininess settings as the head but because they are owned by the lips they would have the shininess settings of the lips. To get around this problem I have decided to make 2.028 instead of having "The highest bidder owns the shared triangle" to have it so that "The lowest bidder owns the shared triangle". This upsets some backward compatibility for work more complicated than my simple examples when nodes like the DelPoly node is used but since I have not documented these nodes yet and only I and ep have used them to my knowledge I don't think any big problems will be caused in making this evolutionary change at this stage.

Done away with Seamless's geometry Field.
Seamless II always had a single IndexedFaceSet node for the geometry behind scenes before 2.027 was released which was the first version to make all nodes that existed visible to the user. So it might seem a bit strange at first to hear that I have removed this field completely from concept for 2.028. Having one would only complicate the new way parts are able to have different effects planed for the future. A great bonus of no longer being confined to the conventions of how an IndexedFaceSet node stores triangles is the data for triangles can be stored more efficiently. 2.028 no longer needs an extra -1 value for each triangle in the coordIndex field. What's more exciting than this is I have become free to think of more efficient ways triangles can be stored when using the textureCoordIndex method, a method I did not like much in the past because it seemed to me much more wasteful compared to using the textureCoord per vertex method even taking into account that with textureCoordIndex u don't need an extra lot of wrap around vertices and less likely to need a Normal node like u might with the texCoord per vertex approach but it was the fact that u need an extra 6 index values typically for each vertex that made me not warm to the textureCoordIndex method in the past. I am now hoping to make seamless able to save data much more eficiantly using the texCoordIndex method by saving the data much the same way vertices are saved when using the simpler texCoord per vertex method. This should be made possible by adding an extra field of indices that instruct seamless which vertices to join after the file has been loaded. This should make for much greater efficiency download wise than the textureCoordIndex method and typically less than the textCoord per vertex method if u consider that u typically need a Normal node when using this method to avoid a seam. Though I have done away with the geometry field for the Seamless node, IndexedFaceSet nodes are still used for pre made triangle structures for the Stem node's source field.

Some More Fields added and some Refinements made to existing fields
I have made a few minor changes to some of the field names as well as added a few fields to the Stem node. xPointCnt has been renamed to staves and yPointCnt has been renamed to bands as I feel these names tax the intellect less (if u think of a barrel having vertical staves) the concept of these 2 fields have been refined a bit too. Before xPointCnt meant the number of vertical vertices but now means the number of triangles strips, keeping the logic uniform bands means number of horizontal triangle strips.
These new name changes and concepts should not cause any big problem because seamless 2.028 can tell if the file its loading is from a older version than 2.028 and so will make the necessary changes to the values automatically maintaining backward compatibility to 2.000 for all simple examples. For the more complex buildAv.smls example a modified version of buildAv.smls had to be made because of incompatibilities arising from the new "lowest bidder owns the triangle" convention being implemented. The new buildAv.smls example takes advantage of the new joinEnds field.

The SFBool joinEnds field added to the Stem Node
I have added a SFBool field to the Stem node named joinEnds. The advantage of using this is its much more efficient and simpler to have no begin and end vertices to begin with. This always made sense for color per vertex but I had previous versions have a begin and end vertex for each band unjoined because I thought this was necessary to have for the textureCoord per vertex method which I had planed to add support for in the future but now I am thinking the concept of using textureIndex could make this obsolete for textures the same way it is for color per vertex. This field is set to TRUE by default but should be set to FALSE when flat grids of triangles are wanted for making such things as land.

The SFBool insideOut field added to the Stem Node
I have added to the Stem Node a field named insideOut which is much the same as the insideOut field for the CopyPart node. It reverses the indices making triangles transparent on the opposite side. To keep the words uniform I have also renamed the command reversIndices in the F10 menu to insideOut as this does exactly the same thing.

The MFFloat decay field added to the SineTug Node
Any vertices above the specified location are tugged to the full amount in accordance to the distance field. In previous versions any vertices behind the specified location were left completely unaffected. In 2.028 this will be the same if decay values are set to 0 but values greater than 0 specify a tug affect for a distance (decay distance). The amount of tug affect will reduce less and less until the end of the decay distance is reached to where there will be no more tug affect. This field should make the SineTug node easier to use and more versatile especially when being applied to objects made using the CCLathe node.

Most VRML97 Nodes Can Now be Edited Using Seamless Control Panels
All of the standard VRML97 nodes except for the Script and PixelTexture nodes have been added to 2.028. They wont function but can be edited so that seamless can take the place of using a text editor perhaps with the advantage of preventing the user from writing illegal VRML syntax. If seamless gets to support x3d in the future there will be no need maybe to learn a different syntax this way.
Note Although these VRML97 nodes recently added will exists in the scene tree they don't yet all have their own unique image because I haven't had time to design all the images for them.

Some New Examples and Updated Tutorials for 2.028
I have added some extra files to the seamlessWay.zip files and re saved all old files in 2.028 so that examples are in 2.028 format



[ href="http://www.seamless3d.com">3d Modelling Software] [Tutorials] [Forum] [Features] [Download] [Gallery] [FAQ] [Worlds] [Avatars] [Links] [Thyme]