[sldev] AWG: Geometric Content Creation
Mark Burhop
mark.burhop at gmail.com
Thu Nov 1 08:09:07 PDT 2007
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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.secondlife.com/pipermail/sldev/attachments/20071101/37a48fb4/attachment-0001.htm
More information about the SLDev
mailing list