forget it closed topic, go away

[tabletopfreak Toocool]

nvm, sorry i asked

Edited January 7, 2018 by tabletopfreak Toocool

[OptimoMaximo]

i don't use mesh generators and prim to mesh conversions of any sort, but if your concern is the price, there's one you can try for free, in Firestorm viewer. Right click-->More (a couple of times if i recall correctly)--> Save As--> Collada

This feature in the viewer doesn't generate LoDs or physics shapes files for you though, however, depending on the distance you're viewing the exported objects from, the currently showing LoD is the one being exported out (or so it did last time i checked on this feature, and it was quite long ago)

[Rolig Loon]

The eight face (color) limitation is a limitation of mesh objects in SL. You cannot upload a simple mesh to SL that has more than 8 faces defined. If you try, the uploader divides it into two linked objects. I imagine -- not having ever considered using a prim-to-mesh converter -- that a more complicated model allows you some control over how to manage the faces in that linkset. I have no idea whether any of them give you control over LODs or physics shapes, but that's another possible difference between them.

Edited January 7, 2018 by Rolig Loon

[Chic Aeon]

1 hour ago, tabletopfreak Toocool said:

is it not being able to work with link sets that have more than 8 colors , while other prim to mesh solutions simply and conveniently give you a linked mesh when you have more than 8 colors (faces) to a linkset ..

As Rolig stated the 8 materials (in your description "colors") is a Second Life limit, not the limitation of the prim to mesh program.

So if Program B links the object together (joined in Blender) on export you will have a mesh that when uploaded will come APART again (and often in a very VERY messy way) when it is imported into SL via uploader. Linking into one object is not a solution by any means.

ALSO and very importantly -- and discussed many times on these forums so there should be plenty of info in the archives -- the prim to mesh "solution" is no solution at all. It exports VERY messy mesh with too many vertices (a cube has way more vertices than a simple mesh prim) that take a LOT of clean up if you want any kind of realistically low poly mesh -- which is what we need in SL.  

You still need to learn how to make physics models and perhaps your own custom LODs along with cleaning up the mesh. Realistically it is faster to model from scratch. 

 

So the whole prim to mesh system was always a work around when mesh was very new and aimed at folks who wanted to be able to say that the "made mesh" when in fact, they did not :D.

Do some searches here on the forums and you will likely see why you would be better of to A. Just build with prims or B. Learn how to model mesh from scratch. 

 

 

[OptimoMaximo]

This change of topic title reminds me of another thread about rudeness...

 

 

Edited January 7, 2018 by OptimoMaximo
added link to the thread i mentioned

[Anna Nova]

and I was just about to give the complete answer.  But now I forgot the question.  Doh!

[Pamela Galli]

I assume it is yet another case of someone asking for help and being insulted and outraged when they get it.

[Rolig Loon]

There's a lot of that going around recently. Maybe there's something in the Linden water.

[ChinRey]

16 minutes ago, Pamela Galli said:

I assume it is yet another case of someone asking for help and being insulted and outraged when they get it.

Judging by the replies here, probably not. More likely they figured out it wasn't as easy as they thought and gave up.

 

14 minutes ago, Rolig Loon said:

There's a lot of that going around recently. Maybe there's something in the Linden water.

January is traditionally the season for internet aggression. You see it everywhere on the web, nothing special about this forum there

Edited January 7, 2018 by ChinRey

[ChinRey]

17 hours ago, tabletopfreak Toocool said:

nvm, sorry i asked

Oh no, you won't get away that easy!

I didn't get to see your original post but judging by the replies, you had some problems with Mesh Studio. If you really want to learn how to use it, I suggest you take the starter class at Builders Brewery if you haven't already. Then join the Sweet Meshes group and don't be afraid to ask for help there.

Contrary to what Chic said, I've found Mesh Studio to be a very useful tool for making meshes. It allows you to build inworld rather than on a sterile gray grid and if you know how to handle it, you can make meshes as good as or even better than many of the comemrcial items in SL.

But Mesh Studio and the other inworld meshing tools do not have a magic "create good mesh" button. You still have to know how the tool works and how mesh works in Second Life. Mesh Studio ahs the advantage over the others in that it comes with very good and helpful support but even so, in the end it's not that much easier than modelling programs like Blender.

