[sldev] AWG: Geometric Content Creation

[Zha Ewry]

The physics calculation is entirely server side. There are tiny rendering
things which are done client side, but they don't affect other  people.
(Flexies, and particle systems are client side artifacts, and they have no
physics implications as a result) There are schemes where you could do
physics elsewhere, but they run into very tricky consistency, communications
costs scaling issues.

- Zha


On Nov 1, 2007 11:09 AM, Mark Burhop <mark.burhop at gmail.com> wrote:

>
> On 10/31/07, Mark Grandau <mgrandau at solidworks.com> wrote:
>
> > As a CAD developer, SolidWorks, I of course have my perfered format. But
> > the issue is that even that is constantly evolving as hardware evolves.
> > Perhaps a better way is to allow access to the OGL through a plugin of
> > some type with a default prim, perhaps linking to the plugin in
> > question.
>
>
> *Mark Burhop Wrote:*
>
> Take a look at this:
> >
> > http://wiki.secondlife.com/wiki/Geometry_Based_Architecture_View
> >
> > It includes a rendering plugin with flexibility for multiple (and ever
> > changing) formats.
> >
> > Does this line up with what you are thinking?
>
>
>
>  On 11/1/07, Mark Grandau < mgrandau at solidworks.com> wrote:
> >
> >  I think I see where you're going.  Not sure what the ClientSide Library
> > represents and why should the viewer only have access to the Region Domain.
> > I would think you would want Web Clients, Standalone Apps or the Viewer
> > (which is just another standalone app to me) all to have potential access to
> > both domains.
> >
> > I would also encourage you to split the render and physics plugin to
> > separate plugins. That would clearly document interconnectivity and allow
> > for customization or perhaps reuse of the render plugin in the standalone
> > apps. What are you thinking for the plugin mechanism, Gecko-XPCOM?
> >
> > The big thing to me, from the rendering side, would be the rendering
> > plugin needs to expose enough of the OGL functionality.
> >
> > I was actually thinking less abstract and more implementation based,
> > building on HTTP concepts. Using mime type to identify the various file
> > formats, which the file formats already have.  This would be used to trigger
> > the plugin. I like the idea of mime types also for VW objects because that
> > would allow for representations of VW objects in Web based clients and
> > standalone Apps. I think it is just as important that VW object be able to
> > be represented in the Web clients or standalone Apps.
> >
> > Mark
> >
>
>
> The ClientSideLib could perhaps be drawn differently or removed.  Its been
> my experience that some SOA implementations will also have some type of
> client libraries which non-SOA executables can link into. Then,
> the non-web savy developers can call simple APIs. So, for example, there
> might be a C++ lib that takes care of the Rest and XML and service
> connection which could be reused by developers not wanting to get into the
> specifics.  I was trying to show this might be common... not every
> application would have to it write their own.
>
> For the Render and Physics, I think the Physics part may need to be
> removed (someone tell me, does physics calculation occur on the client or
> server?)
>
> The model is definitely more abstract and long term (and very open to
> change!) The AWG discussions have been at this level and the diagram was to
> help with that.  It just seemed to match up closely with your more
> practical comments (always good if an architecture is grounded in reality
> :-)
>
> Mark
>
>
>
>
> _______________________________________________
> Click here to unsubscribe or manage your list subscription:
> /index.html
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.secondlife.com/pipermail/sldev/attachments/20071101/eebaea85/attachment-0001.htm