New day new problems

[Dain Shan]

Hi all

 

Im a bit stunned right now, cause i have no explanation for this. So i decided to ask for help or hints here.

Problem ..

I Created a cube with a few extra surfaces ( Triangles ) that i would like as a very low LOD base.

I created the cube in Blender ( 2.5 ) and exported it to collada.

Heres the Blender screen with the cube

 

As you can see 11 vertices and 18 faces. Nothing wrong.

So i wanted to check if i did it right and checked the uploader in todays Developement viewer ( Build 232988 )

And to my great surprise i saw this

 

18 Triangles .. check

But errrr 41 Verts ???

even if i consider that a portion of the vertices got doubled from the 11 .. it cant be ..

Anyone an idea what going on here? I used the advanced method for the uploader.

 

[Rusalka Writer]

I believe every LOD step is supposed to drop to at most one third of the level above. At one time it was a half. I don't know why the rule persists when the numbers get so small, and nor do I understand why jamming the Error Threshold to 0.000 on every level seems to work fine, or what that means, or what I'm doing.

I hope the Wiki will be very, very clear about all the options. I can make the thing do what I want, but I don't know why.

[Marielle Caerndow]

It could be that your collada file from Blender 2.5 is a newer version than the Uploader supports.

More specific: When I use Collada 1.4.1 files, the uploader tells me that the model has much more Vertices than is has in the 3d-App. The previous collada version (1.4.0) works instead. 

You could check it by opening your collada file with a text editor. Somewhere in the first lines it should state it's version. 

[Gaia Clary]

1. Blender 2.5 uses Collada 1.4.1
2. The vertex duplication in principle comes from the fact that when you use sharp edges then the vertex normals take effect. I am still not 100% sure about the exact number which you see. it may indeed be an effect of Collada-1.4.1 (which to my understanding is not (fully?) supported by LL) ...

You can try this:

in Blender go to object mode, then smooth the cube. Alternatively set the crease angle to 90 degrees in the mesh-importer. In both cases you get the expected number of vertices.

Explanation (sort of, please can someone who knows better can give a more precise explanation ?):

You can decide for each face if it shall be lighted with smooth transition to adjacent faces or with a sharp visible angle. When you make the entire object smooth, then you have only smooth transitions. In that case only the face normals are taken into account, so you get exactly the number of vertices that you expect.

When you add sharp transitions, then suddenly the angle between the edges of 2 faces plays a role. Since this angle can change along each edge, now the vertex normals play a role, and this means each vertex has to be counted multiple times depending on how often it is reused in different faces. So each reuse of a vertex is counted probably because the vertex normal information must be stored somewhere. So in principle you have 3 vertices per triangle to count and you would end up in 3*18 = 54 verts.

It appears to me that the vertices in the flat plane at the bottom of your cube do not get counted because some of the vertex normals of the shared vertices point into the same direction...

 As i said, i am far from sure if my explanation is correct. At least some details are missing, so i wuold be very interested to learn what is going on here in detail.

[arton Rotaru]

That error message belongs to the assigned Material Groups to each LOD mesh. I suspect the lowest LOD misses a triangle that is assigned to a material that is present on the higher LODs.

Each LOD requires the same number of material groups aka 'textureable faces'.

[Gearsawe Stonecutter]

where all LODs models created in the same version for Blender?

make sure all LODs have the same number of textures/surfaces or sumeshes.

have to read the errors. As Arton stated the error has noting to do with vert count but the number of material is not the same as the others.

For every material or smoothing group a vert share it is counted again that many times. Picture to planes are a right angle to eachother share the same to verts along one edge. In the 3d program you use it will state 6 verts. Since the same to verts are part of two different smoothing groups they are counted twice in the vertex buffer of the video card. So now you have 8 verts. An 8 vert box would be  24. Since each vert is assigned to 3 smoothing groups.

EDIT:

did a second check uploaded a box with smoothing assigned to each side and got 24 verts then uploaded one with the same smoothing group assined to all and got 20 not 8. so something is not 100% right here

[Dain Shan]

Thanks

 

I Really should have mentioned that i just did a test here.. the mats arnt set right.

That wasn the point. it was about this weired Vertex count i get while trying to upload the model.

I did a quick test here for the smooth shading impact on the modell and well i still think theres something off

But look for yourself

 

Thats what happened when i set the same cupe to a cease angle of 90 degree. Indeed the vertice count rises.

Now what happens if i smooth the whole object ( so the very low LOD ) already in Blender!

 

 

3 vertices are gone.. good so far but still they are higher count then not smoothed :matte-motes-shocked:

 

Ok I will try to load and export it from Blender 2.49b .. only .. can someone point e to an phyton install ( an executable ) that will work? I tried to install the newest but it seems that diddnt work. Blender 2.49 still tells me that it need the Phyton scripts and i cant find an executable for an older version ( so 2.6 of Phyton ). A pointer would be really nice

 

