Error #3670: Buffer too big.

DanielKotzer

when I import a large mesh I get this error:

ArgumentError: Error #3670: Buffer too big.
at flash.display3D::Context3D/createVertexBuffer()

What am I supposed to do? the mesh has many polygons...

JohnBlackburne

How many? It will throw that error if there are more than 0x10000, i.e. 65536, vertices. You might need to break your large mesh into smaller pieces, small enough that they won’t trigger this error.

DanielKotzer

Hi John,

Thanks for the reply.
so basically I need to split the mesh into groups of 65535 not 65536 vertices because I need to have a number that can be divided by 3 because every 3 vertices make up one triangle and I can't cut a triangle into 2 sections because then I'll get holes in the mesh, right?

JohnBlackburne

If you have 3 vertices for each triangle that might be part of the problem. You don’t need 3 vertices for each triangle normally, as vertices are used in more than one triangle. It’s more usual to have similar numbers of vertices and triangles, or a few more vertices than triangles, as once a mesh is started you only need one additional vertex for each new triangle.

The best thing is to put some breakpoints or Trace() statements inside Starling and see how many vertices and triangles it is trying to pass to the Mesh constructor. Then once you know how much over, or many times over, the limits you are you can think about a scheme to cut up the Mesh. Certainly do it by the whole triangle, ideally in some way that makes sense for the thing being modelled.

DanielKotzer

Hi John,

I made a function that if a mesh is big, it is splitting it into peaces of 65535 vertices, and takes 65535/3 of the index coordinates, from the x3d file. works fine, I don't understand why every triangle has to have 3 vertices though, as you say, some vertices are shared by more then one triangle, no point in writing them twice, I really don't understand why the exporter of x3d from 3d max is writing the file this way, maybe it is part of the xd3 file format, and maybe it is a limitation of the exporter, don't know.

Anyway I have another problem. when you rotate the object, you have to rotate the light direction you use in the Fragment shader, otherwise the light will rotate with the object as if it is a spot of color on the object, so I did rotate it, but then if I use a very small object the light spot is not steady while you rotate the object, it dances around, I guess when the calculation is done with very small numbers, with many numbers over the floating point, that makes the output very inaccurate.

maybe this is not the reason, but I can't think of anything else.
here is the code I use to rotate and move the light source to it's correct position, maybe someone can show me a better way to do it.

first I get the rotation and position changes stored in the object, and the groups it belongs to, in a Matrix3D called "drawMatrix":

var tmp:Object3D = obj;
				while (tmp.Parent)
				{
					drawMatrix.prepend(tmp.Parent.modelToWorld);
					tmp = tmp.Parent;
				}

				drawMatrix.prepend(worldToClip);

now I use this matrix to rotate and move the light:

var m:Vector.<Number> = obj.modelToWorld.rawData;

//I begin by setting the light position it it's original place I have to
//change the position in accordance of the object, don't know exactly why but
//this is the only way it works.

				obj.LightPos = new Vector3D();
				obj.LightPos.x = -(sceneLight.Position.x - m[3]);
				obj.LightPos.y = -(sceneLight.Position.y - m[7]);
				obj.LightPos.z = sceneLight.Position.z - m[11];
				obj.LightPos.w = sceneLight.Position.w;

//now I do the adjustment

				obj.LightDir = new Matrix3D();
				drawMatrix.copyToMatrix3D(obj.LightDir);
				obj.LightDir.appendRotation(180, Vector3D.X_AXIS);
				obj.LightDir.appendRotation(180, Vector3D.Z_AXIS);
				obj.LightPos = obj.LightDir.transformVector(obj.LightPos);
				obj.LightPos.normalize();
				obj.LightPos.scaleBy(sceneLight.intensity);

any help would be appreciated
Thanks.

JohnBlackburne

On the number of vertices, you could eliminate duplicates in code. As you read the vertices in if one matches on you’ve read already use the index to that instead. Better to do this in an external tool, though doing it at runtime would still be a win in GPU memory usage and performance.

