Great to hear from you David, Cosm is the reason I chose Java3D for my project. I'm really impressed with what I've seen you guys going.
Funny, I'd already considered what you mentioned, a behavior with frames elapsed set to zero, but dismissed it as "too obvious" =D Handling everything in the ProcessStimulus would be fine... My other thought was to override the PreRender method and do my work there, but my toying with immediate and mixed mode rendering has resulted in less than stellar performance compared to retained mode. I guess D3D7 and D3D8 has put my mind in an "Immediate State of Mind." (sung to the tune of a Billy Joel tune). Scott ----- Original Message ----- From: "Yazel, David J." <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Monday, February 25, 2002 10:06 AM Subject: [JAVA3D] Mixed, Retained and Immediate mode for games > I keep reading assertions on this list that immediate mode or mixed mode is > the preferred method when using Java3d for games. > > Just to weigh in here on the mixed mode, immediate mode and retained mode > debate. Our project runs in 100 percent retained mode. We don't make a > single call to anything in the graphics3d context obtained from the > Canvas3d. While we do use some behaviors to handle the intersection of the > view platform with an objects activation bounds, the vast majority of the > per-frame work is done downstream of a single bevahior with elapsed frames > zero. > > From this behavior we do the following: > > 1. Recalculate the transform3d of all moving objects. > 2. Recalcuate the camera (view) transformation > 3. recalcuate the position of the clouds, sun, moon and all other sky > entities > 4. make any "transactional" updates to the scene graph (like LOD changes, or > terrain quadtree swaps) > 5. Adjust the volumes for all non-spatial sounds based on various factors > 6. Recalculate the position, size, color, etc, of all living particles. > 7. Recalculate water vertices and texture coordinates > 8. Recalculate a variety of "special" effects like morphing, melting, > fading, shrinking and anything that needs vertex manipulation over time. > 9. Recalculate all or some of the avatars skin and bones. > > Every calculation is based on a single frame "time" that is calculated using > a high resolution timer, adjusted to match the server (which it synchronizes > with upon connection to the server). > > Currently the frame calculation time is about 2.5 times faster than the > frame rendering time. So for example on a 700 MHz PIII the average frame > calculation time is about 10 ms while the frame rendering time is about 25 > ms. The most intensive things are the avatars which take about 900 > nanoseconds each to recalculate the skin, so we have to pick and choose > which ones get updated per frame. > > So, for what it is worth, we have not found a need to use mixed or immediate > mode at all. > > David Yazel > Magicosm 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".