Edited January 7, 2018 by ChinRey

[OptimoMaximo]

@ChinRey The OP was asking which prim to mesh toolkit is best, considering the various prices they sport, also asking what there is to Mesh Studio to make it worth its higher price, other than a couple of features i can't remember.

Fan of the sterile grid floor here, btw =P

[ChinRey]

1 hour ago, OptimoMaximo said:

@ChinRey The OP was asking which prim to mesh toolkit is best, considering the various prices they sport, also asking what there is to Mesh Studio to make it worth its higher price, other than a couple of features i can't remember.

Oh. That should be of general interest.

To me supporting the original rather than one of the copycats is a point in itself but I understand that not everybody feel that way.

I know of five different prim to mesh converters:

Mesh Studio's biggest and I think crucial advantage for new mesh makers is the Sweet Meshes support group. As I said in my first post, converting prims to mesh is a bit more complicated than just clicking a button to save land impact and if you don't know how to build with mesh already, you really, really, really need to be able to get help. For advanced mesh makers Mesh Studio offers more options for curve resolution.

Mesh Generator is not recommended for beginners since it throws you into the deep end with no help whatsoever. Advanced mesh makers may like its library of premade shapes and the sculpt support but then you have to know how to clean up your meshes and make LoD models in Blender or Maya or such. Those features are absolutely useless on their own.

PrimsToMesh seems to be dead. It was a very promising alternative with some exciting new ideas but it's unfinished, full of bugs (it even duplicates triangles here and there) and, like Mesh Generator, it comes with no usable support. (On a personal note - I suppose it's safe enough to mention it by now: PrimsToMesh is the reason why I'm not a Mole. There were some problems with Mesh Studio just when I was making the demo build Michael asked from me and I decided to try PrimsToMesh instead. The result was so messy it took ages to clean up so I missed my deadline.)

There was an early converter made by the same guy who came up with Pointilism and in the same mad genius style. I don't think it's even available anymore and it's certainly not something you'd want to use today.

Firestorm and Singularity come with a built in converter of course but it's not useful for anything on its own. It taps right into the output of Open GL, retains all the suprefluous polys of the prim and even exports each part of a linkset as a separate mesh. Essentially it gives you the worst of both worlds. In other words, unless you are prepared to spend a lot of time editing your mesh, you're always better off keeping your build as prims. I sometimes use it when I work on SoaS or other grids but even then, most of the time it's faster and better to rebuild in SL than to export directly.

 

1 hour ago, OptimoMaximo said:

Fan of the sterile grid floor here, btw =P

I'll show you something that may make you change your mind.

Prim sphere converted with Mesh Studio, curve resolution 48 - all LoD models identical:

