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".
