WolfBaginski Bearsfoot

The Prim Equivalence calculation does take into account the object size. If you've hand-made the different LOD meshes, you might be able to cut the Tiny version's PE even more. Instead of using the full 1-2-3-4 set, you might use 2-2-3-4. The smallest Mesh details could be wasted effort. Do you put the detail in the Mesh itself, or concentrate on the UV-mapping to allow better use of the texture? It's one of those design choices, and the optimum might come out differently for a Tiny.

They admit it is as buggy as all hell, dumping a metric **bleep**load of snark on the LL code as they do so. Also, they haven't yet implemented Mesh uploading. So I shall carry on using Kirstens for that. It's usable, has a decent frame rate, and is definitely worth trying out. I infer that if the bugs are in the LL code, we're not going to avoid them by switching Viewer, if we want to see Mesh.

I've been doing a rather crude test, and linked two mesh objects with one ordinary Prim. Total Prim Equivalence is 5, for a basic house. It's as quick and dirty a model as you could come up with, but no weird stuff with the linking of Mesh and ordinary Prims. I'm wondering if something got changed when Mesh left beta status.

I haven't used a Linden Lab viewer for over a year. Until I wanted to try Mesh. Gee, I wonder why that is?

Emerald is officially dead. Things blew up a year ago. A few months later, Linden Labs introduced an official multi-attachment system. I can't recommend a particular viewer, since I've no experience of an Apple Mac, but the little I've heard suggests it's just too old a machine.

There are possible criminal charges here, for unauthorised access to a computer system. California State Law, US Federal Law, and if the perpetrator is in another country, that country's law. And it's not easy to prove. But I'm not entirely sure that this is a Linden Lab server that the pics came from. The image is created by your machine, even if it gets uploaded to the asset servers for storage. How good is your own machine's security?

I've seen reports of that problem, and this is the first time I've seen an attempt at an explanation. I've tried making a simple building from Mesh, and Prim Equivalence can be quite low, but my Viewer crashed when I tried to upload. But think of this. You can use a hollowed box to make a wall with one window, exactly in the middle. Mesh lets you make two windows in the same component, or a window and a doorway. One downside is that a Mesh object has a limited number of materials. There's a limit to how complicated you can make things and keep the texturing simple to do. And remember, you can select several objects and save them as one inventory item. So the not-linking work-around isn't so bad.

That video card is a 4-year-old design, but I don't see anything obviously slow about it. It was top-end when it came out. The current nVidia driver has fixed a few glitches for my system, so if you haven't upgraded recently, it's worth doing. I wouldn't use Viewer 3 myself, it's been so much slower than other Mesh-capable Viewers. I think you should try a different Viewer, if only to eliminate some possible causes. Kirstens S21 is what I use for Mesh. But it does sound as though the Viewer 3 betas are getting somewhere with the speed problem.

I'll agree that there have been previous occasions when new stuff has fallen over after Phoenix has picked up the code. Display Names come to mind as an instance. They ought to know how many people are using the different Viewers, so why do they get taken by surprise?

The HTTP method of sending data has been around for a long time, and should be, with open source and everything, be thoroughly understood, debugged, and reliable. It was introduced in SL for texture delivery, with the claim that it would avoid many of the problems with the methods previously used. These didn't have mechanisms to detect errors or dropped packets, leading to all sorts of texture problems. Yet it now seems that the standard answer to texture problems is to turn off HTTP Texture Fetch. I suppose that part of the reason it might work is that it sets the flag to Clear Cache before the next login And I do remember that there seemed to be some problems in the early days. But it frequently gets blamed for slow texture delivery and low frame rates. The reasons for slow texture delivery might be general net congestion affecting the handshakes needed for each file sent, but I can't see an obvious connection to low frame rate. Is the HTTP being unfairly blamed. because of memories of long-gone problems? Or is there some incompetent programming deep inside the Viewer or Server code? I've also heard a few stories over the years, about the pitfalls of multiple threads and other programming esoterica, and i don't pretend to understand them. But it does occur to me that a choice made before HTTP was introduced could now be sub-optimal. Not incompetent programming in itself, but perhaps a failure to realise the effect of accumulated changes.