56.809 download weight, that is 57 LI (I didn't make a physics shape for this quck demo so ignore the physics weight).

 

Exactly the same shape created with Blender:

 

 

83.302 download weight - 83 LI.

 

This is an extreme example of course but a shape created with Mesh Studio wil always have a lower land impact than an identical one created in Blender. Add to it that the converted prim comes with a ready made UV map that is sometimes usable right away and often a good starting point for a more advanced mapping.

Edited January 7, 2018 by ChinRey
Correcting some of the typos

[OptimoMaximo]

11 hours ago, ChinRey said:

Firestorm and Singularity come with a built in converter of course but it's not useful for anything on its own. It taps right into the output of Open GL, retains all the suprefluous polys of the prim and even exports each part of a linkset as a separate mesh.

Which is exacly what you just built. Consider that each imported prim, also, has each single face disconnected, and would require a merge on the edges (remove doubles in Blender)

Well that's exactly how prims were made and how they really are. All prims are the result of Maya's NURBS. In Maya, NURBS or polygons come with UV from their creation. NURBS always have a square, full-UV space UV map. A cube was made of 6 NURBS planes snapped (and not stitched) together. This means that it's MeshStudio and the others that do the clean up you report

 

11 hours ago, ChinRey said:

'll show you something that may make you change your mind.

Prim sphere converted with Mesh Studio, curve resolution 48 - all LoD models identical:

Thanks, but this can't make me change mind  I accept the lowest LI i can get from my models because i know how much i optimized them and at upload time, i am sure i can't go any lower. Plus, most of my detailing goes into material textures. Using imported prims as a mock-up isn't my style either. I know how to build something up-to-scale directly in my software. It's just how i trained to work.

Edited January 8, 2018 by OptimoMaximo
added couple of lines

[OptimoMaximo]

On a side note, the "go away" part of this thread title seems to have sparkled more interest than it did with its first title LOL

[Love Zhaoying]

Is this the new “post anything” thread?

[ChinRey]

2 hours ago, OptimoMaximo said:

Which is exacly what you just built. Consider that each imported prim, also, has each single face disconnected, and would require a merge on the edges (remove doubles in Blender)

Yes, except of course that with a direct Firestorm style prim export you have no control over the curve resolution. This was just a simple example though. All prim-to-mesh converters except the one built into some third party viewers, do merge linksets into single meshes, they do merge vertices along the edges and they do include methods to eliminate superfluous faces.

 

2 hours ago, OptimoMaximo said:

Thanks, but this can't make me change mind

I didn't expect you to change your working methods. But don't sell the prim-to-mesh converters short. Mesh Studio is actually a quite sophisticated and advanced 3D modelling tool. The only real limit is that it can only do shapes that can be created from 256 or fewer prims and sculpts (and you don't usually want to use sculpts for the input). For all their flaws, so are Mesh Generator and PrimsTo Mesh. They also give you access to the old autobuilder scripts that are still around. PipeMaker and Mesh Studio for example, is a match made in industrial/steampunk heaven. Even with the post-processing cleanup you can use the two together to make complex piping systems so fast it's not even funny.

I certainly do far more work in Blender than with Mesh Studio myself but to me they are two of several tools in my toolbox and I always try to choose the tool that is most sutiable for whichever job needs to be done.

 

2 hours ago, OptimoMaximo said:

I accept the lowest LI i can get from my models because i know how much i optimized them and at upload time, i am sure i can't go any lower.

But I can.

It's all about compressability. Download weight is a crude estimate of how much data needs to be transferred and that depends as much on how well the data as been compressed as on how much raw data there is. Dae does not have a rigid syntax, it's an xml format - a text document describing how a 3D scene or item is supposed to look. Just like humans, different computer programs can describe the same thing in different ways and that can have a huge impact on how well SL's compression algorithm can handle the file. As @Drongle McMahon demonstrated here long ago, the order the vertices and triangles are listed in is the most important factor but there are others as well. Blender and Mesh Studio seem to be the two extremes there, Blender has the messiest dae syntax of all programs, Mesh Studio the cleanest. You can of course clean up the dae file manually in a text editor before you upload but not even I would bother doing that regularly and I'm obsessed with optimization.

Edited January 8, 2018 by ChinRey

[OptimoMaximo]

25 minutes ago, ChinRey said:

3 hours ago, OptimoMaximo said:

I accept the lowest LI i can get from my models because i know how much i optimized them and at upload time, i am sure i can't go any lower.

But I can.

Please expand more on this concept, because at the current state, what i'm getting from your statement here is that you could optimize my models more/better than i do? in that case my answer would be "i strongly doubt" or worse "you wish"... however, reading your other posts, it doesn't seem to me that you'd be that arrogant, so i strongly doubt of my text perception first

I know how LL manages to encode data quite well, since i'm the one who released the only .anim exporter for Maya so far, plus a rebuilding tool from Maya scene to SL (which doesn't incorporate much encoding knowledge actually). The whole mesh feature was built around the Collada 1.4.1 version, resulted from binary FBX 7.1 (2011) conversion using FBX converter. That's the only way to ensure the cleanest Collada possible for SL from Maya, in my opinion. Tested a lot of times, other FBX versions work BUT the Collada file was output a little different with every version i tried. And in the uploader, the lowest LI i got from the same model comes with the model exported using 2011 version. 

38 minutes ago, ChinRey said:

Blender has the messiest dae syntax of all programs

Collada per se is a dinosaur file format, with lots of flaws. Ever noticed how Collada files aren't that widely spread used, if not for SL use? It can't handle stuff like groups (not like those in Blender, it's a container object) or geometry parenting, thing that instead is very much required for an exchange format. But as the Wiki states about it, paraphrasing and not quoting here, it's an animation exchange format. Which means you animate, BAKE animation in the file and export what's the animated result, stripping away anything else. If you use FBX converter, also, you will see how FBX files in the order of the Kilobytes end up in a Collada file of size in the order of Megabytes. With this said, it's probably a matter of parsing order, not syntax, what you're talking about. And if something like that becomes a problem, in Maya you just recalculate the vertex order and the model gets a clean(er), better organized one, aimed at better binary compressability, since Maya saves binary (.mb) and ascii (.ma) files. If it wasn't for @Gaia Clary , maintaining also the default Collada exporter, Blender wouldn't even have a working Collada exporter for SL (at least working as a standard Collada which didn't work for SL). Looks like (not saying that you are) you're assuming that content creation and file formats standards revolve around what's available in Blender, while the truth is that Blender users have struggled quite a lot to have stuff working in SL, before Gaia and the Machinimatrix guys took this burden on their back. This truth also includes the fact that everything inside SL was made in Maya, and things like Collision Volume bones rely on features that Maya has, and Blender doesn't support: each Collision volume bone has specific rotations and scale settings, which goes with the free bind pose skinning. In Blender, you can't successfully attach something to armature, if each single bone isn't set to zero rotation and scale at 1, see what happens if you do, without Avastar to handle the custom bind pose. But i'm digressing. A file's parsing order can also depend from the 3D software architecture it was output from, how the data is being stored and retrieved internally to the software. Blender notoriously uses a quite unique architecture.

[ChinRey]

1 hour ago, OptimoMaximo said:

Please expand more on this concept, because at the current state, what i'm getting from your statement here is that you could optimize my models more/better than i do? in that case my answer would be "i strongly doubt" or worse "you wish"... however, reading your other posts, it doesn't seem to me that you'd be that arrogant, so i strongly doubt of my text perception first

At least I'm not arrogant enough to claim I can explain it in detail. I think Drongle can, that's why I tried to page him earlier in this thread. @arton Rotaru, too come to think of it - and @TheBlack Box but there's not mcuh chance we'll hear from him here.

I have tested it quite extensively though so I think I have a fairly good grasp of the practical implications. Here's another example. Eight cubes, positioned and rotated more or less at random. Converted to mesh with Mesh Studio and with full LoD I get:

3.743 DL.

If I import it to Blender and reexport it with no modifications whatsoever, I get:

3.574 DL. That isn't much of a difference but keep in mind that this is supposed to be exactly the same mesh - no changes to it whatsoever.

Once I start editing it in Blender, the download weight goes up fast. Here I have converted the tris to quads before exporting:

and I get 4.676 DL.

These are not random differences, it's a consistent pattern. A mesh created with Mesh Studio will always have a lower download weight than an identical one made with Blender. Even after heavy editing, a mesh originally created by Mesh Studio tend to have a slightly lower download weight than one created from scratch in Blender.

 

2 hours ago, OptimoMaximo said:

With this said, it's probably a matter of parsing order, not syntax, what you're talking about.

It has to be a little bit of both. The big difference between the second and third of my examples are almost certainly caused by the parsing order but I can't see how that can explain that small difference between my first two examples.

 

2 hours ago, OptimoMaximo said:

 And if something like that becomes a problem, in Maya you just recalculate the vertex order and the model gets a clean(er), better organized one

I did make a fourth version of my eight cubes: no. 3 with a different vertex order. This time it made no difference to the download weight, it stayed at 4.676. Sometimes it does though and when it does, it can go both ways. But Blender's tools for sorting vertices is rather crude and it wouldn't surprise me at all if Maya can do better.

 

2 hours ago, OptimoMaximo said:

This truth also includes the fact that everything inside SL was made in Maya

That's not really relevant for Mesh Studio since it doesn't depend on the SL software to create the mesh. What The Black Box did when he made Mesh Studio was reverse engineer the entire prim system and make his own custom software to handle it. The only thing the inworld Mesh Studio script does, is read as much of the prim properties as a script possibly can and send it to a server far away where the real magic takes place.

 

2 hours ago, OptimoMaximo said:

Looks like (not saying that you are) you're assuming that content creation and file formats standards revolve around what's available in Blender

I don't but I can only speak of what I know. A Maya license is way beyond my budget (and probably the budget of most SL creators) so I have no first hand knowledge of what it can and can't do. I have been told by people who have experience with both programs that Blender can do pretty much enything Maya can but I don't necessarily buy that.

[OptimoMaximo]

4 hours ago, ChinRey said:

Dae does not have a rigid syntax, it's an xml format

Oh and another thing: syntax is by definition rigid. Again it's the parsing order that can be flexible. If syntax is not respected, a syntax error occurs because a command or attribute can't be "flexible". Arguments need to be respected in order for the correct file construction or the parser won't recognize what some text may mean with a differently ordered/incomplete set of arguments. On the other hand, the order in which this data gets dumped to file is the parsing order (for when the file needs to be read). I'm even overlooking the remainder of your sentence

[OptimoMaximo]

35 minutes ago, ChinRey said:

3 hours ago, OptimoMaximo said:

With this said, it's probably a matter of parsing order, not syntax, what you're talking about.

It has to be a little bit of both. The big difference between the second and third of my examples are almost certainly caused by the parsing order but I can't see how that can explain that small difference between my first two examples.

For the "little bit of both", please read my previous post. It's certainly a matter of parsing order, where the uploader accepts different orders as per Collada's definition, which allows it. Now the order in which this data comes in might make the parser struggle more or less, depending on what the basic .llm encrypting was primarily built for to have as optimal order. One hint of this is that the scripts in these converters take the data from what SL whips out for your screen to render, which is the native order and therefore a Collada generated back from there MUST be the most efficient file version.

As a parallel, i can tell you my experience on dumping a .anim file which uses the same type of binary data dumping. With all data correct and in place, the order in which i fed this data to the file writer affected the working order of my animation file. I won't go into detail here, IM inworld if you're interested.

35 minutes ago, ChinRey said:

I have been told by people who have experience with both programs that Blender can do pretty much enything Maya can but I don't necessarily buy that.

Yeah don't buy that, there are tools which can be used for SL stuff that Blender doesn't have. You have to get Avastar for a Component Editor for vertex weights editing, just to name one.

 

35 minutes ago, ChinRey said:

3 hours ago, OptimoMaximo said:

This truth also includes the fact that everything inside SL was made in Maya

That's not really relevant for Mesh Studio since it doesn't depend on the SL software to create the mesh. What The Black Box did when he made Mesh Studio was reverse engineer the entire prim system and make his own custom software to handle it. The only thing the inworld Mesh Studio script does, is read as much of the prim properties as a script possibly can and send it to a server far away where the real magic takes place.

Above i partially answered it, since it DOES start from the mesh that the viewer unpacks, which was created in Maya. Leave alone the XML export as it is a raw binary to text conversion from the internal mesh format. But exactly like you did, trying to explain to me the details of a Collada file, i got carried away with some history there.

35 minutes ago, ChinRey said:

I did make a fourth version of my eight cubes

I'm now wondering, are the sizes consistent? Blender default cube is 2 meters in all 3 axis, regular cubes in SL are half a meter. I'm sure you're keeping this consistency, but you haven't mentioned it so...just asking.

Edited January 8, 2018 by OptimoMaximo
fixed a few typos

[ChinRey]

58 minutes ago, OptimoMaximo said:

Oh and another thing: syntax is by definition rigid.

Dae is a variant of XML, a markup language rather than a binary file format. One of the two main ideas behind xml (and yes, I'm afraid I'm old enough to remember the discussions back when it was first introduced) was to allow a looser, more flexible syntax than traditional file formats. Come to think of it, this may be why LL chose it rather than dedicated binary mesh file formats. The early LL developers did have a affinity for xml and had a tendency to use it even when it clearly wasn't the best solution.

 

37 minutes ago, OptimoMaximo said:

One hint of this is that the scripts in these converters take the data from what SL whips out for your screen to render

No they don't. I'm not sure how familiar you are with lsl but the data you can get with llGetLinkPrimitiveParams() is the pure prim properties, straight from the assets database and tapped long before it gets anywhere near any software that converts it to renderable mesh. It's not even on the same computer. Scripts are handled by the server, rendering - including converting the prims to mesh for display - is handled by the client.

 

37 minutes ago, OptimoMaximo said:

I'm now wondering, are the sizes consistent? Blender default cube is 2 meters in all 3 axis, regular cubes in SL are half a meter. I'm sure you're keeping this consistency, but you haven't mentioned it so...just asking.

Oh, sorry if I didn't make myself clear there. The Blender examples used the Mesh Studio dae file as the basis. I imported it into Blender and then exported it twice, first without making any modifications to it, then with one minor change (changing the tris to quads). Size doesn't affect the dowload weight for meshes with all LoD models identical anyway.

Edited January 8, 2018 by ChinRey

[OptimoMaximo]

33 minutes ago, ChinRey said:

No they don't. I'm not sure how familiar you are with lsl but the data you can get with llGetLinkPrimitiveParams() is the pure prim properties, straight from the assets database and tapped long before it gets anywhere near any software that converts it to renderable mesh.

Yes they do. Since the prims are strictly parametrized and encoded meshes, all you need is to get their parameters, apply the parameters and create a mesh from the prim definition. Which is what is encoded in the internal mesh format. Take that and apply the necessary transforms to get a copy of your prim model. It wouldn't surprise me if the mesh from a viewer export came with the root prim's center at the center of the 3D software scene: prim positions are taken relative to the root prim, which conveniently translates to the center of a 3D scene for reconstruction.

Try to load an XML prim build file changing the order of their parameters keeping syntax correct, and see what happens trying to reupload it.

33 minutes ago, ChinRey said:

The early LL developers did have a affinity for xml and had a tendency to use it even when it clearly wasn't the best solution.

Sure they had this affinity, it is a convenient file format for easy binary-text-binary conversions. Figure that they were so fond of XML that the internal animation files is binary encoded, all meshes get also encoded into binary formats, internally. XML meant for them that someone can easily output a text file to translate data with Maya, which at the time supported only 32 bit signed data values. Actually, it's MEL (Maya's native scripting language) that has this limitation still to date, indeed i had to use Python to write my anim exporter. But python wasn't integrated in Maya, at the time.

