maths for prims

Hi there!
Is there any description of how each prim is actually created?

I doubt they are simple equations, probably a mix of programming and math?

When editing a prim, hitting the "more>>" button in the edit window opens a large dialog box that has the numeric representations of all the shapes (L*H*W, hollow, material, etc).

if you want the actual mathematics object creation, ie vectors or ray tracing or wutev, you have to check out the open source physics engine 'havok', as that is what SL uses for physics.

> If you want the actual mathematics object creation [...] you have
> to check out the open source physics engine 'havok'

Thank you Kurzweil. Googling around I found www.havok.com but it's not open source and they give evaluation copies only to qualified game developers. Maybe is there another source of information about it?

I'm asking to see if there's any way of producing a better "importer".

Approximating the surface of an object using triangles (or other polygons) will inevitably lead to a very high number of prims wich make this approach unfeasible.

If we could play with the equations of the prims we might be able to slice the object and find a smaller set of prims to approximate it.

I'm fully aware of the complexity of this approach that would require, among the other things, analyzing the topology of the objects, I just wanted to see if anyone already explored that path.

R.D

Hi Rael

Welcome to SL.

The client translates the prims into the triangles and meshes that many 3d developers are very familiar with (not me though). I understand that prims involve the smallest amount of communications from server (the sim you are on) to client (the pc or mac you are on). You do not have any way to upload anything except textures and prims to build things with. The cllient has a renderer to convert these prims into objects understandable by the display card via opengl.

The libsl folk might appreciate someone who can display these prims more efficiently than the official client can. Could that be you?

Ed

Importers so far either use one prim per triangle for a polygonal mesh, or are specifically designed to import from scripts running in other 3d programs, producing objects made out of equivalent prims in those programs.

Approximating general 3d objects with prims seems like a very hard problem, perhaps similar in difficulty to AI vision. The prims are very restricted in many ways. For instance, there are a number of ways to make a (non regular) tetrahedron, but given 4 arbitrary points in space, I don't think there is in general a one prim way to make a tetrahedron with those vertices.

If we can't even do this... well, it's going to be hard to get very far, but I'd be interested to hear your thoughts.

Much of the artistry of prim building is in finding ways to modify the prims to realise a certain shape, and this really is an art, not one that I see algorithms being able to do anytime soon. (And certainly not before we get proper meshes in SL )

@Ed
Thanks for the suggestions! I went through libsl code (screenviewer seemed to be the most relevant piece). I'm not a C# expert (an euphemism to say that I can barely read the code) but I guess they rely on XNA for the actual conversion. Anyway, I have to have a closer look at it. I tried to stay away from MS tools so far but maybe it's time to install VS Express.

Maybe understanding how they map prims to XNA I can get a sense of how they are built.

@Seifert
Yes, it's an hard problem for sure! Your point on the tetrahedron is very interesting, Maybe we could prove that two prims are always enough but I would not be able to start figuring out how to prove it without knowing which type of surface is the "cube" prim.

Interesting you mentioned AI. I was thinking (and please take it as a brianstorming input) something along these lines:

1. identify topological/geometric properties of prims
2. Divde the "surface described" object in pieces so that each piece has the property of one (or more) prim.
3. Use a genetic algorithm (or similar) to find the prim parameters that minimize the distance between the object piece surface and the prim surface

Point 3 is complcated by the fact that the "internal" surface of the prim is irrelevant (or maybe this is a simplification?)

About point 2 it's like we were asking: "Given this set of faces, would a cylinder approximate them better than, say, a sphere?". I don't know if this is a solved (or even tractable) problem

In my mind is like if I would wrap an object with a prim adjusting its parameters so that it fits the object as best as it can. If the result is not acceptable I might be able to split the object in smaller pieces and try again with other prims.

I understand we will never be able to approximate ANY object with primes at ANY level of detail but if we could do it for a reasonable set of objects I'm sure it would be useful.

R.D

All prims are an extrusion of a base polygon along a path that modifies the scale and the position of the polygon.

"Cut begin" and "cut end" modify the base polygon.

"Taper" and "shear" modify the path the polygon takes.