Since there is a lot of free furniture out there, I'm not sure this is so dreadful for merchants. If some of these freebies can start showing off things such as Mesh. well, I expect to hear the screaming from here. But, once the Viewers are giving a decent frame rate, a Mesh freebie pack is going to be worth doing. There is a huge amount of free, or very cheap, material out there. Some of quite good quality. Scripted freebies aren't so good, usually. Is this really going to change things?

It's looking as though the Marketplace is getting in a mess. There were problems reported in Status on the 26th, but I have had both sales and purchases failing on the 30th August and 1st September. The non-delivery problems might be something else FUBARed but my inference, from the increased problems, without an apparent increase in SL use, is that the Labs have cut back on the infrastructure, Yesterday, I had one guy try to buy the same item three times, without delivery. Delivery failure, and payment cancelled so the system isn't cheating anyone, but I wouldn't have blamed him for giving up on trying to buy.

Excitement is over-rated as a concept

Ah, useful to know that about the Collada file. It looks as though Wings 3D uses 1 unit = 1 centimetre Looking at my model, that looks right for the figure the Viewer told me.

I've been fiddling with mesh, and I'm getting somewhere with the basic problem of making the mesh, making the lower detail versions, and handling the UV Mapping. But I'm finding that the mesh I make appears in SL at a smaller size than I expect. There are various programs out there, possibly with systems to give "real" dimensions, as well as whatever internal coordinate system they use. What I'd like to get a handle on is how big 1 unit in my editing software is when it appears in SL. As an example of the problems I've come across outside SL, the program Poser has had a few scale variations, but 1 unit in the data format used (essentially Wavefront .obj files) has scaled out as close to 100 inches, If you want to make something for a Poser figure to handle, that comes out about right. But many other CGI models, when you import them into Poser have a scale of 1 unit to 1 inch, or 1 unit to 1 centimetre. It looks as though the Collada import does give a figure, so nobody needs to pay a fee to find out this figure for their software. But is there a list anywhere?

I've used DAZ stuff for years, and they have one of the less restrictive licences in the business. But it still pretty clearly blocks use in SL. Thing is, they want people to make and sell certain kinds of derivative work. Pictures and animations, obviously, that's what they're selling their products for. But there are add-ons which depend on the mesh-structure, and the rigging data, which they want people to make and sell. We have the same basic tech with Mesh here, attachments using the AV rigging, usable as clothes. Of ncourse you want people to have that stuff. And DAZ don't mind if you use their models in another CGI program to produce images and animated video. But there are limits. I'm not sure it would be wise to load a DAZ model into SL, even for personal use. It's a legal grey area Pass that mesh onto anyone else, and it's a definite breach. The way SL works, that mesh model is getting passed on to multiple computers, to render images from different view angles. It's not just you who is rendering a picture. Last I heard, DAZ 3D still have a small presence in SL, so they are aware of this place And then, at the technical level, so much of this stuff is at insanely high polygon levels for use in SL. Turbo Squid does distribute material usable for games. DAZ 3D doesn't.

But whatever your system, weekends are always worse. And recent versions of the Linden Lab Viewer are also bad.

That's intriguing, but it's consistent with what I'm seeing. Texture loading is being awkward in all the viewers at the moment, but the LL Viewer does seem to be somehow worse. This sounds typical of something doing a lot of work, over and above the network protocol itself, when a texture is downloaded, and not playing nicely with resources also needed for the rendering. There's all sorts of stuff which could be happening with allocation of CPU time, and then there's the communication which the graphics card. Looking at the stats panel, there's a definite correlation between high bandwidth use and low frame rate. I wonder why.

People were telling me, a few months back, that Viewer 2 was faster than Viewer 1, which seems a sick joke now. The last few versions of Viewer 2, and now Viewer 3, have been horribly slow. The speed I achieved with that experimental Cool VL Viewer does make me think those old opinions are plausible, so what have the Lindens been doing to FUBAR their Viewer? It looks as though something they've done in the last few versions has broken the product. Since Henri has based things on v2.6 + Mesh, it doesn't look as though Mesh itself is the cause. It is somewhat unfortunate that the Mesh-capable Viewer is going to be associated with this poor performance.