33 minutes ago, ChinRey said:

Dae is a variant of XML, a markup language rather than a binary file format.

Thing that i know, but again if the parser expects some data being fed in with a set of parameters and some are missing or incomplete, parsing won't occur, or at least it would, just incorrectly. That is plain fact. Indeed you can get parsing error when the order is too messy for the uploader, or XXX block missing (where these X are substituting an acronym, most seen is MAV when materials have issues) , as an error. The parsing error explains itself. The XXX block missing is a syntax error, where a block of data is expected and isn't to be found anywhere. It may well be in there, but if the construction of such block misses a "marker" for the end of the previous statement, it's seen as part of that and not recognized, therefore not found and missing. Pretty much like LSL, when a semicolon is missing and gives you a syntax error: it sees the next command as part of the previous, creating a wrong syntax.

Now if you export a binary FBX doesn't mean it's human unreadable. FBX is Autodesk take at evolving Collada. What the binary or ascii definitions mean, is the type of C struct being used for values. ASCII is just plain text for all types of data, leaving the software to figure out the type of data by its look and by the attribute it's attached to. The binary one instead also leaves a trace of the data type. Indeed, in Maya it's best to save scenes with objects in .mb (binary), while shading networks are best suited for the ASCII file (.ma), because all you need in there is just names of connections, files and their paths and the material values which are established in the software, so a string representation works fine.

