Distributed Graphics: Two Case StudiesDistributed GraphicsThis LectureSlide 4High Level LibrariesGeneral GoalDifferent between Distributed and Monolithic ApplicationsRepo-3DMotivationClient-Server Data Sharing Inappropriate for Distributed GraphicsUnderlying InfrastructureDistributed ObjectsRemote ObjectsReplicated ObjectsUpdate Scheme for Replicated ObjectsAnim-3DGOPropertyBasic Design of Repo-3DReplicated Objects?Local VariationsLocal Variations - propertyLocal Variation - childrenExampleStreaming Texture Intensive ApplicationsIntroductionBackgroundBackground (2) : A different approach [Levoy]Background (3) [Levoy]View-dependent Texture StreamingView-dependent Texture Streaming(2)View-dependent Texture Streaming(3)View-dependent Texture Streaming(4)The Texture Quality FactorThe Texture Quality Factor (linear case)The Texture Quality Factor (non-linear case)Slide 37Geometry StreamingBandwidth (compared with MPEG)Two Reference ViewsThree In-Between ViewsResultsMore resultsSlide 44Distributed Graphics: Two Case StudiesJian Huang, CS 594, Spring 2002Distributed Graphics•Two major categories:–Data can be replicated–Data can not be replicated•Dependent on the choice–Drastically different approach–Specific pros and consThis Lecture•Look at a sample system in each category:–A Distributed 3D Graphics Library, Blair MacIntyre and Steven Feiner, SIGGRAPH’2002–Deep Compression for Streaming Texture Intensive Animations, Daniel Cohen-Or, Yair Mann, Shachar Fleishman, SIGGRAPH’1999•Lots of research issues are currently still open problemsDistributed Graphics•Systems for distributing the shared graphical state of multi-display, multi-person, distributed, interactive applicationsComputer Supported Corporative Work (CSCW) and Distributed Virtual Environments (DVE)High Level Libraries•Have excellent programming libraries for stand-alone 3D applications: Inventor, Performer, Java3D, …•No such libraries for distributed graphics applications, although some DVE systems have been proposed:–A mechanism to distribute application state (either a custom solution or using a general-purpose lib)–Maintain the state of the graphical display separately and locally•A “dual databases” approach–Synchronizing the dual database is complex, tedious, and error-proneGeneral Goal•To use a “single database” approach for distributed 3D graphics library•Repo-3D is an object-oriented, high-level graphics package–The objects used to create the graphical scenes are directly distributable from the programmer’s perspective–The objects reside in one large distributed shared memory (DSM)–The underlying system automatically replicates the fine-grained objects across as many processes as needed–Updates to objects are automatically reflected in all replicas, with any required objects automatically distributed as needed.Different between Distributed and Monolithic Applications•Distributed control–In a non-trivial distributed application, different components need to be notified of changes to the distributed state•Interactivity–Network latency bandwidth limitations make updates to distributed state much slower. For performance, need to perform some operations locally•Local variations–There are times when a shared graphical scene may need to be modified locallyRepo-3D•Repo-3D addresses these problems in two ways: –Notification object: associated with any replicated object. Invoke notification object’s methods when the replicated object is updated.–Local variation: to allow the properties of a graphical object to be modified locally, and parts of the scene graph to be locally added, removed, or replaced.Motivation•Authors’ fundamental belief: –With uniform high-level support for distributed programming in the languages and toolkits, prototyping and experimenting with distributed interactive applications can be (almost) as simple as multi-threaded programming in a single process•Useful for:–True with exploration and prototyping phase–Object-oriented programming (high data transparency)Client-Server Data Sharing Inappropriate for Distributed Graphics•Client-server data sharing (e.g. CORBA, Modular-3 Network Objects, Java RMI) impossible for high frame-rate distributed graphics•Data replication is necessary•Update of shared/replicated data should be asynchronousUnderlying Infrastructure•Developed in Modula-3 language: descendant of PASCAL, and heavily influenced Java•In particular, Modula-3:–strong type safety–exception handling–concurrency–object-oriented programming–automatic garbage collectionDistributed Objects•Within the paradigm of distributed shared memory (DSM)•Three types of objects–Simple objects: normal local data obj–Remote objects: client-server semantics. All method invocations go across the network to the original object–Replicated objects: replicated at all locations, need to be consistently updatedRemote Objects•The Network Object package provides support for remote objects•It implements –distributed garbage collection–exception propagation back to the calling site–automatic marshalling and unmarshalling of method arguments–return values of virtually any data type between heterogeneous machine architecturesReplicated Objects•The Replicated Object package supports replicated objects. Each process can call any method of an object it shares–All operations on an instance of an object are atomic and serializable–All operations are performed in the same order on all copies of the object–If two methods are invoked simultaneously, the order of invocation is nondeterministic–Full replication: no partial replicationUpdate Scheme for Replicated Objects•Each method is marked either read or update•Only update methods trigger an update event•Use a sequencer process (maybe a remote process) to enforce the same sequence of operations for a replicated object•May have multiple sequencers in the distributed system•All replicas of an object, including the one invoked this update method, executes the update after receiving update msg from sequencerAnim-3D•Graphical objects (GO): –all entities of a graphical scene: geometry, light, …–GOs can be grouped in any Directed Acyclic Graph (DAG)–Each GO is associated with a set of properties•Properties: –behavior of GO–Defined by a name and a value: •say, TextureReconstruction, nearest neighbor•Input event call-backsGO•GO
View Full Document
Unlocking...