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] 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
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
[opensource-dev] Mesh rendering: What does indicesp provide?
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