Thanks in advance

 

[arton Rotaru]

 

---

Dain Shan wrote:

Thanks

 

I Really should have mentioned that i just did a test here..

the mats arnt set right.

 

---

What does that mean? Have you assigned any materials or not? Since the error msg belongs still to the materials, this would be good to know, if the upload floater gives wrong information here.

 

Edit: Never mind, now I get it.

[Gearsawe Stonecutter]

I am having a little problem too. If there are no smoothing groups assigned I do get 24 verts for a box as expected but if all have the same smoothing group I get 20 which should be 8. unless there is some limit like the same vert can not share more than 2 face or something like that.

[Dain Shan]

---

arton Rotaru wrote:

 What does that mean? Have you assigned any materials or not? Since the error msg belongs still to the materials, this would be good to know, if the upload floater gives wrong information here.

---

 

Well i try to figure it out right now.

( First time i have this problem at all ... )

Well to make things short i just loaded the low lod as the high lod to circumvent the error, and still got the 18 Faces 44 Verts in the uploader.

 

Since i havnt much time. I will do a detailed test on the materials tomorrow when im back from work.

But there is something attached to materials...

I just deleted EVERY material but one from the model, exportet it and uploaded it as the high lod model again .. in that case the uploader says 18 triangles and tadaaaa 41 vertices thats really really odd.

 

[arton Rotaru]

Yeah, sorry. I got that now. /me needs more caffeine.:matte-motes-yawn:

[arton Rotaru]

But, something what I came across a couple of times is, sometimes the importer add alot of verts on first upload. If I upload that same mesh again, using the .slm file, the verts are cut in half in the uploader.

[Drongle McMahon]

The dialog is giving the number of vertex data entries in the list of vetices in the internal data format, as uploaded. Each of these entries contains position, normal and texture coordiantes (Gaia...there are no face normals). If ANY of these differ, there has to be a new entry in the vertex list. There is also a triangle list that has sets of three indices into the vertex table defining the vertices of each triangle.

For a sharp edged cube (without your extra triangles for now) there are three to six triangles meeting at each corner, depending on how the faces are divided into trangles. Some of these will share the same normal, but there will always be three different normals at each corner (draw vertex normals in Blender to see). So for this reason alone, there must be 8 x 3 = 24 combinations of position and normal, which appears as 24 in the upload dialog. If the same cube has smooth edges, the the triangles meeting at one corner all have the same normal there, so there are only 8 vertex entries.

If the cube also has a UV map with the standard unwrapping, then there are two corners that appear on the UV map with three different UV coordinates and two that appear with two different UV coordinates. So, even for a smooth cube, there are 4x1 + 2x2 + 2x3 = 14 vertex entries. If the UV map has completely separate squares for each quad face, there will be 24 vertex entries, and if each triangle is separate, there will be 36.

Finally, the sub-meshes for different materials are different lists. So the vertices at the edges shared by multiple material regions are always duplicated in two (or more) lists, even if the have the same position, normal and uv coordinates.

Now, you have added 6 triangles. That could give a total of 18x3 = 54 vertex entries, depending on all the above, even if it's all one material. If it's more materials, it could be even more. Finally, from your first picture, it looks as if there might be a very small angle between the two triangles on one quad face. That would make those two have different vertex entries where they would be identical if the quad was absolutely flat. So accuracy of flatness of quads (or other supposedly flat regions) in faceted meshes can affect the vertex entry count. 

Hint1. Faceted meshes will always have more vertex list entries that smooth ones, and cost more in prim equivalents.

Hint2. Fragmented UV maps will increase vertex list counts and prim equivalence cost.

The description of the internal format, on which this is all based (as well as some experiments) is in the wiki.

[Gaia Clary]

I tried it with a Collada export from Blender 2.49b and now everythiong makes sense to me again. And here is the difference between a smooth and non smooth cube as i see it:

These numbers make a lot of sense to me:

 

• for the smooth cube(left side): Each vertex is counted exactly once, so we see 11 vertices as expected.
• For the sharp edged cube (right side): Each vertex is counted once for each different face normal.

You can see how the numbers count up from the following image:

Each corner is connected to faces with 3 different face normals. So each corners counts up to 3. The vertices inside the bottom plane of the cube are each counted once because all attached faces have the same face normal. Hence we get:

8*3 for the corners
3*1 for the verts in the bottom plane

sum: 27 verts

So it looks all correctly handled from the Mesh Importer.

Are you sure that you have removed duplicate vertices in your cube ?

[Gearsawe Stonecutter]

Okay the vert count comes from UV mapping it appears. No?

[Gaia Clary]

Thank you Drongle.

So every day i learn a bit more ;-) My previous example was made without a UV map... With UV map i get 17 vertices for the sharp edge case and 27 vertices for the smooth edge case...

