Well it makes me a little nervous. Sounds like this is a significant
undertaking to save some memory in a very specific set of circumstances.
There are many other things that are more critical which need to be done
first. I would say put it on the list, but as a low priority? Thats just
my opinion. If I had to chose between this and sorting the alpha blended
shapes correctly, I think you know which I will choose.
Dave Yazel
Cosm Development Team
> ----------
> From: Adam Tegen[SMTP:[EMAIL PROTECTED]]
> Reply To: Discussion list for Java 3D API
> Sent: Monday, November 06, 2000 12:15 PM
> To: [EMAIL PROTECTED]
> Subject: Re: [JAVA3D] Memory Issues: same number of normals and
> coordinate s, even for indexed Geometry?
>
> Thanks for responding.
>
> Does anyone else listening to this discussion think this would be useful?
>
> Adam
>
> -----Original Message-----
> From: Discussion list for Java 3D API
> [mailto:[EMAIL PROTECTED]]On Behalf Of Kevin Rushforth
> Sent: Monday, November 06, 2000 11:29 AM
> To: [EMAIL PROTECTED]
> Subject: Re: [JAVA3D] Memory Issues: same number of normals and
> coordinate s, even for indexed Geometry?
>
>
> This is a known limitation of the IndexedGeometryArray API. The
> lengths of the coordinates, colors, normal, texcoord arrays must be the
> same even for IndexedGeometryArray objects.
>
> We could look into addressing this in Java 3D 1.3, but it will require
> additional API, at a minimum separate counts for each of coordinates,
> colors, normal, texcoord. It will also require significant changes to
> the implementation; currently, all of the set/get methods for vertex
> data are in the GeometryArray base class. These would either have to
> be modified to know about the separate counts for each component or
> they would have to be overridden in the IndexedGeometryArray class. If
> there is enough demand for this, we could look into doing it (at least
> for the by-ref case).
>
> --
> Kevin Rushforth
> Java 3D Team
> Sun Microsystems
>
> [EMAIL PROTECTED]
>
>
> >Date: Mon, 6 Nov 2000 08:22:10 -0500
> >From: "J. Lee Dixon" <[EMAIL PROTECTED]>
> >Subject: Re: [JAVA3D] Memory Issues: same number of normals and
> coordinate
> > s,
> > even for indexed Geometry?
> >To: [EMAIL PROTECTED]
> >
> >Yep, I can definitely agree with you there. If you are using an
> >IndexedGeometryArray subclass, it would make sense to be able to have
> >multiple faces that point the same direction (i.e. share the same
> >normal).
> >
> >Yet, the API spec says that if your normals.length < (3*vertexcount),
> >you will get an exception. This makes no sense for indexing.
> >
> >Can somebody at Sun PLEASE address this design issue???
> >
> >-Lee
> >
> >-----Original Message-----
> >From: Adam Tegen [mailto:[EMAIL PROTECTED]]
> >Sent: Friday, November 03, 2000 5:34 PM
> >To: [EMAIL PROTECTED]
> >Subject: Re: [JAVA3D] Memory Issues: same number of normals and
> >coordinate s, even for indexed Geometry?
> >
> >
> >Thanks very much for the reply.
> >
> >One thing though:
> >
> >I am using setNormalRefFloat(), so in this example I have to create
> >
> >float[] locations = new float[24];
> >float[] normals = new float[24]; //not 18, because its by ref.
> >
> >so I waste the space for 6 floats (4 bytes each) for 24 bytes.
> >
> >Since I am doing cad data, dealing with possibly hundreds of megs of
> >data,
> >this wasted space can amount to a lot.
> >
> >If anyone at sun could chime in, I would appreciate it. The part I
> >don't
> >understand is why there is this issue in the first place. Indexed data
> >shouldn't care, unless I am missing something. XSG, for instance,
> >doesn't
> >care.
> >
> >Thanks much,
> >
> >Adam
> >
> >
> >-----Original Message-----
> >From: Discussion list for Java 3D API
> >[mailto:[EMAIL PROTECTED]]On Behalf Of J. Lee Dixon
> >Sent: Friday, November 03, 2000 4:55 PM
> >To: [EMAIL PROTECTED]
> >Subject: Re: [JAVA3D] Memory Issues: same number of normals and
> >coordinate s, even for indexed Geometry?
> >
> >
> >Each "vertex" has a location (or coordinate), and optionally a normal,
> >color, and texture coordinate.
> >
> >After looking at the API specs for IndexedGeometryArray, I think it
> >works like this (somebody at Sun feel free to chime in):
> >
> >Vector3d[] locations = new Vector3d[8] { ... 8 locations ... };
> >Vector3d[] normals = new Vector3d[6] { ... 6 normals ... };
> >
> >int index_count = 4 (vertices_per_face) * 6 (faces) = 24;
> >cube = new IndexedQuadArray(locations.length, COORDINATES | NORMALS,
> > index_count);
> >
> >// Now, set the locations.
> >cube.setCoordinates(0, locations);
> >
> >// Now, set the normals. I think what happens here is that
> >// the GeometryArray has allocated space for *pointers* to 8 normals,
> >// but we only fill 6 of them.
> >cube.setNormals(0, normals)
> >
> >int[] location_indices = new int[index_count]
> >{
> > 0, 1, 2, 3, // the quad for the first face,
> > 1, 3, 7, 4, // the quad for the second face,
> > 5, 4, 7, 6, // the quad for the third face,
> > etc....
> >};
> >
> >int[] normal_indices = new int[index_count]
> >{
> > 0, 0, 0, 0, // the normals for the vertices in the first face are the
> >same
> > 1, 1, 1, 1, // second face
> > 2, 2, 2, 2, // third face
> > 3, 3, 3, 3, // etc...
> > 4, 4, 4, 4,
> > 5, 5, 5, 5
> >};
> >
> >So, I think the only *wasted* space is the two normal pointers in the
> >normal array that are not used... Does this sound right to ppl at
> >Sun?????
> >The GeometryArray is (hopefully) allocating the array space, but not the
> >actual members of the normal array. I mean:
> >
> > // They have to do this because the max possible normals the
> > // user will want is a normal for each vertex.
> > myNormals = new Vector3d[vertex_count];
> >
> > // But hopefully not doing this:
> > int i;
> > for(i=0; i<myNormals.length; i++)
> > {
> > myNormals[i] = new Vector3d();
> > }
> >
> >*whew*
> >-Lee
> >
> >-----Original Message-----
> >From: Adam Tegen [mailto:[EMAIL PROTECTED]]
> >Sent: Friday, November 03, 2000 2:18 PM
> >To: [EMAIL PROTECTED]
> >Subject: Re: [JAVA3D] Memory Issues: same number of normals and
> >coordinate s, even for indexed Geometry?
> >
> >
> >A further question:
> >
> >A "Vertex" is a combination of coordinate, normal, etc. right? If you
> >have
> >an IndexedGeometryArray, why does the number of normals need to equal
> >the
> >number of coordinates? The number of indices for each does need to be
> >the
> >same for each, though.
> >
> >Can you explain this to me further? Other scene graphs use per-vertex
> >shading and do not have this restriction.
> >
> >Adam
> >
> >-----Original Message-----
> >From: Discussion list for Java 3D API
> >[mailto:[EMAIL PROTECTED]]On Behalf Of J. Lee Dixon
> >Sent: Friday, November 03, 2000 1:28 PM
> >To: [EMAIL PROTECTED]
> >Subject: Re: [JAVA3D] Memory Issues: same number of normals and
> >coordinate s, even for indexed Geometry?
> >
> >
> >The reason for the number of normals equalling the number of coordinates
> >is that Java3D does per-vertex shading. This allows for smooth shading
> >of curved surfaces, but yes it is a little wasteful for objects like
> >cubes.
> >
> >-Lee
> >
> >-----Original Message-----
> >From: Adam Tegen [mailto:[EMAIL PROTECTED]]
> >Sent: Friday, November 03, 2000 12:11 PM
> >To: [EMAIL PROTECTED]
> >Subject: [JAVA3D] Memory Issues: same number of normals and coordinates,
> >even for indexed Geometry?
> >
> >
> >Hello-
> >
> >I'm doing some tests with Java3D and notices something:
> >
> >The number of coordinates must equal the number of normals (when
> >enabled)
> >etc. At least this is how it seems to be when I use commands like
> >IndexedTriangleArray.setNormalRefFloat(...)
> >
> >While this makes sense for non-indexed geometry, how does this make
> >sense
> >for indexed geometry? A cube, for instance has 8 coordinates, and 6
> >normals.
> >
> >Am I understanding this correctly? Does this mean that java3D eats up
> >unneeded memory? Is there a good reason for this, or is this an area
> >for
> >improvement for future versions.
> >
> >If someone could explain this to me, I would greatly appreciate it.
> >
> >Adam
> >
> >========================================================================
> >===
> >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".
> >
> >========================================================================
> >===
> >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".
> >
> >========================================================================
> >===
> >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".
> >
>
> ==========================================================================
> =
> 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".
>
===========================================================================
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".
