while this is a cool feature, can be very useful, and ISVs want it all the
time - there is currently no hardware support.
this feature will not receive hardware support until 2002-2003 timeframe at
the earliest. This isnt cheap in terms of gates and does have an impact on
the cache architecture in the graphics card so IHVs arent running to
implement this in silicon. If you want it faster, talk to your IHVs and make
the request.
I suspect you will not see this feature without hardware support.
-----Original Message-----
From: peter [mailto:[EMAIL PROTECTED]]
Sent: Monday, November 06, 2000 9:55 AM
To: [EMAIL PROTECTED]
Subject: Re: [JAVA3D] Memory Issues: same number of normals and coordinates,
even for indexed Geometry?
I would vote for this one ... it would be very useful to introduce this
feature
- it would simplify life a bit :) ....just a bit ..... I VOTE
Peter.
Adam Tegen wrote:
> 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".
