2 things that would inprove the game 150%

1. Less lag when you walk, hopefully Havok will come out with with something to fix this. Also better servers could fix this

2. Allow importing from external 3D programs. Also allow 3D modelling of your own character, id rather do that than mess with the in-game app.

You won't be able to import anything from 3d apps any time soon. 3d apps have a ton more information in their meshes, vertexes, etc. than their SL counterparts. The entire reason SL can exist is because it can compress the simple data and shove it down your pipe at broadband speeds. Imagine trying to compress a 400,000-polygon dragon and pushing it to your client instantly.

LF

You mean that you don't enjoy taking 10 seconds to reach a nearby spot flying and then 20 seconds compensating for the repeated overshoots? That's why walking to a place is often faster of course ...

It's not lag btw: the client-to-server latency is vastly less than the visible reaction time on even the puniest broadband. It's just a poor non-adjustable implementation of avatar acceleration and deceleration. It should be configurable in Prefs.

This comes up once every couple of months. Someone from LL should post a thread in here about the parametric modeller, and why it is not feasible to import .dxf files and so forth, and sticky the thread.

It's totally feasible.

All they need to do is to validate the incoming mesh at upload time for any traversal properties that they can't cope with, apply whatever resource limits they want to maintain and reject anything that would go beyond them, compile up the mesh-defined primitive to determine attributes like CoG and bounding boxes, and finally dump out the structural data and the code for generating the display lists at run time into whatever type of loadfile they use. It can even be parametrized just like the built-in prims are for simple transformations --- certainly for scaling and basic deformations.

None of this is impossible, but it probably isn't what LL want to do at the present time because their engines can't really cope very well even with the current simple prims and limited avatar density. They'll have to allow complex imported meshes eventually though, otherwise they'll lose out to other outfits who do allow it ... it won't be long before serious competition arrives. They'd better sort out their server and client-side engines before then.

Morgaine, sounds like you maybe wanna volunteer to code that transform?

I think what people are trying to say can be simply summed up as such:

SL modeler does not equal CAD/3D modeler,

and

Hardware/bandwidth limitations are the biggest problem to expanding SL's capabilities.

There's been thread after thread about people wanting offline modeling tools, ability to import mesh/poly/spline based models, etc. IMHO, it's just a matter of time before it all gets implemented. SL staff have a lot of other issues/bugs to tackle before they tackle such an advanced item. The software develop soon enough to enable us to do such things, so I'm not worried about that any time soon. I'm sticking with SL for the long haul!

Arti

I just keep copying and pasting my same reply over and over, hehe...

This comes up a lot. This is a feature you will probably never see in SL. The reason is due to the streaming nature of the SL world. Arbitrary 3d meshes are data instensive. They contain information for the location of every vertex, the interconnections of vertices by edges, triangle, and surface normals for each triangle. To introduce an object like that into SL and sill have it where everyone can see what you're doing with it in real time would require SL to send the entire object description to each and every client that comes within draw distance of it.

SL works by using parametric primitive objects. Your client already knows how to make them in terms of vertices, edges, and polygons. All the SL server needs to communicate to your client is that there's a primitive of X type, with dimensions of XYZ, rotation of XYZ, and numbers for cuts, twists, and other special features. It's a tiny amount of data which is why SL can get away with streaming the entire world to you instead of making you store it locally. For this reason you will likely never see support for mesh objects imported from 3d modeling programs.

This is from an article that Philip Linden wrote... ""The average bandwidth to a Second Life player hovers around 100Kbps, although players with larger pipes can allow spikes to several times that if their connection allows it. Even with broadband, a huge amount of compression is needed. Each simulator in Second Life can handle around 10,000 objects, and although you can't see all those objects at any time, you can often see a good percentage of them. Existing compression techniques for transmitting generalized meshes could never get that many objects into view at a speed adequate for making the experience feel fluid, so the decision was made to throw out meshes for most of the objects in world and to switch to a constructive solid geometry approach built around geometric primitives. These basic shapes are represented algorithmically and allow a tremendous degree of flexibility via scales, cuts, twists and through combinations of multiple primitives that can be transmitted in an extremely terse form."

