3rd party imports

I also have met more builders in here than anyone else.
In fact there are so many that do a good job it makes most people not want to even try.

Then again I am one of the builder/texture/semi-scripters so maybe I just get drawn to those people and it just seems like there is more of them around from my view.

Hard for everyone to see the painting when we are all in it I guess.

Maybe I should have said this better. Prims are individual units meant to emulate common shapes - boxes, spheres, torii, etc.


The calculation for that is not very computer intensive at all; I even have a test script for 40% of prims so far (still working). Keeping track of the generated faces in 3D causes lag, however, as does the time necessary to transfer the data from point A to point B.


Prims really shine where objects are simple at a conceptual level. Say, a desk. Instead of transmitting ~30 polygons, you would transfer five box prims. However, this is not the case in more complex works like a human face, which can easily shoot up to hundreds to look even reasonable, with lots of excess crap to render.


Further, prims come with a lot of "add ons" denoting their would-be fixed length nature. Here's a list of what prims keep track of individually, just in llSetPrimitiveParams:



And this still leaves out the fact they keep track of their name, asset UUID, creator, owner, permissions levels, particle settings, script pin... the list goes on. That's hardly conjecture - these are tested facts.


Now, compare this to Adam's take on the problem, adding the necessary bits of excess code to 3D models instead of prims, and voila - fewer, but far more variable, records to keep track of in the system.



Long story short: prims are a freaking lot of data, but their size is easily fixed in the system. Meshes aren't, so they would span a broader range than existing prims, data-wise, lagwise, and most likely, draw-wise, as prims are drawn procedurally and are thus easier to ballpark than meshes. This could be a good thing or a bad thing, but the fact remains -- it is not the case in Second Life.

Just let me bend prims, and create antiprims.

And don't give me guff about booleans on prims crashing computers because some OpenGL implementations don't do the right thing... do the subtractions in the client and feed the resulting mesh to OpenGL. There's no bandwidth problem *there*.

*puts Prims next to Argent's Anti-Prims*

"Fool! You'll kill us all!"

Bah, cartoon characters are immune to primular explosions and XYZ radiation! We can walk out of the most devastating explosion with nothing worse than a coating of soot to shake off!

Just keep the paint-thinner the heck away.

I did some testing a few weeks back, and I think SL's single-threadedness is one of the big reasons it lags. It does a lot of 'waiting' for a particular task to finish.

I used my smartswitch to rate limit the port my SL computer is connected to, down to 50kbps. SL's framerate went beserk, from 50fps down to 0.3.

However, back to the task at hand.

Prims are laggy on the GPU because there's a lot of extra filling that doesnt need to be done. A good number of triangles are not shown, but drawn anyway - take the humble torus as an excellent example. If you make a teapot from a torus and a sphere linked together, your going to be wasting half that torus, plus all the culling that's not being done.

Meshes, even after the expense of converting them to a displaylist; should be significantly faster than prims, simply because you are not wasting as much.

If LL imposes a limit of '100 tris = counts as 1 prim', you wont see people importing half a million tris models; but the quality of work will shoot up dramatically - and as a bonus, framerates will probably improve because there isnt so much wasted filling.

I dont think there's any performance reasons stopping the implementation of meshes - I think it's mostly an architecture one; LL's locked into prims, and wont be fixing it anytime soon.

Chances are, the solution to that problem is the same as the solution for textures - throw them into the asset system. Store just the UUID of the asset, and let the client download the mesh design from the asset cache, rather than have it sent all-at-once as the prim. (This would be particularly efficient if there were lots of copies of the same model in one area - a likely scenario which also benefits from display lists)

Nobody has mentioned the way prims work with the physics engine. I'm not too clear on the benefits vs disadvantages of prims vs meshes for this, but I would have thought that using prims gives reasonable bounding box type information for breaking up the collision detection problem, and does so automatically, without the builder needing to know anything about it.

Perhaps meshes could be dealt with similarly, I don't know the details, maybe someone else can enlighten me.

