Re: [opensource-dev] Mesh rendering: What does indicesp provide?
Hi,
On Thu, Jun 3, 2010 at 12:35 AM, Rob Nelson
nexisentertainm...@gmail.com 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 viewer needs to construct a terrain surface (a mesh) for display. I
have completed an LLViewerObject to this end, except for:
::getGeometry(LLStriderLLVector3 verticesp,
LLStriderLLVector3 normalsp,
LLStriderLLColor4U colorsp,
LLStriderLLVector2 texCoords0p,
LLStriderLLVector2 texCoords1p,
LLStriderU16 indicesp)
What is confusing me is indicesp. I think it has something to do with
connecting vertices, but I'm not sure how.
I think you should find it's a list of indexes into the vertex,
normal, etc arrays that's later passed to glDrawElements, but I'm not
100% sure.
The example code I am
working with uses a mess of lookup tables in the following loop for each
voxel:
//Draw the triangles that were found. There can be up to five per cube
for(iTriangle = 0; iTriangle 5; iTriangle++)
{
if(a2iTriangleConnectionTable[iFlagIndex][3*iTriangle] 0)
break;
for(iCorner = 0; iCorner 3; iCorner++)
{
iVertex =
a2iTriangleConnectionTable[iFlagIndex][3*iTriangle+iCorner];
vGetColor(sColor, asEdgeVertex[iVertex],
asEdgeNorm[iVertex]);
glColor4f(sColor.fX, sColor.fY, sColor.fZ, 0.6);
glNormal3f(asEdgeNorm[iVertex].fX,
asEdgeNorm[iVertex].fY, asEdgeNorm[iVertex].fZ);
glVertex3f(asEdgeVertex[iVertex].fX,
asEdgeVertex[iVertex].fY, asEdgeVertex[iVertex].fZ);
}
}
So, for example, you would convert this code by appending each iVertex
used to indicesp in turn rather than rendering the corresponding
vertex immediately. It appears there's a slight complication in that
all the arrays could contain items that have already been added
previously and these may affect your indices, but you should be able
to figure this out from the existing code.
Aidan
___
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
Re: [opensource-dev] Mesh rendering: What does indicesp provide?
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 vertex at the specified
index on the array. This is done for all data types.
vectorLLVector3 verts;
vectorLLVector4 colors;
vectorLLVector3 normals;
U16 indices[3] = {0, 1, 2, 1};
for(U16 i = 0; i 3; ++i)
{
U16 x = indices[i];
glColor4f(colors[x].mV[0],colors[x].mV[1],colors[x].mV[2],colors[x].mV[3]);
glNormal3f(normals[x].mV[0],normals[x].mV[1],normals[x].mV[2]);
glVertex3f(verts[x].mV[0],verts[x].mV[1],verts[x].mV[2]);
}
Is the most simple example I can think of that would demonstrate how it
works internally.
In the code example you have, the vertexes are drawn one by one in immediate
mode, which is both slow, and undesired. You will have to do some research
into using proper vertex buffers to properly convert the code.
On Wed, Jun 2, 2010 at 19:35, Rob Nelson nexisentertainm...@gmail.comwrote:
I am almost to the point of going crazy. I was going to write a
notecard to a Linden, but I've been knocked out of SL for reasons
unknown, so I'll have to ask here.
In my infinite lack of wisdom, I decided to start working on a project
where I replace the heightmap terrain in Second Life with one based on
voxels. To get to the core of the reasoning behind this switch so I
don't spend too much time on it:
* Voxel-based land allows creation of overhangs/caves/floating chunks
of land (not possible with heightmaps)
* Also adds the ability to handle up to 255 terrain materials
(textures, eventually detail shaders) instead of 4, and the materials
are placed where desired instead of at fractional heights.
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 viewer needs to construct a terrain surface (a mesh) for display. I
have completed an LLViewerObject to this end, except for:
::getGeometry(LLStriderLLVector3 verticesp,
LLStriderLLVector3 normalsp,
LLStriderLLColor4U colorsp,
LLStriderLLVector2 texCoords0p,
LLStriderLLVector2 texCoords1p,
LLStriderU16 indicesp)
What is confusing me is indicesp. I think it has something to do with
connecting vertices, but I'm not sure how. The example code I am
working with uses a mess of lookup tables in the following loop for each
voxel:
//Draw the triangles that were found. There can be up to five per
cube
for(iTriangle = 0; iTriangle 5; iTriangle++)
{
if(a2iTriangleConnectionTable[iFlagIndex][3*iTriangle] 0)
break;
for(iCorner = 0; iCorner 3; iCorner++)
{
iVertex =
a2iTriangleConnectionTable[iFlagIndex][3*iTriangle+iCorner];
vGetColor(sColor, asEdgeVertex[iVertex],
asEdgeNorm[iVertex]);
glColor4f(sColor.fX, sColor.fY, sColor.fZ, 0.6);
glNormal3f(asEdgeNorm[iVertex].fX,
asEdgeNorm[iVertex].fY, asEdgeNorm[iVertex].fZ);
glVertex3f(asEdgeVertex[iVertex].fX,
asEdgeVertex[iVertex].fY, asEdgeVertex[iVertex].fZ);
}
}
Can anyone give me any pointers on getting this converted?
Thanks.
Rob
___
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
___
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
Re: [opensource-dev] Mesh rendering: What does indicesp provide?
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 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
vertex at the specified index on the array. This is done for all data
types.
vectorLLVector3 verts;
vectorLLVector4 colors;
vectorLLVector3 normals;
U16 indices[3] = {0, 1, 2, 1};
for(U16 i = 0; i 3; ++i)
{
U16 x = indices[i];
glColor4f(colors[x].mV[0],colors[x].mV[1],colors[x].mV[2],colors[x].mV[3]);
glNormal3f(normals[x].mV[0],normals[x].mV[1],normals[x].mV[2]);
glVertex3f(verts[x].mV[0],verts[x].mV[1],verts[x].mV[2]);
}
Is the most simple example I can think of that would demonstrate how
it works internally.
In the code example you have, the vertexes are drawn one by one in
immediate mode, which is both slow, and undesired. You will have to do
some research into using proper vertex buffers to properly convert the
code.
On Wed, Jun 2, 2010 at 19:35, Rob Nelson
nexisentertainm...@gmail.com wrote:
I am almost to the point of going crazy. I was going to write
a
notecard to a Linden, but I've been knocked out of SL for
reasons
unknown, so I'll have to ask here.
In my infinite lack of wisdom, I decided to start working on a
project
where I replace the heightmap terrain in Second Life with one
based on
voxels. To get to the core of the reasoning behind this
switch so I
don't spend too much time on it:
* Voxel-based land allows creation of
overhangs/caves/floating chunks
of land (not possible with heightmaps)
* Also adds the ability to handle up to 255 terrain materials
(textures, eventually detail shaders) instead of 4, and the
materials
are placed where desired instead of at fractional heights.
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 viewer needs to construct a terrain surface (a mesh) for
display. I
have completed an LLViewerObject to this end, except for:
::getGeometry(LLStriderLLVector3 verticesp,
LLStriderLLVector3 normalsp,
LLStriderLLColor4U colorsp,
LLStriderLLVector2 texCoords0p,
LLStriderLLVector2 texCoords1p,
LLStriderU16 indicesp)
What is confusing me is indicesp. I think it has something to
do with
connecting vertices, but I'm not sure how. The example code I
am
working with uses a mess of lookup tables in the following
loop for each
voxel:
//Draw the triangles that were found. There can be up
to five per cube
for(iTriangle = 0; iTriangle 5; iTriangle++)
{
if(a2iTriangleConnectionTable[iFlagIndex][3*iTriangle] 0)
break;
for(iCorner = 0; iCorner 3; iCorner++)
{
iVertex =
a2iTriangleConnectionTable[iFlagIndex][3*iTriangle+iCorner];
vGetColor(sColor, asEdgeVertex[iVertex],
asEdgeNorm[iVertex]);
glColor4f(sColor.fX, sColor.fY, sColor.fZ,
0.6);
glNormal3f(asEdgeNorm[iVertex].fX,
asEdgeNorm[iVertex].fY, asEdgeNorm[iVertex].fZ);
glVertex3f(asEdgeVertex[iVertex].fX,
asEdgeVertex[iVertex].fY, asEdgeVertex[iVertex].fZ);
}
}
Can anyone give me any pointers on getting this converted?
Thanks.
Rob
___
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
___
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
Re: [opensource-dev] Oz Linden office hours
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.secondlife.com] On Behalf Of Oz Linden (Scott Lawrence) Sent: Tuesday, June 01, 2010 10:46 PM To: opensource-dev@lists.secondlife.com Subject: [opensource-dev] Oz Linden office hours I'm starting office hours... for now twice weekly. Please feel free to drop in to discuss any open source issues. At this stage, you're more likely to help me with building and developing, so if that's what you're after Merov is probably a better bet. https://wiki.secondlife.com/wiki/User:Oz_Linden/Office_Hours ___ 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 No virus found in this incoming message. Checked by AVG - www.avg.com Version: 9.0.829 / Virus Database: 271.1.1/2914 - Release Date: 06/02/10 14:25:00 ___ 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
Re: [opensource-dev] Mesh rendering: What does indicesp provide?
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 C4 is quite fast, to the point it's quite suitable for realtime deformations of terrain. It details the construction, Level of Detail, material handling for per-pixel lighting, and to some extent the editing tools available in C4 for voxel terrain editing. http://www.terathon.com/lengyel/Lengyel-VoxelTerrain.pdf ___ 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
[opensource-dev] Second Life Community Convention 2010 - Boston - Aug 13-15th
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! - Fleep *2010 Second Life Community Convention -- Coming Together!* The 6th annual Second Life Community Convention (SLCC) will take place in Boston, August 13-15, at the Boston Park Plaza Hotel and Towers, with a new organizing committee at the helm. AvaCon, Inc. has taken over the reins for the convention with a team experienced in the production of SLCC. The goal of SLCC is to bring the many Residents of the Second Life community together to network, build friendships and to discuss Second Life in a common forum. Since its inception, SLCC has been organized *by* the community *for* the community. All of the organizers and volunteers who plan and staff each year’s convention donate their time, expertise, skills and love of Second Life® to create a great experience for attendees. “While we all value our experiences in the virtual world, SLCC allows us to meet each other in person, share meals together, learn from one another, and celebrate the abundant creativity that Second Life® makes possible,” says organizer Misty Rhodes. The Second Life Community Convention presents a number of tracks relating to how people are using SL. Last years convention tracks included Education, Business, Health and Support, Nonprofit, Music, Fashion, Art, Theatre, Poetry, Performance Community. This year organizers are melding areas which have overlapped in the past. “We’ve changed the names of some of the tracks slightly to better reflect the most common topics at the convention, and we expect that Business Enterprise, Education Research, and the Live Music Performances track will be equivalent to ‘full tracks’ with the most sessions per day, while the remaining tracks will be ‘half tracks’ with fewer sessions over all,” explains Rhiannon Chatnoir of the organizing team. AvaCon, Inc. has launched a new website at http://www.slconvention.org which has all the details for the convention content, registration, sponsorship, and volunteering opportunities. The site will act as the center for information about tracks, social events, location, and other details for attendees. Submission forms for proposals for panels and presentations can be found there, along with specifics for advertising in the convention program. Sponsorship opportunities are also available for the Second Life Community Convention. Sponsors have the opportunity to reach a highly coveted target demographic of tech-savvy early adopters, virtual world developers and thought leaders, online community organizers, and the most innovative and dedicated Second Life Residents. In addition to reaching the audience of 350-400 attendees of the convention in Boston, sponsors also have the opportunity to reach an even broader audience of thousands of Second Life residents through the virtual convention site hosted in the virtual world of Second Life http://secondlife.com/. Registration for the convention includes access to the convention content, exhibits, and lunches on convention days. The Early-Bird Registration is available to the first 50 paid registrants at $185. Through July 3, Early Registration is $230, and the Regular Registration price is $260. Because SLCC is organized *for* Second Life Residents *by* Second Life Residents, including teens – there’s something for everyone! Content creators, artists, and musicians attend to share ideas, get creative, and learn new techniques from the pros. Enterprise users and businesses discuss strategies for success and techniques for maximum ROI. Educators present research, best practices, and workshops. From casual users, community groups, and roleplayers to the serious side of Second Life, come to the conference to learn, share, and network with the real people behind the avatars! *AvaCon, Inc.* is a non-profit organization dedicated to promoting the growth, enhancement, and development of the metaverse, virtual worlds, augmented reality, and 3D immersive and virtual spaces. AvaCon holds conventions and meetings to promote educational and scientific inquiry into these spaces, and to support organized fan activities, including performances, lectures, art, music, machinima, and much more. AvaCon's primary goal is to connect and support the diverse communities and practitioners involved in co-creating and using virtual worlds, and to educate the public about the emerging ecosystem of technologies broadly known as the metaverse. Contact: Chris M. Collins (SL: Fleep Tuque) Director of IT Communications Second Life Community Convention 2010 Boston, MA | August 13-15, 2010 Organized by AvaCon, Inc. (774) 654-0010 i...@avacon.org http://slconvention.org ___ Policies and
Re: [opensource-dev] Mesh rendering: What does indicesp provide?
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, 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 C4 is quite fast, to the point it's quite suitable for realtime deformations of terrain. It details the construction, Level of Detail, material handling for per-pixel lighting, and to some extent the editing tools available in C4 for voxel terrain editing. http://www.terathon.com/lengyel/Lengyel-VoxelTerrain.pdf ___ 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 ___ 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
Re: [opensource-dev] Mesh rendering: What does indicesp provide?
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 involves a paper that he distributes freely, I doubt he'll have any problem. He writes these papers with the intention of people implementing them in their own projects. He responds to emails fairly quickly. On Thu, Jun 3, 2010 at 5:55 PM, Rob Nelson nexisentertainm...@gmail.comwrote: 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, 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 C4 is quite fast, to the point it's quite suitable for realtime deformations of terrain. It details the construction, Level of Detail, material handling for per-pixel lighting, and to some extent the editing tools available in C4 for voxel terrain editing. http://www.terathon.com/lengyel/Lengyel-VoxelTerrain.pdf ___ 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 ___ 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
Re: [opensource-dev] Moving #opensl (IRC) to freenode.net
Since nobody reacts, I assume there are no objections. When are we going to move over? -- Carlo Wood ca...@alinoe.com ___ 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