Edited January 8, 2018 by OptimoMaximo
few missing words

[OptimoMaximo]

1 hour ago, ChinRey said:

Size doesn't affect the dowload weight for meshes with all LoD models identical anyway.

I don't know if this is for testing purposes only, but for what i can observe inworld, prims dynamically get different lods depending on the prim size and viewing distance.

[ChinRey]

1 hour ago, OptimoMaximo said:

Yes they do. Since the prims are strictly parametrized and encoded meshes, all you need is to get their parameters, apply the parameters and create a mesh from the prim definition. Which is what is encoded in the internal mesh format.

We may misunderstand each other here. What I'm saying is that the software Mesh Studio (and the other prim-to-mesh converters except the FIrestorm/Singularity one) uses to interpret the prim properties and turn them into vertices and triangles, is completely separate from the software that doesn the same job in the viewer. The only thing they share, is the input data.

It would be interesting to know which libraries the various applications use to convert to and from COLLADA since the choice there may be significant. I know Maya uses FCollada and that seems to be the most obvious one for Second Life too. It makes sense to assume the Blender interpreter is built on pycollada and Mesh Studio's on Three.js but I'm just guessing really.

 

1 hour ago, OptimoMaximo said:

Try to load an XML prim build file changing the order of their parameters keeping syntax correct, and see what happens trying to reupload it.

