[sldev] AWG: Geometric Content Creation

Mark Burhop mark.burhop at gmail.com
Sun Oct 28 18:48:01 PDT 2007


On 10/28/07, Lawson English <lenglish5 at cox.net> wrote:
>
> Mark Burhop wrote:
> >
> >     > For the concrete people, "Collada"
> >     > < http://en.wikipedia.org/wiki/COLLADA> anyone?
> >     I think the major issue that immediately comes to mind with AMOs
> >     (Arbitrary Mesh Objects for those of you keeping score at home) is
> >     bandwidth. Prims are exceptionally lean on bandwidth. Mesh models
> >     tend
> >     to be heavy.
> >
> > Yes- being able to stream geometry across the wire with as few bytes
> > as possible is really important. I like the compactness of the current
> > prims.
> >
> > So while I think meshes are often the only practical option for some
> > things,  I do think a future architecture could do a lot more with
> > "analytics" that it does now.
> >
> > Consider a simple box with an arbitrary cylindrical hole in it.
> > Comunicating that takes very few bytes.  Creating one today in SL
> > today is hard (except for a few special cases).
> >
>
> Various folks have talked about geometric geometry.  The ability to do
> boolean combinations on prims would go a long way to addressing these
> issues. The REAL issue is the very long term, where Intel's call for
> raytracing to replace more traditional 3D rendering comes into play.
> Standard prims, I iunderstand, are almost a freebie for raytracing. More
> complicated messhes muddy the waters. How complex do we want things to
> get, knowing that graphics issues will change drastically by the time
> the world-wide-grid could become a reality?
>
> Lawson
>
>
If if the AWG starts to take hold, this will be part of an interesting
discussion. There are a few important aspects to this:

1.) The will be a desire for increasing levels of realism especially as the
exisitng barriers (compute power, graphics technology, network band width)
continue to crumble. Any final solution should scale accordingly.

2.) The need to make use of existing geometric assets. In this case I'm
talking about the large volume of 3D data that exists in so many programs,
file formats, and companies today.  People want to reuse their geometry, not
recreate it for every new system that comes along. So I don't think you can
completely start from scatch.

Pratically, for Boolean work, you probably want to use  CSG or the more
advanced Boundary representation (BREP) geometry. BREP would be great but is
mostly in the domain of comercial products like ACIS and Parasolid. So
either you set up to plug in these modelers (like with the physics engine),
or fall back to something simpler like open source CSG or some other
technology supporting booleans (F-REP?)

In any case, they *may* be too computationally intensive to be used in the
short term.  You would first have compute the composition of data and second
figure out how to render it.

I'd be curious to hear other peoples views on this....
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.secondlife.com/pipermail/sldev/attachments/20071028/402d12d0/attachment.htm


More information about the SLDev mailing list