Antonio Bleile wrote: > Marcus Lindblom wrote: > >> In our system, we have every "object" that need extra updating being >> registered to a "updater" when it's created. (By checking the type >> dynamically.) The order of update is simply the order of creation, and >> this has worked surprisingy well for almost three years now. The time >> (both absolute and relative) is fetched from a singleton (that provides >> different clocks for each aspect). > > Sounds good, the Observer pattern is always good ;) That would > work well with a global "animation pool" (a pool that contains all > the animation data of the scene).
Ugh. I don't like global things. But it seems the only way to distribute things in a cluster without having them shown (otherwise there wouldn't be a MaterialPool), or? > The only problem is the singleton for the time storage ;). > What about having a "Time" node? That would work exactly as > the light node, nodes below the time node use their ancestor's > time. Pretty neat. How about having (at least the option of) a separate graph for time-objects, so that we avoid forcing things down the same hierarchy. We already have light & transform/material connected that way. You might also want to consider allowing the animation update to run in a separate thread (and thus aspect) from the main app and the rendering. It would make sense for OpenSG to allow for this, since it has such excellent multi-threading facilities. Cheers, /Marcus ------------------------------------------------------------------------- SF.Net email is sponsored by: Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php _______________________________________________ Opensg-core mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/opensg-core