It doesn't work? I take your word for it.

It does work with dae file though - at least to some degree. One of the immediately noticeable differences between between a dae file generated by Mesh Studio and one generated by Blender, is that <library_materials> and <library_effects> elements are swapped. Mesh Studio lists the materials before the effects, Blender does it the other way round.

As far as I know (I may be a bit outdated here), the XML specification does not mention anything about ordered or unordered elements so it's essentially up to each developer to decide. The specs do however specifically state that attributes are unordered.

 

1 hour ago, OptimoMaximo said:

Figure that they were so fond of XML that the internal animation files is binary encoded, all meshes get also encoded into binary formats, internally.

I'm not sure if I would have been surprised if you had told me they do use xml formats internally.

I was thinking more about security than practicality actually. There is some data LL has include in publically available xml files they would have preferred not to distribute in a humanly readable format. I know that for a fact since I mentioned it to a Linden once and he was rather shocked. There were no big issues as far as I know though, just some minor thoughtlessness.

 

18 minutes ago, OptimoMaximo said:

I don't know if this is for testing purposes only, but for what i can observe inworld, prims dynamically get different lods depending on the prim size and viewing distance.

They do but all prim to mesh converters ignore this, they give you one model and one model only. The script based ones allow you to specify the vertice resolution - including some intermediate options that don't exist for prims. Mesh Generator and PrimsToMesh even let you increase the resolution way beyond what you get even at the highest LoD level for the prims. The viewer based converter gives you the LoD model that happens to be in view at the time you save.