I am no longer sure that i still want to explain the behaviour of meshes in detail. So when we are through this mesh thing, will we then all get a diploma from LL ? For practical usage of Math in 3D ?

I wonder if it would make sense (and help) to see the number of materials in the uploader and maybe some infos regarding the UV map...

[Gaia Clary]

---

Dain Shan wrote:Ok I will try to load and export it from Blender 2.49b .. only .. can someone point e to an phyton install ( an executable ) that will work? I tried to install the newest but it seems that diddnt work. Blender 2.49 still tells me that it need the Phyton scripts and i cant find an executable for an older version ( so 2.6 of Phyton ). A pointer would be really nice

Thanks in advance

---

I could not find a binary python release for python-2.6.7, only a source release.

But a realy easy way to get a full functioning blender-2.49b for windows or Mac with the correct python release and even a slightly enhanced Collada exporter is Jass-pub. That is an all in one binary package. It comes with an installer and installs a functioning blender with no need of any additional software (Primstar-1.1 for Sculpty making is included).

See here for details: http://blog.machinimatrix.org/jass/

And from here you can get a realy enhanced Collada-exporter for Blender-2.49b:

http://blog.machinimatrix.org/spikes-after-mesh-upload-to-sl/

[Drongle McMahon]

Sorry to make it more complicated. I realised the UV map thing when I accidentally left the UV map of a manually decimated mesh as disconnected squares :matte-motes-agape:.

Anyway, I made a picture of what I think the format is. I will put it in a new thread so that Runitai might see it and point out any corrections it might need (or whether it's complete rubbish).

[Dain Shan]

Many thanks all for the links and the hints on the issue, very appreciated!

 

Well it seems we really have to dip very deep into the tech stuff at least.

All the time i was assuming, because the functionallity is already in OpenGL, that the vertices in a mesh only once appear in a list, and not like LL do here, part them in separate lists and therefore double and ( if i understand that fully ) may even tripple the vert count under some circumstands.

Well i guess it is too late now, since the Asset as it is is final.

Oh well. Thats is not that good if you plan to make some Building Block like meshes that a customer could texture all he wants without creating a totally new texture but use the the alreadypresent ressources in SL. ( So buy from a texture maker )

Cause if you want to use all 8 mat slots and also create a half good Very Low LOD it may become very difficult and also very costly to do so. I wonder if that is really necessary.

 

[Drongle McMahon]

The Collada file uses a different form of indexing. It has separate lists of positions, normals and UV coordinates. Then each triangle has three sets of three indexes instead of just three indexes. So the triangle index list is much bigger. So if you have a sphere, all the normals are different and you would be much worse off with the collada method. If you have a fence, with parallel faces on each post etc., then the normal list could be much reduced (although the Blender exporter, for instance, is too stupid to exploit this - it just repeats the same ones over and over!). However, suppose there are 100 such faces. Then you have 600 extra indices in the triangle data but only save 297 (3 per normal) components from the normal table. The elements of both are 16 bits in the internal format. So the scheme chosen will still be more efficient.

As to your concern about the practicality of building components; provided they are not too big, you can still make things that are cheaper than the equivalent prims, amd much better for in-world texturing (with careful UV map work). They have more difficulty competing with sculpties in terms of detail per prim equivalent, but they behave much better with LOD, can be textured much better, and have faces that can be textured and animated separately. The faces can also be discontinuous, which you don't get even with normal prims. I expect there will be an excellent market is smaller building components that will supplement existing stuff to expand the scope and variety of building, but that they will not supplant the existing tools.

[guY Ralior]

It seems to me with this system of not holding a single place as a single place that when you want to make something very detailed texture wise using the locations they have set out for their uploader leaves your model with an extremely high cost which doesn't seem to make the use of mesh worth while. But I guess I will keep in mind what Runitai said, prim count does not equal mesh cost.

[Dain Shan]

Yeah you are right.

 

Today with the new Build of the viewer in sandbox 19 my Meshes have the same prim costs as a build purely made out of common prims.

 

So they raised from a steaming cost of 2.8 to 5.4 ( that would be an equivalent of 5 prims ). Thats a raise of over 90%

Noone is going to buy this ever, or bother even thinking about it.

 

At the moment im really discouraged. I redid the same mesh now 3 times ( actually 4 ) to see if i could bring the streaming cost down .. to no avail. I even deleted all the Materials from the Mesh in blender just to test.

It still is much higher now.

I only can hope that this isnt intensional

[Medhue Simoni]

OMG! I seriously hope the latest build is not anywhere near close. My gator was 5-7 prims. Now, it is 15 prims. My hot air balloon was around 10-14 prims. Now it is 46 prims. I can build the whole thing with about 20 normal prims. This is crazy!

All my small items seem to be ok, but if you build anything of any size, it will cost you.