Yeah... what Chip said... !!!


Buy my point still stands... Never say never... it's limited by hardware.

When fat Optical Cable connections (say, like OC 768, see link below) make it out to residential areas and are common across the world (wishful thinking, I know),
See here: http://searchnetworking.techtarget.com/sDefinition/0,,sid7_gci294572,00.html


When grid computing can be scaled to hundreds and hundreds of times the size it is currently,
See http://www.gridcomputing.com/ for some resources

When graphics cards and CPU's are finally able to handle GAZILLIONS of rendering commands at awesome frame rates (perhaps Quantum computing? see link below),
See here: http://www.qubit.org/library/introductions.html

When the software advances to be able to take advantage of these technologies (this will be the hardest part to get right IMHO, but it WILL happen),

THEN.... METAVERSE as it's truly meant to be seen!

AAAH can you just imagine... infinite draw distance?? Analog (ie Human Eye) level resolution??? :: drool ::

We've only just begun... chin up and watch the revolution happen before our eyes!

Arti

Chip, your facts are accurate, but your assessment of what limits they impose on importing of arbitrary meshes are not accurate.

I don't want to repeat what I wrote just a couple of items up, but any mesh can be turned into a prim and parametrized. Yes, the structural unparametrized deta will have to be downloaded to each client that needs it, but the current implementation is far from efficient in doing that, eg. it does not perform much speculative preloading during link idle time at all. And, once it's on your box, there need be no loading ever again, except for the very small parametrization data or when the mesh is altered directly instead of through parametrization.

The SL client has millions of miles to go before anyone can say that it has sucked dry all the opportunities for optimization. Don't be swayed by excuses about streamed content. The rate of change of complex constructed items is quite small in the current SL, and this would be no different given arbitrary meshes, or maybe even slower because it would be restricted to those people who employ external 3D tools. Everyone else would just parametrize previously created meshes, just as with current geometric prims.

LOL, I'm in the land of the perpetual umbrella on the other side of the pond.

But there's no shortage of good software people in SF --- LL should do more hiring and give their developers a bit more freedom.

Or, as many others have stated, harness the power of the Open Source community. That's not so hard to arrange, and it wouldn't require everything to be opened either.

I still couldn't work, Morgaine. It would break the real time interaction. If you're standing within draw distance of someone who brings an arbitrary mesh out of their inventory, you won't see it until it's been downloaded to your client. It's a lot of data compared to a native parametric object. These arbitrary objects would need to be cached, like textures and everything else, so, unless it was your mesh, more often than not it wouldn't be in your cache already. It would have to download every time. Because of that, severe limits on model complexity would need to be enforced which wouldn't make it worth allowing them. The limited amount of complexity it would add wouldn't be worth the bandwidth hit.

Chip, your facts are correct again but they don't lead to those conclusions! I'll try and provide more detail.

But that's no different to the situation right now, with geometric prims. If someone rez's a huge house full of linked prims now right in your face, or when you teleport, the objects take a long time to appear, despite the fact that the trivial models for current prims don't need loading since they're built in. The limiting factor is certainly not the time to send down the prim parameters, that's negligible. It's all the other details, notably textures.

You always have to compare like with like. How much longer would it take to instantiate an 8-vertex arbitrary mesh prim compared to an 8-vertex cube prim? Not much longer at all, because the relative positional data of the mesh is actually quite minimal, and in fact it's even less than the parametrization data for a cube prim, because of all the fancy transformational parameters that a cube can take and a mesh can't.