The path starts at –(1/2 * Z scale) and progresses to (1/2 * Z scale)

The base polygon is sized based on the X,Y Size and the shape.

1. Boxes use the numbers directly.
2. Circular objects use the LOD (Level of detail) to convert to a polygon where the corners are based on sine and cosine.

The path is then created based on the object type.
1. Boxes and tubes just use taper and shear.
2. Spheres use 1/2 of a sine wave to scale the path.
3. Tori use a circular path to fly the base polygon in a circle.

The taper can go positive or negative and the absolute value is used to shrink one or the other side of the path.

So here is code for a box without a cut. It's not quite right, but It's a starting point.

vector Scale = <x,y,z>;   //meters
vector Taper = <x,y,0.0>; // -1 to 1
vector Skew = <x,y,0.0> ;// -1 to 1

vector TaperStart ;
vector TaperEnd;
if (Taper.x >0) {   //I might have this backwards
	TaperStart.x = 1;
	TaperEnd.x = Taper.x;
}else{
	TaperStart.x = Taper.x;
	TaperEnd.x = 1;
}

To do. repeat for Y

To do.  repeat for taper.

Vector Point
list BasePolyGon
Point.z = 0; not used
Point.x = (Scale.x  * -.5); 
Point.y = (Scale.y  * -.5); 
BasePolyGon += Point

To do.  Repeat for other three points.
Ect... + -, + +, - +

//Extrude path for boxes
list PointList;
//A box has two points on the path so 
for (p = 0 to 1; ++i){
	//normalize p to (0 to 1)
	vector sc;
	sc.x =  (ScaleStart.x * (1-p)) + (ScaleEnd.x * p);
	sc.y =  (ScaleStart.y * (1-p)) + (ScaleEnd.y * p);
	vector t;
	t.x =  (TaperStart.x * (1-p)) + (TaperEnd.x * p);
	t.y =  (TaperStart.y * (1-p)) + (TaperEnd.y * p);

	for (int i = 0 to listCount(BasePolyGon) -1 ; ++i){
		
		BasePolyGon.x = (BasePolyGon.x * t.x) + sc.x;
		BasePolyGon.y = (BasePolyGon.y * t.x) + sc.x;
		BasePolyGon.z = (p - 0.5) * Scale.z;
	}; //for i
	PointList += BasePolyGon;
};//for p

There is probably better code examples in LibSL

Thanks Grumble, this is what I was looking for!

I wasn't able to find anything about that into libSL, it seems to be focused on communication between a Client an the SL world. I'll dig further anyway.

R.D

Perhaps a wiki section would be good.

Can I say it's related to LSL by linking to it from the SetPrimPrams page?

To bad there isn't a wiki on building.

Also check out the Open Source Metaverse Project and FractalSpline for C# source code to render SL-style prims. FractalSpline in particular has pretty much everything you would ever want to know about the math involved in creating and rendering SL-style primitives.

I wrote sceneviewer, the code in it for creating prims was based on the FractalSpline and while it uses XNA data types and math routines the ideas are fairly generic. You are taking prim parameters and building 3d vertices; all prims are built with a <1,1,1> size and no rotation and transformation matrices are used for the positioning, scaling, and rotation in world. grumble gave a good overview, there are two extrusion types that I am aware of which is linear (boxes, cylinders, etc) and rotational (spheres, torii, etc). You start by drawing a 2D shape and then extruding it vertically (which is the Z axis in SL), taking in to account twist and shear and other properties when doing the extrusion. Slight correction, LOD is used on linear extrusion path prims as well; any client would need it if a cube has a twist applied, but the SL viewer uses it even if there is no twist since the lighting is vertex-based and you get more accurate lighting with more vertices per prim. Sceneviewer will use per-pixel GPU shaders so it tries to make prims with as few vertices as possible.

Another difference between sceneviewer and SL is that sceneviewer attempts to categorize prims in to basic shapes and then follows instructions for rendering cubes, cylinders, etc. FractalSpline does the same thing, but SL has a single generic prim renderer with a lot of different code paths. That's how it's able to handle anything you throw at it including tortured prims and things it shouldn't even understand.

#libsl-dev on EFNet if you want to chat more