Hi,
Here's a quick update of where we stand with Snowglobe 2.0.
All patches from 1.x have been analyzed and those that need to be ported
have had a JIRA created to track them. All this is summarized in the
spreadsheet:
-
https://spreadsheets.google.com/ccc?key=0AgvC7hm5YZqcdHVXb05iTE0wTFc0bWptTW4
Since nobody reacts, I assume there are no objections.
When are we going to move over?
--
Carlo Wood
___
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/OpenSource-Dev
Please read the policies before posting to k
I'm sure it wouldn't hurt to ask Eric Lengyel if one could create their own
LGPL implementation of Voxel terrain LOD based off of his paper. He'll
usually only ever say no in the event that it involves distributing code to
one of his commercial products (such as the C4 Engine). Since in this case
It may be quite fast, but I don't think it's GPL, so I can't really use
it. I'll have to come up with my own MacGyver'd implementation of LOD
and stitching after I finish the initial implementation.
Rob
On Thu, 2010-06-03 at 11:42 -0500, Jonathan Goodman wrote:
> It may be a bit late for this, bu
Hi all,
Sending out the official announcement about this year's SLCC 2010, we look
forward to a really terrific convention this year! Be sure to visit the
website at http://slconvention.org to submit a proposal, volunteer to lead a
track, or just plain volunteer - we always need the help!
- Fle
It may be a bit late for this, but I would actually like to point out a
paper that was recently released that details the construction of terrain
from voxels in the C4 Game Engine (1.5.9, and the LOD algorithms introduced
in C4 2.0 that was released a few days ago). The implementation in place in
I would enjoy coming to your OH but I have a slight scheduling conflicts
both in world and RL. On Tuesday's I'm hosting an event and on Wednesday's
im working RL during those times.
-Original Message-
From: opensource-dev-boun...@lists.secondlife.com
[mailto:opensource-dev-boun...@lists.se
As for conversion, it looks like you should just convert asEdgeVertex
asEdgeNorm and the results of vGetColor(for each normal in asEdgeNerm) into
arrays, and build the index table from the results of iVertex. It more or
less looks like it was written to use vertex buffers, but was converted to
some
Thanks, I've successfully converted the code. I appreciate the
perspective.
Thanks again,
Rob
On Thu, 2010-06-03 at 07:53 -0400, Zabb65 wrote:
> >From what I remember...
>
> Indicesp is a pointer to an array of U16s that are offsets to vertexes
> in the vertex buffer. Read it as the vertexes
>From what I remember...
Indicesp is a pointer to an array of U16s that are offsets to vertexes in
the vertex buffer. Read it as the vertexes normals and all this other stuff
being in static arrays. It then runs through the indice list and runs the
associated glVertex3f commands or whatever on the
Hi,
On Thu, Jun 3, 2010 at 12:35 AM, Rob Nelson
wrote:
> I am working on the rendering code in the SL viewer at the moment,
> having completed the server-side code and some of the client-side
> packet-handling classes. However, I have zero familiarity with OpenGL,
> so bear with me.
>
> My viewe
11 matches
Mail list logo