Furthermore, remember that the mesh itself provides the desired structure directly (except for scale), whereas the geometric prims need all those distortional parameters to make them interesting. This suggests that in many cases, the arbitrary mesh will take LESS time to instantiate than an equivalent construction made up of geometric prims with their ton of parameters.

And finally, remember that even a small item is often made up of multiple geometric prims just because that's the only way of creating the desired shape, currently. Well, that wouldn't be necessary anymore, so you would need FEWER vertices than if the object were constructed from current prims, because a large proportion of the vertices of current prims are not needed, their presence is an consequence of building from Lego blocks. Add that saving to the saving from needing very little parametrization data, and the mesh-based prim might well be a lot FASTER instead of slower.

Why not? In a decent implementation of lookahead caching, exactly the opposite would be true: it would almost always be in your cache, if you visit the place occasionally to refresh the cache entry. Indeed, it may already be in your cache despite never having visited it at all, simply through speculative lookahead cache fills during idle time. And complex objects don't change much at all, whether they be intricate jewelry or intricate palaces.

There is absolutely no reason whatsoever why our caches should be limited to 1Gbyte like at present. With 80G drives costing $30, it's a silly limit, and the streaming paradigm of SL is ideally matched to huge caches because so much of SL doesn't change for months on end. Having said that, the reason we have poor load times at present isn't because of cache size, but because the cache isn't working at all a lot of the time. The dumb client seems to flush cache entries after you've backed off from an object just a few yards.

There is an awful lot wrong with the current implementation,of object loading, and that's the main cause of our current loading blues. Arbitrary mesh-defined prims could well reduce download times instead of increasing them, as long as you compare like with like. And it would be trivial to place a limit on mesh complexity and on mesh topology using restrictions imposed at time of importing, in the same way as when scripts are compiled currently.

It would take substantially longer to instantiate an arbitrary mesh. To describe an arbitrary mesh requires the server to communicate to the client the xyz coords of every vertex, the trangulation between vertexs, the surface normal of each triangle, the UVW coordinates of each vertex, and the texture key for each polygon. I did a little test. An 8 vertex 3ds object is 667 bytes. A 98 vertex 3ds object is 6.7kb. A 1002 vertex 3ds object is 54.1kb. There are more efficient formats but that's what I had handy to test with. Granted, this isn't a lot of data, but it's a lot more than what's needed to transmit a parametric prim, which I can only guess at, but it's probably less than 100 bytes. If this were allowed there could possibly be hundreds or even thousands of arbitrary mesh objects within your draw distance at any given moment. And it's not like they would be static. People would be putting them into inventory and taking them out constantly. You couldn't precache them any more than you could precache all the animations or textures in the world.



You're forgetting UVW coordinates for each vertex, surface normals for each triangle, and a texture key for each triangle.



I disagree. The SL client never has to tell your client where an individual vertex is. It's derived from position, rotation, and scale. Your client already knows exactly where to put each one relative to the pivot location from just those three parameters. With an arbitrary mesh, the server has to tell your client the xyz coordiates of every single vertex in the mesh.

This doesn't even get into the issues involved with the physics engine on the server side.



For the same reasons that you can't cache all the thousands of unique textures in the world. We don't have terrabye drives in our computers. There would be tens of thousands of unique mesh objects in the world with hundreds or thousands of new ones being uploaded each and every day..



It's not silly at all when you consider that this is a commercial product that has to be able to run on off the shelf computers in order to be marketable. I would gladly invest in an extra drive just for an SL cache but they can't make that a requirement, and if arbitrary meshes were introduced an enormous cache wouldn't be an option. It would be a necessity.

Don't get me wrong. I'd be thrilled if they could do it without completely killing performance. I'm a modeler and animator for a living in real life. I just think it's unrealistic to expect it to happen any time in the near future. Maybe in a few years

There's also another benefit to the way SL is now. We all have the same tools at our disposal so it's a relatively level playing field. Trying to create complexity out of simplicity is part of the challenge, and for me, part of the fun.

