[sldev] How to determine what an object looks like?
Joel Riedesel
joel at ourstillwaters.org
Tue Mar 13 15:01:04 PDT 2007
Tremendous! I can work with this... I'll send off some linden $ for
your fee :-).
Really... this helps a lot. I was getting there but this makes clear
what it is that I'm reading in the code.
Cheers,
Joel
John Hurliman wrote:
> Joel Riedesel wrote:
>> <sigh>
>>
>> Been doing that.
>>
>> Surely it'd take someone who knows this no more than five minutes to
>> describe the wire format for this data.
>>
>> I can read C++ but not as fast as I can write Java...
>>
>> Cheers,
>> Joel
>
> Sure! I charge by the e-mail ;-). Hehe, anyways primitives in Second
> Life are two dimensional drawings extruded along a three dimensional
> path. The two dimensional drawing is called the profile and there is an
> enumeration or constants for ProfileCurve that defines the shape. You
> have your basic square, a triangle, a circle, and a half circle if I can
> recall. Before extrusion the profile can be modified with a cut begin
> and cut end which start at a predefined point in each shape; you'll have
> to either look at the code or look at the shapes to determine what it is
> for each shape. Remember during extrusion the number of faces has to be
> calculated based on whether there is a hollow and/or cut involved which
> can add new faces. The maximum number of faces for any primitive is four
> outer faces + four inner faces + two connecting faces (from a cut) + two
> endcaps = 12 (unless I missed something). Next there is a PathCurve
> which is an enum or constants for the extrusion type. I recall linear
> (straight up) and two different types of rotational (that differ
> slightly to create spheres and torii among other things), although there
> are likely others. Everything is done with unit sizes at these stages,
> so a ProfileCurve of a square would be from -0.5,-0.5,0 to 0.5,0.5,0
> around the 0,0,0 origin (I'm using Z as the up axis like SL, you may
> want to do it differently). With a linear extrusion since you are
> starting at 0,0,0 you go up to 0,0,1 but counting the number of steps
> taken to get there is done using LOD* which is also used to count the
> number of vertices used for rounded profiles. I like how the LL code has
> abstracted this out in to a generic n-gon generator that is used for
> every profile. At each step you calculate a partial transformation of
> the twist, shear, and taper which you'll see translate directly in to
> the rotation, translation, and scale matrices. Apply the matrix
> transformations and throw the resulting points in your vertex buffer; I
> think you might need to be analyzing the TextureEntry stuff as well here
> to properly set the UV coordinates and you are on your own for
> calculating normals/tangents/bitangents or whatever else you need in the
> vertex buffer. The code is split up to fill the vertex buffer using an
> extrusion routine (which does inner, outer, and connecting faces) and
> two endcap routines which handle things on a case by case basis. These
> completed vertex buffers are sent to different parts of the rendering
> pipeline depending on what type of fancy extras are applied. Shiny prims
> go to one, flexible prims to another, basic prims to another, and these
> different paths determine which vertex and pixel shaders will be
> applied. I wouldn't recommend looking at libsecondlife's libprims as it
> is based on outdated information and not a good model to follow (it's
> been moved to the external Google repository to clean up our main repo),
> if you have any more questions just ask here and please attempt to
> organize all of this and add it to the wiki somewhere along with the
> actual enum/constant values for everything.
>
> * There is a bit of a hack in the viewer code to maximize the number of
> vertices used for simple cubes, since cubes are by far the most common
> object and the vertex-based lighting looks better on them with more
> vertices. I've tried removing this hack (so cubes use the minimal number
> of vertices needed to render) and didn't see any change in framerate in
> my limited testing so I left it alone.
>
> John Hurliman
> _______________________________________________
> Click here to unsubscribe or manage your list subscription:
> /index.html
>
>
More information about the SLDev
mailing list