>
> Can I get a little more information here? What exactly is sent every frame
> for a multi-textured geometry? Vertex data, colors, normals, etc? What
> about the texture itself? Would the performance be the same using by-ref,
> since that forces the data to be re-sent on update.
>
The texture state is sent only once. But the geometry itself
including the vertex data, texcoord, color, normals are resent
every frame. The performance will be the same using by-ref.
Geometry-by-ref is also implemented using vertex array.
So it will be resent every frame as well.
> Just so you know, we are multi-texturing almost everything from walls to
> terrain, and the performance hit is staggering. I look forward to the
> display-list fix in 1.3
I hear you. :)
Charmaine Lee
Java3D Enginnering Team
> -----Original Message-----
> From: Charmaine Lee [mailto:[EMAIL PROTECTED]]
> Sent: Friday, March 23, 2001 4:20 PM
> To: [EMAIL PROTECTED]
> Subject: Re: [JAVA3D] Java3d performance analysis (possible bug found)
>
>
> Dave,
>
> Thanks for the analysis. The reason why the multi-texturing performance
> is much better when you put everything into one geometry array is
> because currently we are using vertex array for multi-textured geometry
> array.
> So we are comparing one glDrawArray call for the one geometry array case
> vs 1296 glDrawArray calls for the 1296 geometry array case. On the
> Solaris platform, we do have the glMultiDrawArray to put multiple
> geometry arrays in one single call, but glMultiDrawArray is an opengl
> extension and might not be supported by other vendors.
>
> In Java3D 1.3, we'll look into putting the multi-textured geometry array
> back into a display list.
>
> Thanks for bringing this up.
>
> Charmaine Lee
> Java3D Engineering Team
>
>
>
> > MIME-Version: 1.0
> > Content-Transfer-Encoding: 7bit
> > X-Priority: 3
> > X-MSMail-Priority: Normal
> > X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200
> > Date: Fri, 23 Mar 2001 00:16:01 -0500
> > From: David <[EMAIL PROTECTED]>
> > Subject: [JAVA3D] Java3d performance analysis (possible bug found)
> > To: [EMAIL PROTECTED]
> >
> > I have a friend who is working on a project using OpenGL. He ran an
> > experiment
> > on the same card I am using.
> >
> > He drew 40 houses. 40 * 1600 polygons came out to 64,000
> > polygons and I got around 110 FPS. That came out to right around 7
> million
> > textured polygons per second.
> >
> > I was amazed by that performance, so I ran some tests
> >
> > Tests performed on a Geforce II GTS in Java3d.
> > All with 1 shape, 216 boxes with 6 sides in 1296 geometry arrays.
> >
> > quads, 2 tex units : 39 fps
> > quads, 1 tex unit : 219 fps
> >
> > triangles, 2 texture units : 39 fps
> > triangles, 1 texture unit : 284 fps
> >
> > tristrips, 2 texture units : 39 fps
> > tristrips, 1 texture unit : 248 fps
> >
> > (note: textures in both units are mipmapped. Changing the second unit from
> > MULTI_LEVEL_LINEAR to BASE_LEVEL_LINEAR did not improve performance.
> > Changing the perspective correction from NICEST to FASTEST also has no fps
> > improvement)
> >
> >
> > Now I did it with 2 shapes, one of the box sides was a different shape and
> > appearance
> > All with 2 shapes, 216 boxes with 6 sides in 1296 geometry arrays. One
> shape
> > had 1080 geometry arrays, one shape had 216 geometry arrays.
> >
> > quads, 2 tex units : 24 fps
> > quads, 1 tex unit : 200 fps
> >
> > triangles, 2 texture units : 24 fps
> > triangles, 1 texture unit : 280 fps
> >
> > tristrips, 2 texture units : 24 fps
> > tristrips, 1 texture unit : 248 fps
> >
> >
> > As a final experiment I wrote a TriangleArray masher which took all the
> > seperate geometry arrays in a single shape and put them all in one
> triangle
> > array....
> >
> > And get this.. the fps jumped to 180 with multi texturing, but had NO
> impact
> > when only using one texture unit! I also changed 2 faces to use entirely
> > different multi-textured shapes and the fps dropped to 170.
> >
> > I don't have the numbers to prove it, but I suspect that the overhead of
> > multi-texturing is much higher than it should be, and it is felt everytime
> > there is a geometry array sent to the card. So adding more and different
> > shapes with corresponding multi-textures would result in performance
> > degragation far outstripping the cards own performance hit. This
> > performance hit was just made worse when I sent so many multi-textured
> > geometry arrays to the card, even in one shape.
> >
> > Conclusion.. there is a performance bug when you are multi-texturing in
> the
> > state change from one geometry array to another. (my guess is they are
> > rebinding the second texture unit on each geometry array, regardless if it
> > doesn't change)
> >
> > As a final test, I increased the number of boxes to 1000, which is
> 1000*6*2
> > textured triangles (12k). That was rendered in 180 fps, which is 2.16
> > million triangles per second. I am not unhappy with that performance,
> > although I would think it would be higher. I am not ruling out that my
> > per-frame code is causing the difference.
> >
> > As a final thought... The old fashioned method of multi-tetxuring required
> a
> > 2nd pass. This caused about a 50 percent drop in framerates. The result
> > above show that multi-tetxuring is rendering at 64 percent of a single
> > texture unit. I think it should be around 80 percent.
> >
> > Dave Yazel
> > Cosm Development Team
> > http://www.cosm-game.com
> >
> >
> ===========================================================================
> > 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".