I think what Chip is trying to say, and I grasped this not long after my boolean operation suggestion when I first started SL, is that current prims are like 'models'. Think of it as Quake 2 maps. When everyone is using a default map that comes with Quake 2 as a multiplayer map there's no download involved. When someone introduces a new map into the game, you have to downlaod the map before you spawn into the game.

In SL terms, that means every new model encountered would have to be downloaded into cache before it's shown. Where as currently, the server says "okay tell the client to load a box that's cut 50 degrees" the client can do this instantly because it already has the prim built in and doesn't have to wait. The data that the server sends to the client wouldn't have to be very large at all.

Assuming a box has 15 float params, and I assume params such as 'hallow', 'twist begin/end', and material settings are integers. And params such as phantom, physics, etc are booleans. (I don't know if this is how it's set up, but it's just an example) because of this the 'size' of data for that prim type is always constant. Except for the prim's name and description of course, but you'll notice name and descriptions are only retrieved on request (holding the mouse pointer over the prim)

All in all that's less than 100 bytes of data being sent to the client for that prim type BEFORE compression. I don't know what compression methods SL uses, but compression algorithms work much better when you have something constant to work with. Rather than models users create themselves and import into SL which are considered volitile as they're not predetermined by the client and server.

this thread has a lot of big words

Chip, I started rebutting each of your points, and then the post got stuck by the forums going down. I still have the rebuttal saved, mind you. But overnight, it occurred to me that there was no point rebutting at all, because of the following:

That's false. You've been continually arguing against it, even to the extent of raising objections that are self-evidently simple to overcome.

If you truly wanted progress, you'd look at the potential capacity of a low-end broadband link, determine the extraordinarily large amount of full vertex data that it can support in asynchronous streaming mode and the even greater amount with high-level mesh optimizations and low-level compression, and argue strongly in favour of technologies that can employ that huge capacity without sacrificing our modelling flexibility. Instead, you're arguing continually in favour of the status quo and looking for reasons for avoiding improvement.

So, I'm not going to argue, because that would be pointless when one of the two sides doesn't actually want progress.

The only kind of dialogue that interests me is of the form "Oh look, that's hard, how can we overcome it?" Not debates about why things are impossible, because they're not when people have the desire to engage their thinking caps.

I'll revise my view when I see you take apart those simplistic reasons given why these things cannot be done, because they always can, if one actually wants to find solutions. As a technologist through and through, I see absolutely no barriers in this issue, and I'm fully acquainted with all the technical isues.

Mesh-defined prims are easily possible within the constraints of current technology, where there is a will. The only prerequisite is a desire to remove one's mental shackles.

~_~ this topic is annoying. It could be done like the ground mesh. The ground mesh is built off a color raw image. If it was replaced with a 4 channel TGA (or PNG) then you could use 40 bits to store the location of each point. The three color channels could be used to discribe an angle and the trans channel could be used to describe the distance from the previous (or center ~_~). And you would always have the normal size (that is used for all shapes & plants). A single mesh would have 1 texture that would stretch over all of it.

Part of the reason for *not* adding mesh to SL is the difficulty of editing mesh. The format discribed above would lock them into a format that would be difficult to edit in SL. It would be best suited for an external editor. If someone were to build such a thing LL might actualy support it (as storing a mesh in a low rez image is going to be much more reasonable for them to handle).

The upload price for a mesh should be proportianal to the area of the mesh with a lower limit of 5$L. Something like area/16 = upload price. (area being the x*y of the TGA) Max area of 4096?

Hah! Well then I guess that settles it since you seem to know what I'm thinking more than I do *cough* I'm telling you it's completely unrealistic given the nature of SL. I could be wrong of course, but Philip and LL aren't dolts.

Let's use a scientific method then, to overcome opinions getting in the way of fact.

LL, provide us with a mesh-defined prim capability limited to just a few dozen vertices and to simple topologies only, and let us see exactly how its performance compares to comparable objects created from geometric prims. It's the only true way of determining this.

Throwing in wild speculation, I wonder what it would be like if Second Life had a "companion editor" that allowed you to create objects offline without having to be pressured at times by other things going on in the world, especially if you're having a hard time concentrating. Not to mention, a streamlined but dedicated interface so you don't have to walk around with your avatar or even sit and pan camera jerkingly in some cases.

Granted, you may have to be able to create in context to visualize the final product, but if you could work offline and then import that in a fell swoop into SL, it might be convenient. Sort of a mini-edit... would be cute if there was one for PDA and you could run it on the bus, sketching and doodling out new primcreations, and then upload 'em!

How do you implement LOD on an arbitrary mesh?
A reasonably detailed mesh is on the same order of magnitude as a texture, with regards to the size of the data. I'm not a graphics guru, but if there is some subdivision algorithm that can determine various LODs for an arbitrary mesh, sort of like going from a square, to an octogon, to a "circle", just by determining the midpoints and adding triangles... it could be just like the multi-stage progressive JPEG downloads we have today for textures.
And no one's complaining about those.

Spreaking of bandwidth limitations...

1GB/second at $38/month??!!!?!!?!?!!

http://www.iht.com/articles/541830.html

/me moves to Japan

Is LOD reduced on the TEXTURE itself or the MESH/poly count? I had always thought that MIPmaps were texture based. Is this true?

Arti

Hey, stop sitting on the fence, Eggy. )) LOD is the spawn of the devil.

