> Delivered-To: [EMAIL PROTECTED]
> Delivered-To: [EMAIL PROTECTED]
> Date: Thu, 23 Aug 2001 12:38:22 -0700
> From: R Vegan <[EMAIL PROTECTED]>
> Subject: Re: [JAVA3D] HashCode for Tuples
> To: [EMAIL PROTECTED]
>
> Hi Paul
>
> Thanks very much again for your help.
>
> Yes, indeed ! I was interested in verifying about the even distribution of
> hashcode values - perhaps prompted by the Integer hashcode implementation
> (as you rightly pointed out) and also because of Robert Uzgalis's article
> (which you would be most certainly aware of ). Looks very good.
>
> Just a thought. There are some implementations which use different primes
> for x, y, and z. Not aware of anything conclusive about their effectiveness.
>
> My normal generator - based on recursively identifying smoothing groups
> surrounding a vertex and generating new indices everytime a hard-edge
> is detected - seems to be working well. I match exactly the coordinate
> and index values from the GeometryInfo. Thanks for your example
> on the simple cube to start with.
>
> I deduce that there must have been some smart coding in GeomInfo in
> creating the coordinate array to fit in with the IndexedGeometryArray.
> For example, to ensure that the coordinate and normal counts
> are the same, the coordinate array is exapnded and filled with zeros
> (actually they could be any dummy values since the coordinate indices do
> not refer to them anyways).
There's actually not much code in GeometryInfo. Internally,
GeometryInfo keeps different length lists for coordinates, colors,
normals, and texture coordinates.
When you create an IndexedGeometryArray, you send in the vertexCount
and all the arrays are allocated to that size. So when you call
GeometryInfo.getIndexedGeometryArray, it finds out which is the longest
array and uses that as vertexCount. The lists are then copied into the
IndexedGeometryArray. Unfilled sections of the lists are left unset,
but it's OK because they are never referenced by the indices.
The memory is still allocated within the IndexedGeometryArray, so
all the lists are the same length internally. GeometryInfo just
doesn't set the sections it doesn't use.
>
> Again, just a thought. If the additional coordinate values filled in,
> instead of being zeros, are the actual coordinate themselves ( which
> would be of course duplicates of the ones that were input), then the
> coordinateIndices and normalIndices can be made exactly identical.
> One would then have to carry along only one of these arrays for
> further processing. On the flip side though, the current design
> is probably aimed at simply returning to the user the coordinateIndices
> array that he sent in as input to GeometryInfo.
The 1.3 API has an added feature called USE_COORD_INDEX_ONLY where
the same index is used for all data arrays, like you describe.
However, the justification isn't to save memory, it's because some
graphics cards (NVidia) can support this in hardware. If you
think about it, the data lists will usually be much longer than
they would've in normal indexed mode. Suppose one vertex uses
coordinate 1 with normal 6 and color 2. Now suppose another
uses coordinate 1 with normal 4 and color 2. And a third uses
coordinate 2 with normal 6 and color 2. With a single index,
you will have to include each coordinate, normal, and color
three times, whereas with separate index lists you'd only need
two coordinates, 2 normals, and one color. With just coordinates
and normals you may save some space, but as the combinations
of different vertex data increases, memory use goes up.
The current design isn't necessarily aimed at returning the same
coordinate indices that were sent in. There are many GeometryInfo
operations that will modify the coordinate indices, like unindexify(),
recomputeIndices(), and compact(). The design goal of GeometryInfo is
to support the utility libraries: NormalGenerator, Stripifier, and
Triangulator. We couldn't use GeometryArray with them because the size
of a GeometryArray is set at construction time and can't be changed.
While designing and building those utility libraries, it became
necessary to simple functionality to GeometryInfo itself that all
utilities would need. Most of this functionality involves changing
geometry data into different formats, and this has proven useful for
many users. In fact, GeometryInfo was originally designed to be much
more opaque - methods like compact(), convertToIndexedTriangles(),
indexify(), and unindexify() weren't originally intended to be public,
but people asked for them so we made them public.
-Paul
>
> Thanks for all your tips
>
> Raj Vaidya
>
> > You shouldn't write any code that relies on a particular implementation
> > of hashCode because it could change. But having used hashCode a lot
> > I'm suspecting that you want to verify that the code produces an even
> > distribution. Some classes in java do not - for example, the last time
> > I looked at Integer.hashCode it just returns the integer. Here's the
> > implementation of Tuple3f.hashCode:
>
> > long bits = 1L;
> > bits = 31L * bits + (long)Float.floatToIntBits(x);
> > bits = 31L * bits + (long)Float.floatToIntBits(y);
> > bits = 31L * bits + (long)Float.floatToIntBits(z);
> > return (int) (bits ^ (bits >> 32));
>
> > So it's using a very well distributed algorithm, combining the
> > idea of multiplying by a prime number and also XOR'ing.
>
> > -Paul
>
> ***************************************************************
> "Copyright (c) 2001 Sun Microsystems, Inc. All Rights Reserved.
>
> Redistribution and use in source and binary forms, with or without
> modification, are permitted provided that the following conditions are met:
>
> -Redistributions of source code must retain the above copyright notice, this
> list of conditions and the following disclaimer.
>
> -Redistribution in binary form must reproduce the above copyright notice, this
> list of conditions and the following disclaimer in the documentation and/or
> other materials provided with the distribution.
>
> Neither the name of Sun Microsystems, Inc. or the names of contributors may be
> used to endorse or promote products derived from this software without
> specific prior written permission.
>
> This software is provided "AS IS," without a warranty of any kind. ALL
> EXPRESS OR IMPLIED CONDITIONS, REPRESENTATIONS AND WARRANTIES, INCLUDING ANY
> IMPLIED WARRANTY OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE OR
> NON-INFRINGEMENT, ARE HEREBY EXCLUDED. SUN AND ITS LICENSORS SHALL NOT BE
> LIABLE FOR ANY DAMAGES SUFFERED BY LICENSEE AS A RESULT OF USING, MODIFYING
> OR DISTRIBUTING THE SOFTWARE OR ITS DERIVATIVES. IN NO EVENT WILL SUN OR ITS
> LICENSORS BE LIABLE FOR ANY LOST REVENUE, PROFIT OR DATA, OR FOR DIRECT,
> INDIRECT, SPECIAL, CONSEQUENTIAL, INCIDENTAL OR PUNITIVE DAMAGES, HOWEVER
> CAUSED AND REGARDLESS OF THE THEORY OF LIABILITY, ARISING OUT OF THE USE OF
> OR INABILITY TO USE SOFTWARE, EVEN IF SUN HAS BEEN ADVISED OF THE
> POSSIBILITY OF SUCH DAMAGES.
>
> You acknowledge that Software is not designed,licensed or intended for use in
> the design, construction, operation or maintenance of any nuclear facility."
>
> ****************************************************************************
>
>
> > Delivered-To: [EMAIL PROTECTED]
> > Delivered-To: [EMAIL PROTECTED]
> > Date: Thu, 23 Aug 2001 11:16:17 -0700
> > From: R Vegan <[EMAIL PROTECTED]>
> > Subject: [JAVA3D] HashCode for Tuples
> > To: [EMAIL PROTECTED]
> >
> > Hi Sun Team:
> >
> > I am interested in finding out explicit info. on how the
> > hashcode for a Tuple object is generated - the API says
> > it is derived from the elements of the object. Are the hashcodes
> > XOR-ed together ? with prime coefficients or none ? Would you
> > please give the details, in particular, for Point3f, Point3D,
> > Tuple2i (?) and Tuple3i (?).
> >
> > Thanks in advance
> >
> > Raj Vaidya
> >
> > ============================================================================
> > Raj Vaidya, PhD
> > R&D
>
> ===========================================================================
> To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
> of the message "signoff JAVA3D-INTEREST". For general help, send email to
> [EMAIL PROTECTED] and include in the body of the message "help".
===========================================================================
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff JAVA3D-INTEREST". For general help, send email to
[EMAIL PROTECTED] and include in the body of the message "help".
