Re: [openvrml-develop] Problem rendering from one browser into multiple/changing openvrml::gl::viewers

[Braden M. <br...@en...>]

On Sun, 2006-01-22 at 10:56 +0100, Michael Sögtrop wrote:
> Hi Braden,
> 
> > I'd welcome a patch to fix the library to support this; 
> > however, it's a
> > nontrivial amount of work.
> 
> There would be several methods to solve this: 
> 
> 1.) have a function iterate the whole scene and reset all view
> dependent information
> 
> 2.) store a view id with view dependent information and reset it
> during rendering if the view doesn't match
> 
> 3.) Use some sort of container to store multiple view dependent
> informations per node.
> 
> 4.) Have a mode that doesn't use view dependent information at all
> (like the hack I tried with begin_object).
> 
> I think 1.) would be most efficient and simple, but it cannot be made
> inherently thread safe, so that rendering requests from multiple views
> need to be serialized with a semaphore. In my app the GUI is single
> threaded, so this wouldn't be a problem for me. I think this should be
> true for most apps.

The problem with threading makes this a nonstarter; but I don't think
this is particularly (time-) efficient either. As scene size and the
number of viewers increases, this could get pretty slow.

> 2.) is a bit trading speed for memory compared to 1.) and could be
> made thread safe but it would need an interlocked exchange function
> and if rendering really overlaps regularly, rendering speed will be
> degraded because the list IDs are constantly overwritten and not
> really used. I would then rather prefer 4.) so that you know what you
> get.

Yeah; this doesn't strike me as very efficient either, since viewer
dependent-information will not typically be coincident between more than
one viewer.

> 3.) is I think a bit heavy in terms of memory consumption.

Well, the std::map itself might be; but the things being stored
(pointers and integers) are not. I think this is what we want to do--use
std::map first for convenience, and potentially replace it if it's too
much of a pig.

> 4.) would allow inherently thread safe rendering but is of course far
> from optimal in terms of rendering speed.

Also a nonstarter.

> What do you think about this? 
> 
> Can you give me some hints on what to look out for (in addition to the
> GL list IDs)? Clearing the list IDs is a bit of work but should be
> straight forward, but I have no idea what else there might be.

I think navigation-related stuff is going to be tricky. VRML has a
notion of a "user view" that is an offset relative to the currently
active Viewpoint node. It does not have a notion of more than one user
view; so such a notion will need to be devised.

-- 
Braden McDaniel                           e-mail: <br...@en...>
<http://endoframe.com>                    Jabber: <br...@ja...>