[opensource-dev] crazy land idea

Celierra Darling Celierra at gmail.com
Mon Sep 27 00:18:37 PDT 2010

I'd think that those clipping / occlusion culling algorithms you cited only
work if one of the two pieces of geometry can be transformed (reversibly) so
that it ends up being rectilinear - like a cube, a camera frustum, etc.  You
can see how the examples in your link use rectangles.  Clipping in that
narrow context is *much* easier than the general case of creating geometry
that way, which would be more like Constructive Solid Geometry [1].  SL
already does the union operation in the trivial way (render all prims
whole), so you're looking to not only optimize that but also implement the
difference operation.  In particular, notice how you'd have to reason about
actively creating vertices at the edges where two or more prims meet - I'd
be tempted to just go to meshes and leave that problem to mesh editors to
solve, although then it's not trivial to test whether or not you're inside
the mesh....

If we narrow this to just doing CSG in volumes of "weather" (or water or
space or etc.) specifically, rendering might not be necessary, and checking
whether the camera is inside the volume is pretty easy (just add booleans).
 If you need to visualize it, I think wireframes might be enough - it can
get messy, but I can't imagine the resulting volumes being so complicated
that it'd get too difficult to visualize that way.

What Carlo is talking about in terms of "looking out the window" can
probably be done with stencils [2] - something like, if you're not already
in the volume of rain, then
- render the scene without rain
- save the z-buffer from that render
- render the bounds of the volume of rain into a stencil while re-using that
z-buffer (so that iff something in the scene was "outside", the rain
boundary will be rendered on top of it)
- apply the rain to the applicable areas in the stencils (either re-render
or through some post-processing trick)

...but that seems really costly and it needs that render-the-volume step.  A
hack might end up better (like, just do "the easy way" from Carlo's message,
and then allow in-world objects like windows and such to query the weather
and change their textures).


[1] http://en.wikipedia.org/wiki/Constructive_solid_geometry

On Sun, Sep 26, 2010 at 3:06 PM, k\o\w <kow at sapinski.com> wrote:

>  I've been thinking about ways to implement subtractive objects for a
> while now:
> We would flag the object as subtractive and flip its normals.
> During the rendering phase, we would apply a simple clipping algorithm
> to each object to slice off the intersecting geometry.
> The subtractive object would be merged into the original object to
> create the hollowed section.
> The math involved is very similar to the math already used in SL's
> occlusion culling, and if used properly should reduce render time vs.
> trying the create the same effect with many more prims.
> A quick demo of an algorithm for openGL clipping can be found here:
> http://www.docstoc.com/docs/272548/Computer-Graphics-clipping-opengl
> Similar code would be required for the physics, lighting, and shadow
> implementations.
> Subtractive geometry has been a basic feature of many game engines for
> quite a while, and if used right improves performance.
> I like the idea of using prims to define area effects like the presence
> of rain or snow! This is exactly how these kinds of things are done in
> other game engines. Content creators already do this with volume
> detection but it could be supported better by the client and a new prim
> type.
> On 9/26/2010 12:10 PM, Carlo Wood wrote:
> > Hmmm, yes. There is more use to detecting "being inside a prim"
> > and toggling certain render types as a result it seems.
> >
> > Now, an easy way would be to detect if the CAM is inside a prim,
> > and then turn off -say- water fog, or whatever causes one to
> > appear being under water; or turn off rain/snow if that is turned
> > on.
> >
> > However, if then you look out the window, it stopped raining
> > outside too.. so that isn't good enough.
> >
> > On Sun, Sep 26, 2010 at 09:46:09AM -0400, Tammy Nowotny wrote:
> >> This is purely anecdotal (though maybe someone knows more than my
> anecdote): I
> >> have heard that the SL game engine is not good at determining which
> points are
> >> under/above/inside an enclosure such as a building.  Moreoever, legend
> has it
> >> that there is a whole weather system in the engine which was never
> activated
> >> because there was no way to stop rain, snow etc. from going through
> roofs,
> >> walls, etc.
> _______________________________________________
> Policies and (un)subscribe information available here:
> http://wiki.secondlife.com/wiki/OpenSource-Dev
> Please read the policies before posting to keep unmoderated posting
> privileges
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20100927/0f09f690/attachment.htm 

More information about the opensource-dev mailing list