We found nearly the same result when we started to implement a basic character
animation.
Search the archive for :
serious performance problems when setting Transforms
or just
setting Transforms
This is a known problem that is not planned on being fixed until Java3D 1.3,
which has no published release schedule.
This is equally a problem for us as you, because we are trying to do commerical
quality game demo's and can not do many types because of the hit we take with
Transforms.
Joe Kiniry wrote:
> Hi again,
>
> As mentioned earlier, our graphics engine is rendering multiple entities in
> a very computationally intensive application. Currently we are rendering
> skin-less untextured entities (i.e. just bones and "muscles"), so
> computationally Java3D is going to be constrained more by
> scenegraph-centric scalability issues than polygon ones. I'm rendering our
> canonical test entity which is composed of a half-dozen lines, five
> low-resolution primitive spheres (12 divisions, though I have tested down
> to 4), and 43 quads.
>
> To test the scalability of the various major components of our application
> I ran some benchmarks on a log-log scale. They are appended at the end of
> this email (all numbers are in milliseconds). To summarize, I'm seeing
> slightly super-linear complexity (in number of entities) in all of our
> computation (which we expect) and slightly sub-linear complexity in
> rendering, which we don't understand.
>
> In other words, rendering time doesn't seem to be scaling with respect to
> "traditional" constraints (that of polygons), but instead, directly
> proportional to the number of BranchGroups or, equivalently in my case, the
> number of TransformGroups with TransformGroup.ALLOW_TRANSFORM_WRITE set.
> While this isn't completely surprising, it does lead to a problematic
> situation: that of unacceptable framerates with only 4 or 5 entities.
>
> I'm currently using my mutex-based solution to lock-step rendering. I'm
> considering trying a specialization of Canvas3D approach, but if this
> scaling is inherent in the Java3D architecture, then there is really no
> point in my doing so, thus this email.
>
> Three other notes: (1) the rendering engine is not doing Level-of-Detail
> for these benchmarks primarily because we're seeing rendering times
> non-proportional to polygon counts, thus it is unclear how much LOD will
> help the situation. Of course, we are adding this now and we'll have new
> numbers, but I don't expect to see a significant change in my curves. (2)
> Also note that all of these benchmarks are on our lowest-end target machine
> (a P-II 350 with a Voodoo 3) and were run in Linux. We see equivalent
> numbers under Windows. (3) Finally, these benchmarks are running with all
> test code (pre- and post-conditions, assertions, and tunable logging)
> enabled, but such code is standardized in our product thus impacts all
> systems *but for the actual rendering time* is uniform. I.e. Our physics
> engine can go much faster than this, but can Java3D?
>
> Another way of looking at this problem is this: typically in computational
> intensive, networked applications one is always left waiting for the next
> frame to be ready to render because of things like physics and network
> latency - rendering is "cheap". We're finding just the opposite; a
> situation we are unused to being in.
>
> Suggestions and comments welcome. I'm on the digest list, so please CC.
>
> Best,
> Joe Kiniry
> --
> Joseph R. Kiniry
> DALi, Inc.
>
> ---
>
> 1 entity
>
> <LOG_FPS>: FPS = 45.54655870445344
> Average computation time = 7.4218516
> Average render time = 14.235926
> Average migration time = 9.7292793E11
> Average alife time = 2.5403705
> Average spatial time = 0.08259259
> Average physics time = 3.5422223
> Average scenegraph update time = 3.7037037E-4
>
> 2 entities
>
> <LOG_FPS>: FPS = 25.735609505018445
> Average computation time = 13.558
> Average render time = 24.926666
> Average migration time = 9.7292806E11
> Average alife time = 4.8193336
> Average spatial time = 0.12733333
> Average physics time = 6.5886664
> Average scenegraph update time = 6.6666666E-4
>
> 4 entities
>
> <LOG_FPS>: FPS = 14.051110915956793
> Average computation time = 25.92875
> Average render time = 44.25125
> Average migration time = 9.7292812E11
> Average alife time = 9.53875
> Average spatial time = 0.21625
> Average physics time = 12.19
> Average scenegraph update time = 0.00375
>
> 8 entities
>
> <LOG_FPS>: FPS = 7.143750111621095
> Average computation time = 53.05
> Average render time = 84.99
> Average migration time = 9.7292819E11
> Average alife time = 19.51
> Average spatial time = 0.3425
> Average physics time = 24.9925
> Average scenegraph update time = 0.015
>
> 16 entities
>
> <LOG_FPS>: FPS = 3.4486920835273223
> Average computation time = 109.795
> Average render time = 169.915
> Average migration time = 9.7292832E11
> Average alife time = 39.645
> Average spatial time = 0.7
> Average physics time = 54.065
> Average scenegraph update time = 0.075
>
> 32 entities
>
> <LOG_FPS>: FPS = 1.624932971514925
> Average computation time = 244.51
> Average render time = 333.75
> Average migration time = 9.7301417E11
> Average alife time = 91.65
> Average spatial time = 1.75
> Average physics time = 116.12
> Average scenegraph update time = 0.28
>
> ===========================================================================
> 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".
--
___________________________________________________________
Shawn Kendall Full Sail Real World Education
Course Director 3300 University BLVD
Real Time 3D for Gaming Winter Park FL 32792
[EMAIL PROTECTED] http://www.fullsail.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".