Edited January 8, 2018 by ChinRey

[OptimoMaximo]

50 minutes ago, OptimoMaximo said:

Yes they do. Since the prims are strictly parametrized and encoded meshes, all you need is to get their parameters, apply the parameters and create a mesh from the prim definition. Which is what is encoded in the internal mesh format. Take that and apply the necessary transforms to get a copy of your prim model. It wouldn't surprise me if the mesh from a viewer export came with the root prim's center at the center of the 3D software scene: prim positions are taken relative to the root prim, which conveniently translates to the center of a 3D scene for reconstruction.

I'll expand better on this section. If you get the encoded prim meshes from the assets and use it as a set of prefabs in your externally held application, your SL scripts just need to pack those parameters and the relative transformations (size, rotation and position) and send all over to the server, which has all the files needed to construct a Collada from LL's native meshes descriptions. Who got these prim meshes converted them from LL's mesh encoding (binary) which describe the mesh in all the statii it can get using the torture parameters, then applying the transforms. It's not much different from what Machinimatrix's PrimStar had as a complex sculpty build reconstructor via LSL script. You had to put a prim in the inventory, along with sculpt maps. Using always the same prim, the script rezzed as many copies of that prim as many sculpt maps there were in inventory, change the parameters first, then the transforms to reconstruct the multi-sculpt build you had. Doing the reverse is similar to exporting prims with the viewer: collect prim data (torture parameters and the likes), then the transforms and rebuild from premade meshes.

Now if mesh studio does the cleanup and still uploads low LI is because who made that system made sure that the cleaned up mesh conformed to how a prim was built in terms of the parsing order, making them match as closely as possible.