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]