[GeoWeb3DContest] GML + SSR

Tue Mar 17 10:12:05 PDT 2015

Our biggest problem in the development of a client capable of rendering the
whole city comes from the textures.
Rendering the whole city at LOD 2 in an  average PC is doable (mobile? not
so much), and once you load the 3D model inside the GPU memory it renders
fast (we get 30+fps with mid range gpu rendering the whole city). The trick
here is to render big chunks of geometry at once thus lowering the number
of draw calls, it still needs considerable amount of GPU memory.
Making it fully interactive requires some tricks, you either need to hold
the whole geometry hierarchy CPU side to do ray-casting/picking or to use
color picking on the GPU on feature level, the whole geometry is rendered
on an additional surface buffer where each surface have an unique color
with which you can get the feature id and access the GML data (client or
server side).

The problems are the textures, first having a huge number of texture is
extremely inefficient for the gpu, but even if you merge  everything in big
texture atlases you still have just too much data. The solution here is to
implement something like id Software megatexture
http://en.wikipedia.org/wiki/MegaTexture, and some sort of aggresive LOD
technique. So you will only load the texture in the GPU that are actually
used in the rendering of the image AND you do not load the full resolution
texture but only a scaled down optimized version of it. When a geometry is
close to the camera the full resolution texture is loaded and swapped with
the old one.

FD

*Federico Devigili*

*Analyst and Developer*

*Fondazione Graphitech*

Via Alla Cascata, 56/C - 38123 Trento - Italy

Office: +39 0461 283397

Fax: +39 0461 283398

Skype: fededeviwork

Email: federico.devigili at graphitech.it

Website: http://www.graphitech.it

On Mon, Mar 16, 2015 at 9:32 PM, Information and updates on Web3D's
Rotterdam city data competition <geoweb3dcontest at web3d.org> wrote:

> One idea for GML is to use it as a format for transmitting data that might
> normally be in a GIS database - the so called attribute tables. Once
> transmitted, it would be put back into geometry files and database
> attribute tables.
>
> If trying to use Web3d -vrml or x3d- to render, one idea is to put ID into
> the metadata for the web3d node. Then when searching for relationships, the
> ID for a picked item would be used to search GIS-like database attribute
> tables. This might allow skipping some or all of the cityGML-specific
> format -instead using X3D+database to implement/realize the goemetry and
> relationships.
>
> Another options is a 2 or 3 or 4 layer system:  database, GML server,
> Web3d server, and client with a chain of communications between the layers.
> -Doug
>
> >
> > The thing to work out, and make public, would be the web-service
> 'dialog' between client and server, such as how to ask for an overview LOD0
> map of the area to get started, then how to tell the server the client's
> new viewpoint pose: 3 rotations and 3 translations, and ask for a
> screenshot rendering. Or pose + xy click point, and ask for information on
> the item clicked.
> > - then any compatible client could work with any compatible server
> > -Doug
> > more..
> > I worked out an SSR for virtual reality recently, for freewrl, and the
> client and C web server glue code are checked into freewrl as 'MIT or
> equivalent' license, meaning 'have fun'.
> >
> > I was able to display a bit of rotterdam in vrml, using libcitygml's
> citygml2vrml.exe converter, followed by Chisel's CONDENSE> Create DEF/USE
> (otherwise vivaty/freewrl run out of memory re-mallocing textures), then
> wrapping the result in a Transform with -ve UTM / 3TM coordinates of an
> Point, so as to get the view frustum within near/far range of the geometry
> (vs being at the earths equator with the default viewpoint, and not being
> able to see the neatherlands).
> >
> > Then freewrl renders slow - 1.2 FPS. And that's just for one subdivision
> of Rotterdam, mostly due to what I would call 'heavy textures' 1024x1024x4
> textures. But I do see 3D buildings.
> >
> > I got Aristoteles to run a bit, but it showed no textures, rendered
> 'zingers' -lines from each piece of geometry to a few arbirary points - and
> was hard to navigate and 'enjoy'.
> >
> > I tried building an SVN copy of Aristoteles but it doesn't build right
> out of the gate. Many of these GML software projects were abandoned about 5
> years ago. I suspect GML was pushed by geography professors and a few
> cities trying to break ESRI stranglehold. That's hard, because most cities
> don't mind ESRI, have healthy budgets for ESRI licenses, and have no
> interest in anything unconventional/free. The general public doesn't
> need/want detailed GIS relationships. So who needs GML is the remaining
> question.
> > Esri black box server-side rendering of rotterdam:
> > http://www.esri.com/software/cityengine/industries/rotterdam
> >
> > When I look at google maps, and remember back to MS virtual earth, they
> used server-side rendering. What's changed: with webgl now readily
> available, it should be possible to adjust viewpoint pose more freely in
> 3D, including horizontal street views.
> >
> > In freewrl's web3d SSR, I do a 2-step dialog with the server: first I
> send where the client navigated to. Then the server does collision and
> gravity adjustments to that pose, and sends it back. Then when the client
> gets the adjusted pose, it asks for a snapshot in the second step. The
> server renders the snapshot and sends it back, and the client pastes it
> over the navigation grid.
> >
> >
> >
> >
> >
> >>
> >> One idea is to use server-side rendering (SSR) in the following way:
> >> - render GML LOD0, or 1 on the client side in real time, during
> navigation
> >> - one the viewpoint is pointed where you want it, lift the
> mousebutton/touch. The client then sends the viewpoint pose to the server.
> The server renders that viewpoint using LOD3 or 4, and sends back an
> overlay image.
> >> - you can then click on the overlay image, The client sends viewpoint,
> and point of clicking, back to the server
> >> - the server constructs a pickray and picks the LOD3,4 geometry, gets
> the IDs, looks up info in a database and sends back to the client.
> >>
> >> Benefit: client stays 'light', and server does all the heavy work.
> >> - client needs a bit of webgl for rendering LOD0 and/or 1, and for
> navigating
> >>
> >> -Doug
>
>
> _______________________________________________
> GeoWeb3DContest mailing list
> GeoWeb3DContest at web3d.org
> http://web3d.org/mailman/listinfo/geoweb3dcontest_web3d.org
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://web3d.org/pipermail/geoweb3dcontest_web3d.org/attachments/20150317/1b341884/attachment-0001.html>