Hi all, wanted to update you on some more experiments:
1. I added a new frames per second behavior which wakes up every 40 frames
and calculates FPS. Now I am seeing approximately (depending on clipping)
anywhere from 110 fps to 7, but the important thing is that its not locked
at 18 fps. The funny thing is just adding the behavior caused the
postSwap() to be called more, thus my other FPS calculation also increased,
giving the same numbers as the fps behavior. This seems to confirm my
theory that if there are no scheduled behaviors in your scene within bounds,
and the scene is static, that Java3d will not push out more frames than it
needs to.
2. Keyboard behavior became extremely sluggish after the frame rate went up
to 40ish fps at 200.0 physical clipping. Looked like my keyboard behavior
was not getting executed often enough. Java3d is very liberal on invoking
wakeup on elapsed time criterion, especially if the interval is short. I
threaded my behavior with a high priority thread and now have it doing the
movement transformations, reading a queue of activated keys controled by the
awt wakeup criterion. This still was slow until I reduced Java3d's thread
priority in the universe class to NORMAL. I noticed no reduction in
framerates when doing this. How safe is it to alter transformations in a
thread? I saw example code somewhere where the person was implementing
"falling" in a seperate thread, acting directly on the transformations
attached to objects.
3. There definitely seems to be a relationship between fill and transform
bound. Assuming my clipping is in close enough, changing the size of my
window dramatically changes my frames per second. I need to do a little
work to start measuring some better stats on the relationship of "triangles
/ vertices in view" to fps.
4. I experimented with LOD. Can't say I was very happy with what I saw.
DistanceLOD is working on a switch node. But to get it to work
automatically you have to set the bounds such that the switch decision is
made when the view intersects with it. This causes the LOD behavior to fire
continuously, and if you have lots of LOD'ed objects you use all your cycles
and memory in short order. I will experiment with impementing the
distanceLOD myself, optimized for my large terrain set in a "grid" This way
I can more optimally control the switch nodes when the person moves from one
grid cell to another.
5. I think I have finallly found the right "combination" for large terrain
in Java3d. I have experimented with lots of different configurations and
the following seems to offer the best performance/flexibility. You are
going to laugh because it is counter-intuitive. First of all I found out
that the "number" of shapes does not impact framerate assuming that the
number of verticies remains constant. Only one texture can be shown per
shape, so there are advantages to having smaller shapes. If you recall,
yesterday I had a grid of 200x200 height values mapped into a 4,000 x 4,000
area, with a total of 80,000 triangles. Well I decimated the heightmap down
to 50x50, still mapped to 4000 x 4000, reducing the number of triangles to
5000. Also, I orginally had 50 triangles per "cell" (single sub-mesh)
knitted together to make a single larger. Now I kept reducing the "unit
size" of the submesh and looking for performance drops. I expected to see
performance drops because dropping the unit size of the sibmesh results in
more sub-meshes being generated. But I dropped it all the way down to ONE
without losing performance. (now is when you can start laughing) So my
whole terrain over 4000 x 4000 virtual coordinates ends up being 2500 meshes
of two triangles each (as a deformed square). The WONDERFUL thing about
this is that you can stretch a 128x128 texture on that size mesh very
nicely, which allows you to define a 50x50 map of textures to cells. I will
be experimenting more this week on this, but it allows you to solve the
"straight line" syndrome by playing with texture coordinates and doing a
little bending. I will post some screenshots if I can get something to look
reasonably good.
6. I was wondering if anyone knew those things which are "expensive" for
Java3d to do. In designing my LOD objects, I would like to know what
short-cuts make the most sense. Like, does ignoring vertex colors on
distant LOD objects make them faster to render? Does texturing increase or
decrease rendering speed? I am expecting to make distant hills out of
nothing more than a 4 sided pryamid "hazed" by distance. This should give
me a nice skyline.
7. My goal is to render the scene graph with max clipping, but with an high
framerate by using select nodes to reduce larger-far-away objects down to
just a few polygons, and have maybe, 4 levels of LOD. I will create a
priority structure for objects so that at mid-range an "important" object
can still be rendered, but "unimportant" objects can be cut comepltely or
LODed with a lowpolygon object. Does this apprach sound promising?
Be well all.
Dave Yazel
> ----------
> From: Mark Ferneau[SMTP:[EMAIL PROTECTED]]
> Reply To: Discussion list for Java 3D API
> Sent: Monday, August 28, 2000 12:27 PM
> To: [EMAIL PROTECTED]
> Subject: Re: [JAVA3D] Performance, LOD and optimization
>
> Dave,
>
> It looks like you are doing some really interesting work, especially given
> the domain for the image URLs you provided earlier today. I have to be
> honest that I don't think anyone can realistically answer your questions
> without much more information.
>
> At 10:07 AM 8/28/2000 -0400, you wrote:
> > Q: What kind of FPS should I be seeing?
>
> What platform are you running on, what size is your rendering window, are
> you using OGL or D3D?
>
> > Q: Am I maxing out at 18 fps because I don't have anything in
> the
> >scene moving faster than that? I have no interpolators going, no timed
> >behaviors except my keyboard.
>
> Not likely, depending on your rendering window and graphics hardware, you
> are likely either fill bound or transform bound. Fill bound means that
> you
> are trying to fill too many pixels on the screen and you don't have the
> pixel fill to do so. Transform bound means you have too many vertices in
> the scene that are being processed--this really becomes an issue with
> multiple lights in your scene, especially spot lights. One test for
> finding if you are fill bound is to decrease your rendering window size to
> 60x60 or, better still, to a much small version of what you have now but
> at
> the same aspect ratio. If you performance jumps you are likely fill
> bound.
>
> To see if you are transform bound, use LODs to decrease the number of
> vertices in the scene, decrease the number of lights, etc.
>
> > Q: If I want to do an animation like rotate a transparent GIF
> over a
> >transparent cylinder (for a fire effect), how many FPS do I need for it
> to
> >look realistic?
>
> What kind of fire are you trying to reproduce? Fire in a fire place, fire
> on a stove, forest fire, fire ball, etc? How important of an element is
> the fire to your scene? Depending on the answer to this question the
> speed
> could be lower or higher. In general it will depend on how much your
> textures need to move to generate the effect you desire. If they have to
> move a lot a higher framerate will be required to make the motion not look
> jerky.
>
> --Mark
>
>
>
>
> Mark Ferneau 240-462-6262 (cell)
> Director of Adv. Technology 801-437-4608 (efax)
> Xtivia Technologies, Inc. 732-469-5954 x629 (NJ office)
> [EMAIL PROTECTED] 301-279-5703 (home office)
> http://www.xtivia.com/ [EMAIL PROTECTED] (wireless email)
>
> ==========================================================================
> =
> 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".
