To answer the questions:
1) The data will always have vertices and normals, textures will be used
sometimes, but most CAD packages (or CAD engineers) rarely use textures.
Colors are usually not per-vertex, so they are never used.
2)Yes, that is my assumption, and I could be wrong. A fair test would be to
change the data into non-indexed geometry just for a test. If we stick to
our current design, this is not possible, but our design might change, and
then this would be one thing to try.
3)As for better data. I compared the stripifier we used to the java
stripifier. There seemed to be no useful speed or memory difference, but at
a glance, the one we used had better results, both in the maximum length of
the strips, and in the number of smaller strips (java3d had more small
strips). I did not check which one had more strips, however, but the reason
for using a third party stripifier was to make a fair comparision for speed
and memory usage.
4)As for the normals, the normals and the facets are generated from Brep
data. Since both are polygonal (which are tesselated and made triangular)
approximations, a NormalGenerator might do unpredicable things, although in
fairness I haven't taken a close look at it. For instance, it might
incorrectly smooth some intensionally "sharp" edges, etc.
5) Geometry was used by reference
Thanks for the help and ideas,
Adam
-----Original Message-----
From: Paul Pantera [mailto:[EMAIL PROTECTED]]
Sent: Monday, November 06, 2000 6:09 PM
To: [EMAIL PROTECTED]
Subject: RE: [JAVA3D] Memory Issues
Ah, OK. So give me more. In the first case you are using indexed
triangles with vertex and normal data? Or do you have texture
coordinates and colors also?
You seem to be assuming that the extra memory usage is coming from the
way we're doing indexed geometry, but I just don't see it. Did you try
un-indexed triangles vs. strips? How about the simplest comparison of
all: indexed strips vs. non-indexed strips? That would prove your
point better.
I'd also be interested in what would happen if you loaded your data
into our GeometryInfo object and ran it through the NormalGenerator and
Stripifier, then pulled out the un-indexed GeometryArray. I wouldn't
be surprised if the normals were better than those generated by the CAD
package and the strips were longer. You might be pleasantly
surprised.
To decrease memory, you could also use Geometry by reference. If
you're not using Geometry by Reference, make sure you GC your
geometry after sending it to Java 3D.
-Paul
> From: "Adam Tegen" <[EMAIL PROTECTED]>
> To: "'Paul Pantera'" <[EMAIL PROTECTED]>
> Subject: RE: [JAVA3D] Memory Issues
> Date: Mon, 6 Nov 2000 16:39:05 -0500
> MIME-Version: 1.0
> Content-Transfer-Encoding: 7bit
> X-Priority: 3 (Normal)
> X-MSMail-Priority: Normal
> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
> Importance: Normal
>
> I created a file from a CAD system which we wrote custom convertor for.
We
> then implemented a loader in the same manner for all of the scenegraphs.
As
> per your question: it is faceted and tesselated by the CAD system. It is
> further pre-processed (for j3d) by a routine I made to compress all the
> duplicate data.
>
> All of the data points were stripped with a program that we have, so that
> the stripping was exactly the same. So there aren't any references to the
> Stripifier, GeometryInfo, or NormalGenerator.
>
> Furthermore, we have implemented a set of leak detection classes.
> Everything is garbage collected (I checked through WeakReferences),
although
> I don't know if it is allocated back to the system.
>
> Adam
>
> -----Original Message-----
> From: Paul Pantera [mailto:[EMAIL PROTECTED]]
> Sent: Monday, November 06, 2000 4:22 PM
> To: [EMAIL PROTECTED]
> Subject: Re: [JAVA3D] Memory Issues
>
>
>
> I may be able to help you with this. I wrote GeometryInfo and
> NormalGenerator. From the discussion, I assume you're using both of
> these, as well as Stripifier. I need a little more info about how
> you're using the utilities. How was the 210M number generated? Did
> you call getIndexedGeometryArray or getGeometryArray, or what? If
> you are calling getIndexedGeometryArray, try sending 'true' to
> the method as the 'compact' parameter. This will fold duplicate
> data points into one, lowering the memory footprint (maybe - depends
> on your data). Also, try calling getGeometryArray instead of
> getIndexedGeometryArray - your geomtry will render faster and it
> may take less memory (again, depending on your data).
>
> Make sure you are removing the GeometryInfo, NormalGenerator, and
> Stripifier objects after you've retreaved your GeometryArray.
>
> -Paul
>
>
> > MIME-Version: 1.0
> > Content-Transfer-Encoding: 7bit
> > X-Priority: 3 (Normal)
> > X-MSMail-Priority: Normal
> > X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
> > Importance: Normal
> > Date: Mon, 6 Nov 2000 14:20:26 -0500
> > From: Adam Tegen <[EMAIL PROTECTED]>
> > Subject: Re: [JAVA3D] Memory Issues: same number of normals and
> coordinates,
> even for indexed Geometry?
> > To: [EMAIL PROTECTED]
> >
> > Hello-
> >
> > Please don't send this to anyone outside of the j3d team. I could
re-post
> > it if you wish, but with some censoring of scenegraph names. Please let
> me
> > know if I could re-post this.
> >
> >
> > In light of the previous discussion, I thought I might elaborate and
give
> > some actual data points.
> >
> > For all those interested, my team as been evaluating scene graphs for
the
> > past 2 months. There are 2 major concerns: memory and speed. J3Ds
speed
> > seems acceptable, and is likely to only get better. Memory usage is
still
> a
> > concern, at times taking 3 times as much memory as our "best"
> > platform-specific solution.
> >
> > To illustrate just memory usage as a concern, here is a table of the
same
> > file loaded in different scene graph technologies, both as triangles and
> > triangle strips. The numbers shown are in megabytes.
> >
> > The columns were tested on the following in order: 1 pump model, 10
pump
> > models, 100 pump models, 1 turbine model, 1 chassis model
> >
> > Hoops: 9.5 23 127 39 136
> > Hoops (stripped) 12 27 164 44 155
> >
> > VTK 7 21 170 27 103
> > VTK (stripped) 6 14 92 16 50
> >
> > Java3d 6 17 159 67 210 <---
> > j3d (stripped) 6 11 103 18 68
> >
> > XSG 7.5 18 109 20 71 <---
> > (stripped) 6.5 11 63 13 39
> >
> > The highlighted data point is the one that concerns me. 210Mb vs. 71
Mbs
> > unstripped, and 68 Mbs vs. 39 Mbs stripped.
> >
> > To clarify for some people out there: This problem applies to
per-vertex
> > shading, for all those concerned. I am absolutely doing per-vertex
> shading.
> > 1) Objects that may have a number of planar faces, where re-using the
> > normals would make a large difference -- that is re-using normals for
> > multiple coordinates, which is using less than 3 normals for some
> triangles.
> > 2) In specifying intentionally "hard" or "sharp" edges, that is 3
normals
> > per triangle, but adjacent triangles do not share the normals.
> >
> > These cases make up a large portion on CAD data. While this seems a
> special
> > case, most piece of equipment, from computers, to chairs, to cars are
CAD
> > data, even if they aren't from CAD systems and could benefit.
> >
> > Thank you very much for the responses and continued dialog.
> >
> > 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".