Seriously, LOD is a pretty bad idea because it involves human intervention which just doesn't scale, and because static LODs are out of place in a dynamic environment, and because discrete levels are inevitably always going to be suboptimal (and visible) given that distance is a continuum. Furthermore, the usual CLOD approaches that just automate the creation of discrete LOD levels are almost as bad --- they reduce the pain, but the don't do much for improving the quality since the levels are still discrete.

Proper CLOD needs to mean really Continuous, not Cludged. I've had enough of approaching a patch of ground in games and suddenly have it change its appearance slightly but noticeably owing to the switch in level of detail from one discrete level to the next. Not to mention the dreadful bugs that creep in ... you're standing on a rock ledge made from multiple slabs, and as you creep slowly forward, it switches suddenly to reveal that you're standing on empty air with a chasm below you. All this is hard enough for world designers already, they don't need the additional nightmare of having to get manual LOD right.

The sort of micro-scale progressive CLOD approach that you mentioned above is the right one in my view, namely actual continuity at the pixel level, no discrete levels of detail at all, neither static nor dynamically produced. When two points on the model end up being rendered into the same viewport pixel then that's the only "level" at which detail reduction should occur, and in fact even that should not create a discrete 2:1 jump but apply some sort of combining algorithm. Maybe the AA hardware could help.

Typical automated LOD is pretty crummy looking. It works by comparing the angle of offset between adjacent polygons and eliminates vertices accordingly (if the object is x distance from the camera, vertices seperating polygons that are at less than a y angle of offset are eliminated). It almost always looks like crap. New techniques are making that obsolete though. Normal mapping, where a high res object is rendered and it's details are stored and rendered onto a lower rez proxy object, is replacing other LOD methods. It's similar to traditional bump mapping, but it's a 3d effect rather than 2d. This is what the Far Cry and Doom 3 engines do. It looks great and adds tons of realism without adding to the poly count. The low rez proxy objects would still be too high rez for SL though. You can see some examples at http://www.crytek.com/polybump/index.php?sx=polybump. Very cool stuff.

That's progress?

Upheaval of 16+ people's lives from 16 countries is, er, suboptimal, in an age of easy wideband comms.

It sounds like an interesting product though. One can't blame them for trying to earn some money in an age of open-source, but it has resulted in some very restrictive licensing that will lose them customers. There are no easy solutions in that area though.