but then if I use a very small object the light spot is not steady while you rotate the object, it dances around

This could be a number of things. The thing that springs to mind is a normal side effect of lighting a mesh. The lighting algorithm presumably uses normals, which might not exactly match the thing being modelled depending how they are calculated. Increasing the number of triangles should help, so decreasing the number might make things worse, and smaller objects might need fewer triangles.

Better meshes is one fix. It need not be more vertices, it might just be models designed with lighting in mind.

It should not be a problem with FP precision. You have to be dealing with very big worlds before FP precision becomes a factor. Or there’s a problem with your code, but I doubt that’s the case as it likely would do far worse things than move erratically. Lighting, which deals with unit vectors, dot products, simple scaling, should not have to worry about floating point precision.

bwhiting

obj.LightPos.normalize();
obj.LightPos.scaleBy(sceneLight.intensity);

Out of curiosity why are you normalizing the light position?
Surely it should just be where it is in 3d space.

Are you talking about a point like or a directional light?

DanielKotzer

yes a directional light

DanielKotzer

by the way, except for the vertices, is there anything else I can optimize? the normal's array is just the same size but no room for optimization on the normal's right?

DanielKotzer

I just checked it and the problem of the light dancing on the object was not because of its size, but because it was not a perfectly round object, it was not a sphere, but a box which I applied a mesh smooth modifier on, and it is very rounded but not perfectly rounded and that is why the shininess spot was moving around.

JohnBlackburne

You should have a normal for each vertex, so reducing the number of vertices should also reduce the number of normals.

(I’m assuming that if two vertices [in different triangles] are the same then their normals are the same. If not then it could account for the glitchy lighting you described earlier.)

In theory you can optimise normals as they are highly regular vectors. They have only two degrees of freedom so you could store them in 2 floats. You could compress them further by storing them with fewer bits of resolution, so you could pack a normal into a single float/4 bytes.

The only problem with this is you have to unpack it all in the shader, which adds overhead to the rendering code. It’s unclear whether this cost is worth the saving in e.g. uploading data – it probably depends on a number of factors. Also it’s probably not as straightforward as standard lighting code; certainly if I were doing it I would look at a number of methods and approaches.

JohnBlackburne

Ah, yes, using a box to model a sphere probably works well right up until you try lighting it. You will never get a perfectly round mesh, it will always be polyhedral, but there are a number you could use such as a dodecagon, icosahedron or truncated icosahedron (the shape used for footballs).

DanielKotzer

Hi John,

I created a very simple model, only 2 triangles that together form a polygon, but the vertices are not on the same plane, the two shared ones are higher, so you get a curved polygon, now I can make the curve smooth or cornered, by applying a smooth modifier on 3d max. when I export the x3d file of the smooth polygon, the normal's are different then when I export the cornered version.

the cornered version x3d code

<IndexedFaceSet DEF='Plane001-GEOMETRY' solid='false' coordIndex='0 1 2 -1 3 4 5 -1 ' normalIndex='0 1 2 -1 3 4 5 -1 ' >
					<Coordinate point='-555.500122 -550.973633 -555.499512, -555.500122 0.000000 555.500488, 555.500061 0.000000 -555.499512, 555.500000 -550.973633 555.500488, 555.500061 0.000000 -555.499512, -555.500122 0.000000 555.500488'/>
					<Normal vector='-0.524565 0.753184 0.396920, -0.524565 0.753184 0.396920, -0.524565 0.753184 0.396920, 0.231870 0.103994 0.967172, 0.231870 0.103994 0.967172, 0.231870 0.103994 0.967172'/>
				</IndexedFaceSet>

smooth version of x3d code:

