FLoD-A Framework for Peer-to-Peer 3D Streaming

1. FLoD-A Framework for Peer-to-Peer 3D Streaming

2. Outline • Introduction • P2P Based 3D Streaming Requirements • Challenges • Framework • Evaluation • Conclusion

3. INTRODUCTION

4. 3D Objects • Objects are placed in a large scene • Positions and orientations • Associated data • Polygonal meshes, Textures, Light maps, animations • Information is stored within a scene description

5. FoV & AoI

6. Traditional 3D Content • Require users to pre-installation or prior download • Undesirable - Web 3D • The future internet • If millions of 3D site were exist …

7. 3D Streaming Features • Continuous, real time delivery of 3D content • Allow user interactions without a prior download • 3D content needs to be fragmented into segment • Users accessing 3D content often have different visibility • Scalable and efficient 3D streaming may be important

8. 3D Streaming Stages • Object determination • Employ visibility determination to pick object • Use visual quality estimates to assign transmission priority • Object transmission • Data reduction technique are used to send the object segment

9. P2P 3D Streaming • How can 3D streaming be realized for millions of concurrent users? • Users navigating may own similar content • 3D Data would resemble on-demand media streaming • The main different: • Content access pattern • Media streaming: linear (time) • 3D streaming: non-linear (area)

10. In This Article • FLoD: A Framework for Peer-to-Peer 3D Streaming

11. P2P BASED 3D STREAMING REQUIREMENTS

12. Requirements • 3D object data can be fragmented into • A base piece • many refinement pieces • scene can be rendered once the base pieces are obtained

13. Requirements • Different fragmentation methods • Progressive meshes [7] • Geometry image [12] • Texture fragmentation [13] • Render and navigation may begin as soon as base pieces within the AOI art obtain

14. Requirement for Client • Main concern – Visual Quality • Visual perception [11] • How muchand how fasta client obtains data • Fill ratio • the ratio between the data currently owned and necessary to render a view at an instant • The goal is maximizing the fill ratio

15. Measures for Client • Base latency • The time to obtain the base piece of an object • The delay for a user to see a basic view of an object • Completion latency • The time to download the complete data of an object • The delay of being able to fully inspect an object

16. Requirement for Server • Main concern - improve the system’s scalability • Content is delivered by Peer-to-Peer style • Minimize the server’s CPU and bandwidth usage

17. Distributed Visibility Determination Dynamic group management Peer and piece selection CHALLENGES

18. Distributed Visibility Determination • Visibility should be determined without the server or any global knowledge • We need to partition and distribute scene descriptions to all peers

19. Dynamic group management • Peers exchange 3D data based on interest group • Involves the efficient discovery and maintenance of interest group • If users are moving constantly, the group is much more dynamic than media streaming

20. Peer and piece selection !! • Contact the proper peers • Request the proper data piece • Resource capacity, content availability, network • 3D streaming is view-dependent [14] • Data pieces may be applied in arbitrary order • Requires only a roughly sequential transfer order

21. FRAMEWORK

22. Conceptual Model • Partition • Divide the entire scene into blocks • Fragmentation • Divide 3D objects into pieces • Prefetching • Predict data usage and generating object scene request • Prioritization • Perform visibility determination to generate the ordering of object pieces • Selection • Determining the proper peers to obtain pieces • Efficient fulfill request from prefetching and prioritization

23. FLoD Framework • Graphics layer • Object determination (prefetching, prioritization) • Object reconstruction (de-partition, de-fragmentation) • Networking layer • Object transmission (peer and piece selection)

24. FLoD Policies • Content Discovery • Query the neighbors first, then request the data from the neighbors • Peer Selection • Random or based on certain criteria. (peer’s bandwidth capacity) • Server Request Condition • To ask the server whenever other clients cannot respond to request • To ask the server only if the client becomes the nearest node to an object

25. EVALUATION

26. Scalability Simulation • The upload bandwidth for both C/S server and FLoD server

27. Scalability Simulation • The upload and download bandwidth of FLoD client

28. Streaming Quality • The fill ratio for both C/S and FLoD client

29. Streaming Quality • FLoD client’s base latency is relatively stable at below 600ms

30. AOI Neighbors • If AOI neighbors do not exist • Server request ratio may decrease as nod densith

31. Limitation • Downgrade client’s upload to 64, 48, 32, 16, 8 KB/s • Look at the effect of data density • The fill ratio decreases as the client upload gets smaller

32. Conclusion • This is a topic of interest to both graphics and networking. • Challenges: • Quality of client • Efficiency content delivery • Peer and piece selection • Cannot found AOI neighbors

33. References • [7] H. Hoppe, “Progressive meshes,” in Proc. SIGGRAPH, 1996. • [8] S.-Y. Hu, J.-F. Chen, and T.-H. Chen, “Von: A scalable peer-to-peernetwork for virtual environments,” IEEE Network, vol. 20, no. 4, pp.22–31, 2006. • [11] J. Chim, R. W. H. Lau, H. V. Leong, and A. Si, “Cyberwalk: A webbaseddistributed virtual walkthrough environment,” IEEE TMM, vol. 5,no. 4, pp. 503–515, 2003. • [12] N.-S. Lin, T.-H. Huang, and B.-Y. Chen, “3d model streaming based onjpeg 2000,” IEEE TCE, vol. 53, no. 1, 2007. • [13] J.-E. Marvie and K. Bouatouch, “Remote rendering of massively textured3d scenes through progressive texture maps,” in Proc. VIIP, 2003,pp. 756–761. • [14] J. Kim, S. Lee, and L. Kobbelt, “View-dependent streaming of progressivemeshes,” in Proc. SMI’04, 2004, pp. 209–220.

34. THANKSQ & A