[x3d-public] SSR: server-side rendering

[Christoph Valentin]

Hi Doug
 
Just my private opinion:
I like the idea, because
(1) it saves transmission bandwidth for complex scenery (e.g. between User Equipment and network at the Uu interface)
(2) we need not expose GPS coordinates to the User Equipment (maybe this is not sooo important)
(3) this could be generalized to transmit video streams in the future
(4) do not know much about portal rendering, but I guess this is about the handling at the server, and I'm only arguing about transmission through the network 
 
All the best
Christoph


Gesendet: Freitag, 13. Februar 2015 um 22:16 Uhr
Von: "Tom Sparks" <tom_a_sparks at yahoo.com.au>
An: x3d-public at web3d.org
Betreff: Re: [x3d-public] SSR: server-side rendering
On 14/02/15 02:38, doug sanden wrote:
> IDEA: SSR - server-side rendering: render the scene on a server and ajax screenshots to client
> -Doug
> more..
> 1. client side page shows:
> a) a rendered image when not navigating
> b) a ground grid during mouse/touch drag navigation
> http://dug9.users.sourceforge.net/web3d/tests/SSR/grid4_x3dom.html
> 2. At the end of a drag when the touch/mousebutton is released, the accumulated navigation is ajaxed to the server, and the server moves an avatar, takes a screenshot, compressed to jpg, and sends back to client.
> 3. client renders the image over/instead-of the grid
>
> Purpose of the grid: to give user a sense of how far and what direction they are navigating when there's no visible scenery
> - they can guestimate how far they want to go
> Option: server renders 2 or 3 'depth slices' of the view frustum against transparent background, and ajaxes all depth slices, and the client composes them, as textured planes in 3D scene to give a sense of distance
>
> Benefits:
> - for large scenes, no geometry to download other than small grid. very fast to get into a large scene
> -- avoids the need for any kind of binary compression other than jpeg
> - for proprietary scenery, only screenshots are sent to client, no need to encrypt
> - best when scene contains no time-based animations - just static geometry
> -- option: also detect short mouse/touch 'clicks' and send them to server as clicks instead of navigations
> - server-side scenes can have conventional x3d/vrml97 files with Protos and advanced nodes
>
I like the idea
but portal rendering[1] would work better idea as long as you render the
layered depth images on the server

[1] http://en.wikipedia.org/wiki/Portal_rendering[http://en.wikipedia.org/wiki/Portal_rendering]
[2]
http://www.cs.princeton.edu/courses/archive/spr01/cs598b/papers/rafferty98.pdf[http://www.cs.princeton.edu/courses/archive/spr01/cs598b/papers/rafferty98.pdf]

tom

_______________________________________________
x3d-public mailing list
x3d-public at web3d.org
http://web3d.org/mailman/listinfo/x3d-public_web3d.org[http://web3d.org/mailman/listinfo/x3d-public_web3d.org]