<IndexedFaceSet DEF='Plane001-GEOMETRY' solid='false' coordIndex='0 1 2 -1 3 4 5 -1 ' normalIndex='0 1 2 -1 3 4 5 -1 ' >
					<Coordinate point='-555.500122 -550.973633 -555.499512, -555.500122 0.000000 555.500488, 555.500061 0.000000 -555.499512, 555.500000 -550.973633 555.500488, 555.500061 0.000000 -555.499512, -555.500122 0.000000 555.500488'/>
					<Normal vector='-0.524565 0.753184 0.396920, -0.178753 0.523490 0.833070, -0.178753 0.523490 0.833070, 0.231870 0.103994 0.967172, -0.178753 0.523490 0.833070, -0.178753 0.523490 0.833070'/>
				</IndexedFaceSet>

as you can see the normal's are not the same, so how can I just take out vertices from the "Coordinate point" array, I need to have a vertex for each normal, to assign the normal to it?

JohnBlackburne

In that case I don’t think you can. If your normal data is different then the vertices are different, as each gets uploaded with its vertex data. So that would stop you optimising those vertices.

It seems to be an extreme example though, one designed to be difficult to render as it does not actually represent anything. A model of a real object should not have such problems. E.g. a model of a ball will have normals associated with each vertex which are the same for each triangle sharing that vertex – in the case of a ball they are easy to identify as they are radii to the ball.

I am not familiar with 3D Max, but I would think it will have a setting for this, i.e. a way of telling it to have just one normal per vertex, even if it shared between multiple triangles as most are. Or you could do this in your own code, replacing different normals at a vertex with an average of them.

bwhiting

Is it not doing what you want it to?

You will always have one normal per vertex, but if triangles that share vertex positions that have different normals then they will just not share the same vertex but each have their own that happens to occupy the same point in space.

Both outputs are giving you 6 vertices it looks like though, so the standard un-smoothed one seems inefficient by not sharing the vertices. Is that the issue?

DanielKotzer

it is doing what I want, but my question is, if I get rid of 1 out of 2 vertices that have the same position coordinates, what about the normal's? can I put one normal instead of 2 which is the average between the 2? will this work? or will it give me a different result in the way the object surface is rendered?

JohnBlackburne

can I put one normal instead of 2 which is the average between the 2? will this work? or will it give me a different result in the way the object surface is rendered?

Yes. Yes, you can use one normal which is the average of the two (or 3 or more) normals from each face. You can just average the vectors and renormalise the result. Yes, it will look different but arguably it will look better as you will be able to blend them across triangles without discontinuities between triangles.

bwhiting

this might help:
https://www.youtube.com/watch?v=PMgjVJogIbc

That is exactly how you do smooth shading. The vertex normal no longer represents the orientation of the triangle it is associated with but the average of all the triangles that share it within some threshold. (You need the threshold usually or things can wind up looking pretty odd)

Like if you think of a cylinder, you want the normals around the main body of it to be smooth but the sharp 90 degree ends to be unsmoothed.

bwhiting

"quickly" made this image in blender

https://imgur.com/PLeraFn

3 cylinders
1 has smoothing on with no threshold - looks smooth but the top surface is wrong
2 has smoothing on but with a threshold of < 90 so the hard edges at the top and bottom are still sharp
3 flat shaded - no smoothing

DanielKotzer

saw the video, very clear, but then one thing is clear, if the surface is smooth, the normals are the same, as can be seen in the x3d code I have posted before. but if you have a corner on a mesh, it can't have the same normal for both vertices.

In the 2 triengle model I made, vertex number 3 and 5 are the same, but on the cornered model, their normals are not the same, and if I take the normal of vertex number 5 and put it on number 3 or vice versa, it will give me a cornered surface, but a strange looking one, also if I put the average of the 2 normal's I'll get a strange looking surface, it is cornered but has gradient shading, not what I wanted.

So, If I want a model, that has some cornered edges, and some smooth edges, and I want to preserve these different types of edges, and not smooth it artificially, I can't take out any vertices!

Am I right or am I wrong?