Considering the current physics usage it shouldn't be worse than say a Half Life 2 server. Physical mesh objects will probably be triangle limited just like prims.

Generally though the physics system is extremely naff even with prims. I don't think it could really get any worse!

To the best of my understanding, prims and physics are strange bedfellows. The physics system cries bloody murder with complex shapes, just as it does when there's major interpenetration problems. There's also the issue of linked sets of ~31 prims in this sense, as that's 31 items to calculate for.


Counterpoint, meshes commonly use something called a "collision mesh" to simplify this data. While slightly more irritating to build two meshes for one (physical) object, this allows for a higher degree of granularity and simplification of otherwise complex collisions.

In theory, anyway.

And, ironicly, we've been asking lindens for a long time to let us specify collision-linksets of 31 prims, that are linked to another set of prims that are phantom, for a long time.

Kinda like what you can do now with attachments, but without the suckitude of that method of doing it.

Yep. Back when Primmies still worked, I had the little guys follow around single-prim "collision" boxes for exactly this reason. It was the only way to keep a sim from going boom on the data processing.

Not the best solution, but it did work... until they broke the command I was using.

Sure, people are creative with prims. People won't be more creative with meshes, I agree.

Talented people can make great things regardless of tool.

My point:
I can make a great house in an hour with 3rd party solutions that make 3ds export meshes. I could make it with prims as well, thing is, the same house would probably take me at least a day, maybe even a week.

Conclusion: My creativity might not be hindered much from prims, byt my productivity is - severely.

Cheers
Alex

What if they allowed importing of 3d meshes, but charged per poly or vert.
The import could do a poly/vertex count and give you a price before you pay.
There could be a max limit on the polys or verts (as others have mentioned).
Polys would almost act like cash if there was groce national poly (limit).
You'd have to give each other polys to trade either like cash (or like gold in Fort Knox used to stabilize the dollar).
You could rebuild with polys you already own, buy them or trade them. Making it a limited resource.

I don't know how the system works right now. It may take a significant rewrite so might not be feasible.
Not sure about this but I'll bet that they are sticking with primitives and character attributes because they find that they only have to store that information once on people's home machines.

The software then just has to "instance" that information buy telling the software the position and orientation of a primitive and uses blendshapes on the attributes of the instanced characters. Computers are very fast at rendering primitives because the math is very predictable and done extremely efficiently (with Nurbs), <not sure if that's what there using>

Does anyone know whether the data is actually "streaming" online. I doubt it. I think the latest build information is uploaded when you log in. The only thing that probably streams is the data from your computer into your ram in chunks as you approach them, hence the refreshing geometry/textures.
/End of Thought.. might have hurt myself
-Bastage Beeks

I'm not sure that's necessarily the case. The same limits on prims could be applied to meshes, so that more complex meshes would use up more of your object quota, and meshes could be used in places where people currently use textures which would actually allow for a reduction in bandwidth usage.

For example, you could have an object defined by a bounding box and the relative coordinates of the nodes in the object's mesh within the bounding box, with (say) 5 bits of resolution per point. Instead of a prim quota, you'd get a node quota (with each node costing 1/8th of a point, so a cube would still cost you one point).

The question is whether quota-limited meshes would actually allow for a more complex world. Where you currently have a single twisted truncated torus (1 prim) you'd probably need 60 or more points (or 8 prims worth) of mesh to get the same result.

[edit: What about this: mesh objects with 4, 6, 8, 12, or 20 vertices (corresponding with the platonic solids), and 5 bits each of XYZ offset from the default position (corresponding to -1/2..1/2 * the 'object size') for each vertex plus 1 bit for each vertex indicating that it's 'smoothed'. A sphere would be 20 vertices all at <0,0,0> and smoothed. A cube would be 4 vertices at <0,0,0> and none smoothed. The largest object would be a 20m cube (all corners at maximum offset). These would be something between 'prims' and a 'mesh'.]