Let's just compare Sculpts to Meshes I loaded the blank sculpt and got 1920 polygons all triangles. I can adequately model the item with 288 polygons. But that's too low a level of detail to end up with a decent minimum, and that isn't triangles. 576 triangles, then. I made a minimum detail model with 32 triangles. From a distance, it's still got the same basic shape. I can double up on the maximum detail level, and still do better than the sculpt. The Sculpt handles LOD by cutting out vertices automatically. If you use the wrong row of vertices for the edge of a hat-brim, it can all vanish. You have the be close to see the highest detail level, but I was able to keep detail without worrying about putting the edges and corners on the right row of polygons. It is all a lot easier, as well, because all I can do with a Sculpt is move the vertices. It's not just for LOD, I can add and delete vertices as I wish. The big gain comes with the UV mapping process. There's a bit of jargon here, but a UV map is what often gets called a "template" in SL. It's the flatted-out version of the head and body of an avatar, which guides you when you create clothes. It's the way a spherical earth is warped to fit a flat page (and those distortions have a reason all of their own). And "materials" are sets of polygons which are given the same texture and colour, much like the faces of a Prim. Let's continue the example of a hat. It is, very nearly, a cylinder sitting on a flat disk, the crown and the brim. That's three or maybe four, materials visible. The Brim might have a top and bottom, but they could easily use the same part of the texture, without any problems. Like the top of the crown, they're close enough to flat, when viewed from above. The side of a crown, you can treat as a cylinder, and unwrap it. With a little care, you could use a singled chequer-board pattern, and all the squares would be the same size, undistorted. That's very different from a Sculpt version, where you might start with a surface such as a sphere, and the top and bottom edges of the texture map onto the points at the poles. But Meshes aren't for everything. I kept my sample down to 1 PE, but I've heard a few things about what happens with multi-prim objects that include Meshes. A sculpt might be a better choice. What are meshes going to be like for sim-crossing, as a vehicle? But I can see the old trick of a simple vehicle, with the bodywork model worn by the driver, being used with meshes. Will that be better? And vehicles will still fail if there's too much scripting. The bad stuff will be bad stuff, whether it uses Mesh or not.

Agreed. It wasn't so horrible a job to make the reduced detail meshes for what I tried yesterday, and the results were far better than the automatic. The PE cost for the end result was lower, with more detail than a Sculpt and fewer texturing problems. I still need to work on things, but this is looking good. But the good products will still be good products, even if they don't use Mesh

I've tried two Mesh-capable viewers. Kirstens is rendering 30% faster than Viewer 3. It seems possible that the problem you're seeing is down to a crap Viewer release. I'm hoping the Viewer problem can be quickly fixed. I've made and uploaded Mesh, and it is potentially very useful. I may be selling something, fairly soon, when I get the workflow sorted out. But I doubt I shall sell anything while Viewer 3 is so bad, even without Mesh present.

The current Mesh-supporting Linden Lab viewer still needs significant work. Something is hitting the frame rate badly, and I've already checked the default graphics settings. Something is making texture downloads slow. There's more to Mesh than the server code, and I reckon some other people are letting you down.

Problems with the Cache and the Inventory servers are likely. Since those ingenious people on the Dev Team made sure that the Firestorm cache and settings didn't use the same folders so you'll need to clear more than one cache. The new Phoenix version is worth using. It has quite a few bugfixes, implements Parcel Privacy, and handles Prims up to 64m automatically. Phoenix is not going to suddenly drop dead, but some aspects, such as search, depend on LL servers that are eventually going to get switched off. The Phoenix website has a clear explanation of all this.

One might infer that Mesh, now it is on the main server channel, is available from all servers, but the Blue Steel page doesn't make it explicit that it will be in the new roll-out. This seems a little careless. The Dashboard message for Viewer Downloads could have been better, too.