Kwakkelde Kwak

emSynth wrote: Another key note i that there appears to be a slight error in the numeric conversions that causes somr smooth sculpts to have a slightly choppy or faceted appearance. In fact, if you want a smooth rounded shape such as a car fender or similar object, you might want to consider using a sculpt anyway As sculpts are inherently good at approcimating rounded forms. Mesh is best at faceted or angled forms, especially considering the land impact factor. However, mesh can be smoothed such as by using the smooth button on the leftbhand toolbar of Blender forvexample, but this has the additional effect of negativels affecting texturing andcas such is best for solid or non-detailed textures. So you see, the trade-offs are complex. A car fender or any smooth surface is better done with a sculpt? No offence, but that is the most rediculous thing I've heard in a long time. Smoothness is (next to the fixed UV map) the biggest limitation of using sculpts. The "0-255 grid snap" won't let you make any slight curves on a big object without using very few vertices (which will result in smooth lighting but choppy geometry) I've tried it myself and I've seen many car fenders inworld. Not a single one made out of sculpts was very smooth. The mesh equivalent of a sculpt will be just as bad, since if you turn a sculpt into a mesh, the vertices will still sit on the sculpt grid. Modifiers like "relax" in 3ds max might help out a bit here, but it would simply be easier to make the object as mesh in the first place. There is no reason why a mesh wouldn't be smooth, other than the inability of the creator. A smooth version of a faceted mesh object will have a lower landimpact, since all vertices are shared by several triangles. On a smooth object the vert/tri ratio is about 1:2, on a facted one it is 3:1. This results in much much more data with a resulting much much higher landimpact. Changing an object from faceted to smooth has no effects at all on the UV map, all it does is changing the normals.

Baloo Uriza wrote: Keep in mind that framerate is simcapped at 45 (so it's kind of pointless to shoot for anything higher), and the human eye perceives 20 frames as fluid. It seems like you're making a mountain out of a molehill. The simframerate and screenframerate are not connected in any way. The simframerate simply means the rate at which the server updates its current state, for example avatar and object location. This is not the same as the rate at which information is received by the viewer, let alone the rate at which things happen on your screen. Everything that happens locally, such as playing animations, texture animation, camera movement and some script functions (for example llTargetOmega) is not affected by this 45 fps cap. 20-30 fps is about as smooth as any human eye will notice, under certain circumstances like watching motion pictures. On a "normal" film, we don't get a picture one moment then the next 1/25th second later, the frame holds information from one moment to 1/25th seconds later. The resulting blur makes a 25 fps film look smooth. On a screen where everything is very crisp, a human eye will be able to see a difference up to 60 fps, possibly even higher. Just rotate your avatar in SL when you get 30 fps and 60 fps to see the difference. We don't have 100/120 Hz screens just for the fun of it. With NVidia cards you can cap your screen fps at (half) your screen refreshrate, usually (30 or) 60.

Creed Aldrin wrote: Installed MSI Afterburner and decided to try if i maybe running out of GPU RAM. Turned on lossy texture compression and will look into it further. But right now things seem to improve. I doubt you are running out of VRAM, although it's possible. Texture memory is limited to 512 for SL, I don't see the total use while playing SL over 750 really, a lot less than the 1024 your card has. I walked around a bit, seems it creeps up to amounts over 900 here, that indeed is dangerously close to your 1024. You could try to limit the memory use for SL in preferences. Anyway, you can check as you play. In the develop menu, choose "show info" then "show render info". On the bottom you will see your available video memory. If you are already experiencing low framerates, it might cripple the rate completely though.

Creed Aldrin wrote: Question is: can i find more powerful hardware, or my software needs tuning, or nowadays SL sims and avatars are really overloaded with features and current hardware is simply too slow to handle it? A better graphics card might help. Not more but faster memory might help. What you cannot change is what you already suggest. SL sims and avs are overloaded, not just nowadays, they have always been that. Yesterday I was in a sim not even that full or crowded and there were 700 individual textures and about 2.5 million polygons to be rendered. That sounds more like a scene you render for a movie or for stills than one that has to be rendered 30-60 times a second. (The 10,000 scripts running in the sim didn't help either) The framerate was very acceptable, even with shadows on, I think in the region of 40-50 fps. (CPU 3770K@3.5, GTX670, 16GB@1600, SSD) My resolution is a lot lot lower than yours, my monitor won't go over 1680x1050, that makes a big difference of course. If it is possibe, you could borrow a faster video card and see if it makes a difference. (The fact yours isn't at full load doesn't mean a better one can't be faster) Installing those is fairly simple. You do have to accept "poor performance from SL" though. No hardware (at either our end or LL's end) is going to make up for objects that take as many resources as an entire sim should.

Chic Aeon wrote: So some of the items on the marketplace are sort of missleading. There is no advantage -- that I can see -- over a prim cube and a real cube. There is one big advantage. A primitive box in SL has 108 triangles (each side is made out of 3x3 squares) on the highest LoD. A mesh box has only 12, or even less if you remove any sides you will never see. So a straight mesh wall without any sides, top or bottom only takes 4 triangles. As your camera moves away from the object, the difference between prim and mesh will get smaller, since even something as simple as an SL prim box has different LoD models. The advantage won't be directly visible, but you can imagine a sim full of mesh boxes will be a lot easier on a graphics card than primitive boxes. This, at least in theory, should result in more fps. @ Ivan As far as I know textures will appear exactly the same on a mesh object as they will on a prim. That is unless you're working with very complicated objects, like sculpts. For mesh you can make your own UV maps, which means you can give some parts of your object a lot of detail (using a big part of the texture) and some parts hardly any (using only a small part of the texture).

SL supports 8 "faces" per mesh. This means your mesh can have 8 different material ID's in 3ds max. All of those can have their own UV map, but you can also make a single UV map for all of them. It really depends on how you want to use them. Normally You'd use 8 UV maps, so you can apply 8 textures, but in some cases you might want to use one texture where some parts are glowing and some parts are shiny or some parts can be made invisible by script, then one UV map for all ID's can work. The local axis of objects being different won't always make a (visible) difference. If the local axis of the object in 3ds max doesn't match the global axis, the object will be rotated in SL. Then in SL you can rotate it back in most cases. The problem occurs mainly if your different LoD models don't have matching axes, since you can't rotate the individual LoD models in SL. You can reset the local axis in 3ds max before export by applying an XForm modifier or using the Reset XForm in the utilities panel. This will also get rid of any local scale or mirroring (which results in negative volume). Alternatively you can make a new primitive, attach the other objects to it, then removing the faces from the new primitive again.

You almost got it, what you did wrong is the way you replaced the bones in the dae file. All the bones that are already there need to stay right where they are. You need to add the missing ones AFTER them, or add ALL bones after them, doubles in the list will be ignored. I think you need to replace the "12" with "26" as well. You also need to do what Min Barzane said.

If the proportions of the picture are 1:4, why would you use a giant texture with a 1:1 ratio? 256x1024 should be fine and would mean little quality loss over a 1024x1024. Memory use would be four times less. If you do want to use as much memory as a 1024x1024 takes, it's better to cut up both texture and wall in two and use 2 512x1024 textures. Same memory use, almost twice the quality. (You could also put the 512x1024 textures on one canvas and only cut up the wall. Then you'd have a single 1024x1024 texture. If that's what you ment, forget what I said.) Of course it also depends on the size of the wall you're going to put it on. Programs like photoshop or gimp should have no trouble making the picture shown rectangular. (warp, scale, skew, perspective etc) Other than that, no arguments. One would need permission to use the texture and the texture would have to be of better quality if it is going to be near the camera of residents.

Using Drongle's experiments as a guide you could estimate how large your object appears on screen at a certain distance. You could also do this by testing inworld with the help of a couple of simple tools. If your object is, let's say, half an inch high, or 50 pixels or something, it's no surprise that using 50 triangles is not needed to represent the shape of the object.

I don't know any way in DAZ or Poser for that matter to mirror the timeline. If you don't have too many frames, you could do it by altering the .bvh file in a text editor. Near the bottom you'll find lines with lots of numbers. Those are all the coordinates per frame per line. With a short animation it shouldn't be too hard to flip them around. Make sure not to change the base frame, the one with the t-pose.

Lera Keng wrote: These are just lists of coordinates/numbers and I have no idea how I am to use these as obj or mtl files! That's because an .obj file is just that, a collection of numbers. Numbers for vertices, numbers for normals numbers for texture coordinates, everything needed to draw the shape. Right click the link, save as "avatar.obj" or something and you'll have what you're looking for. Like Chosen, I really have no clue why you'd need the .mtl files, but I'm pretty sure you can download them the same way.

Dragging a box around all your prims and looking at the numbers in any viewer will likely result in a lower number than your actual use. Dragging a box ignores very small objects, dragging a box ignores everything outside the box, that is objects in the sky etc. Look at the dates of birth of the forum users, plenty are "legacy residents", including me. I'm not saying what you describe is impossible, it is just very very unlikely. You state it as the absolute truth. I can imagine a Linden not responding well to an attitude like that. I haven't done a complete survey of course, but I did have a quick look at the sim and on the 900 something (or was it 1400?..the one with the bazaar) parcel there are around 2000 prims according to the land menu, all of them accounted for. The other parcels are so small I can't see what's what in a reasonable time. All in all the last I would call this build is low prim. Anyway...did you look for odd duplicates on your sim, a couple of server hiccups ago I found myself with no prims left on my land. Some objects were duplicated and I wasn't online and am sure I didn't touch any. I got the odd message about returned prims as well and found nothing in my inventory. By the names of the objects I could identify them and they weren't returned to me, they were still on the sim. Possibly they were duplicated, sent back then ignored. Luckily all duplicates (or at least I think I got them all) were near ground level so they were easy to find. There are tools out there to find prims at any height, you might want to scan your region. The occurrance of a bug? That would be nothing new in SL. Legacy builds taking more room than they should? I still am not convinced, not even close.

No idea if this is what causes the walkthrough walls for you, but if you rezz a mesh object in such a way that you are in it at rezz time, it will be phantom/physicalshapeless. Rezz it in an open space and it will behave as you expect. At least that happened to me and I think I read it happened to others as well.

To find out what kind of motherboard you have, yo can download a program like CPU-Z and find all the information in the mainboard tab. PCIe is backwards compatible, so a PCIe3 graphics card will run on a mainboard that supports PCIe2, of course the card might not reach its full potential then. To find out what kind of PSU you have, the easiest way is to open your box (if you have a desktop) and look at the side of the big box in the upper back where all the cables go. It will say 400W or 500W or something. Beware this is maximum power drawn, so a 600W one doesn't neccecarily provide more power to your PC than a 550W one. Normal is 70-80% efficency, silver rated is 80%+ and gold 90%+ I think. If you have a laptop, chances are you can find the PSU on the manufacturer's or retailer's website or on your invoice.

I don't see a reason why you want to make the physical model inworld. For something like floors and a ceiling you want planes, not boxes. In SL you can't build planes so you'll use more geometry than needed. All you need to do is make sure it all fits and when making a physical model inworld, that's no different.

I haven't seen or experienced a thing you describe. Legacy builds that cost a certain amount of prims in 2005, still cost exactly the same. That is in the edit menu and in the actual LI they have (land options, available prims). Only if you click the "more info" you will see a different number, depending on the build it will be higher or lower. This number is a potential number and will only count if you set one or more of the prims in the linkset to anything but "prim" or when you link it to a mesh object. If you use a V1 based viewer the numbers don't add up, since it will only show the amount of objects in the linkset, but didn't LL stop supporting those? I have never seen any bugs in the V3 viewer regarding this. If there are, they are just bugs, showing you the wrong numbers. The only important number is actual use, visible in available prims. I never made any working vehicles, but I think that's the only place where the new system has a negative impact. An old vehicle with a physics weight over 32 (?), no matter how much the LI is, won't work. There are some more physics glitches on older builds, but I have never seen an object gaining LI all by itself, just because LL changed the calculations.

My best guess is the physics shape is rescaled by the uploader. Before upload you have to make sure the physics model you build is the exact same size as your visible model. All models you upload are scaled to the dimensions of your high LoD model and I can imagine your floors and ceiling have some thickness, where the ones in your physics model do not. So the lowest physical plane will be on the bottom of your lowest floor and the physical ceiling will be on the top of your ceiling. You can add very small triangles to match the size of your visible model. The same is the case for Your medium, low and lowest LoD model btw. Inworld you can check how your physical model looks by clicking render metadata->physical shape (or something similair) in either the advanced or develop menu. If the physical shape does match your visible shape, something else is going on. My experience with physical models set to prim, is that the avatar position will work fine.

solstyse wrote: I know plenty of people who change their video settings frequently, so that they can walk around without feeling like they're getting nowhere, and so that they can up their graphics settings to take pics once they got where they needed to. Exactly, this seems to work pretty well, so I don't see what LL should change. Users can make their own desicion in their performance/quality ratio. If you combine that idea with automatically storing assets at the maximum resolution that the highest end viewer will display, I think you would get your wish of keeping all the LL eye candy intact, while those on slower machines will get theri wish of a faster performing sl. People have this in their own hand already. Everything IS stored at a certain quality. Using clothing as an example, if the top of the line computers will always display it as 512, then it should reside on the asset server as 512. If a "lightweight" viewer can only display it at 256, then instead of ignoring the texture, what is to stop the lightweight viewer from downsizing a second time locally to display that texture at 256? For that matter, if the higher end viewers (which means 99% of them) can interpret the 1024 texture as 512, then why not Lumiya? That must mean that the viewer is handling that locally on the user's machine. Now, if that was done server-side, preferably at the time of saving the object, or item of clothing, I think even the high end computers would see a benefit, without sacrificing any of the looks that you've grown to love. And it seems that a patch like that to how textures are handled wouldn't be too difficult to the people who invented the grid. There's a difference between "clothing" and "textures". The textures that are used as clothing are stored at any supported resolution. Clothing is always 512x512 on the server. The piece of code that resamples the original texture to 512x512 is used once, not before rendering, but before sending the combined clothing texture to the server. This piece of code, or something similair, could be used another time before rendering, but I'm not sure if that's a good idea. Instead of resampling one texture, the viewer would have to resample all textures. Especially on a relatively slow device as a phone or tablet this could take too much time. What I think Lumiya does, is ignoring the highest part(s) of the mipmap. If you look at something in the distance, your viewer will download a downsampled version of the original texture, readily available. (That's at least what I picked up, that some sort of mipmapping is done server side in SL) As you come closer, your viewer will download the higher quality ones. Changing the distance at which a certain size is downloaded to zero, will ignore the higher resolution(s). The result as I mentioned earlier, is objects that really need the high resolution textures (text for example), won't show correctly. The missing 1024x1024 clothing texture in Lumiya has to be a bug. I can think of something like this: All textures that are rendered on screen are "downsampled" to something smaller than 1024x1024, I never used Lumiya, but the screenshots clearly show the "downsampling", to what size I do not know. A 1024x1024 texture for your avatar is handled differently. It never reaches your screen, so it's processed by a different piece of code. The baking process in Lumiya probably can't handle the big texture and ignores it. Doing this baking server side is exactly what LL is planning to do. It should result in a small performance gain for everyone. (And it means the bugged code in Lumiya becomes obsolete)

The compatibility I was talking about was not the potential compatibility between the two ends, being the server and the user. The more that's done at the server's end, the more compatiblity of course, since more hardware is shared between all users. I'm sure the server code can be written to be compatible with iOS, MacOS, Windows, XBox, PS, Linux, Android etc. In fact I think it already is. We already have different viewers for Win, Mac and Linux, (and even a tpv for android) so this shouldn't be an issue. What is more important I think, is the fact the architecture of the hardware is completely different. For example, a PS3 game is optimised for PS3. It makes use of its strong points and tries to avoid the weak points. I don't know all that much about the internals of any computer, but I do know that what works well on one machine does not work well on another. I also know "porting" a program from one platform to the next often results in a second rate experience. The most important thing in relation to all this, is the fact in order to make such a platform reality, the current server code will not work. Not only in a "code" way, but also in practical ways. A simple example. In order to make SL work on a current console, or tablet, or phone, the texture load needs to be lowered since it's simply too high. Lumiya takes care of this by lowering the maximum texture size (and draw distance). Lots of people use a 1024x1024 texture with text. If the texture shown in the viewer is lowered (by ignoring the highest part of the mipmap?) to 512x512 or even 256x256 you can't read the text. This means broken content, something LL tries to avoid as much as possible. LL tries to bring a shared experience to us residents. The only way I see this possible at this point is by either lowering the quality to the lowest thing out there, being the phone, or by doing server side rendering, which means both soft- and hardware upgrading and importantly, would demand a high speed internet connection. I don't think LL has the resources for it and even if they do, I think those can be put to better use in other places, at least for now. This doesn't mean LL shouldn't keep a very sharp eye on the market of course. I don't know anything about phone contracts in other countries, but here you usually get a phone for a two year contract and a certain amount of (minutes and) data you can use every month, for a certain amount of money every month. Going over this limit results in extra costs. I'm sure this is where the phone companies make a good share of their money. Both legislation and customers getting a bit smarter, pretty much has put an end to data use outside the contract limit. Phone companies are in bad weather here, so costs will probably go up. Where the "war" between the producers is going I don't know, but looking at the investments by the Korean state into Samsung, the balooned value of Apple shares and MS trying to catch up, it might be an interesting soap. I don't have any illusions about privacy on the internet or privacy as a whole nowadays. The most personal information about me or any other person around here is stored in databases. I think medical and financial data are more personal than the files I have on my computer. I do what I can to minimise the potential damage I guess.

What that console does, seems to be more or less what I described. Pretty much everything is done at the server's end so all your box has to do is drawing a picture and telling the server what you're up to. This means the hardware on such a thing can be very low spec and very dedicated to one simple task and therefor cheap like you say. It also means the software needs to be adapted to this system, which I mentioned a couple of times now. That can't be a slow steady change I think, as I explained before. It also means LL will have to make a huge investment in new hardware. Again, if LL could pull off such a system, I'd be all for it, as long as my SL experience doesn't suffer from it. I have no desire to run my SL on a 1500 euro computer with the looks and features of Lumiya. It also means there is probably zero compatibility with other systems that don't share the same architecture. Like any console, the programs for it are very dedicated to one particular setup. This allows better performance again with lower specs, but it also means it's pretty much useless for PC's, both low end and high end systems, since not two are the same. So without trying it out (I'm not going to mess with this computer as it is my workstation and frankly, I don't need to be convinced that the performance is good, I'll take your word on that) I can honestly say I remain very skeptical. BTW, the phone market seems to change, over here in the Netherlands the subsidies are dropping at a fast rate. If anything costs money, it's a high end smartphone. A typical subscription here is around 25 euros a month I think, so for two years that is 600 euros. Not exactly peanuts for a lot of people and it probably won't get any cheaper. A smartphone just does other things than your average PC, a smartphone is also something people use in public, people want to show off their new gadget, a four year old gadget doesn't really exist. Phone technology is improving at a pretty fast rate (question is how long this will continue, that will depend on potential new functions) and therefor a phone depreciates quickly in desirability and functionality. I don't think cost is the leading factor here. Oh and $1/GB? That's for SSD, not a 3TB disc. One of those would cost $3000 then, a bit steep A 3TB disc costs more in the region of 5 cents/GB. In the SSD market there's plenty of room for improvement. I'd love to have a 3TB SSD instead of a combo, but I'm not spending the $3000 I mentioned on it. Call me old fashioned, but I rather have my personal files on my personal computer, not in a Cloud somewhere. No digital database or system has been proved secure, quite the opposite. I understand any computer can be hacked and any CD can be stolen, but that would only happen by pure chance or by a very directed attempt, not a big sweep and analysis of a complete database.

Everything you say I already covered in previous posts. I said to me it's not a big issue since I'm the only one using this computer. I also said, as far as I know, it only happens on the forum, not the marketplace. I also said that even if it happens only on the forums, there's a potential risk, being your privacy and the risk of getting banned. If it also happens on the marketplace, it automatically happens on your dash, since those two are connected. This would be a serious risk of course and I agree that should be classified as showstopper. BTW I totally agree that the system is far from perfect. If you ask me the web browser based functions should at least be split into forum, marketplace and dashboard. Closing the browser or even the page on one of them should log you out instantly, at least by default. Logging in to one shouldn't log you in to another and finally logging out of one shouldn't log you out of any other.

The fact you're not getting the information or response you'd like in the right place, doesn't mean you can expect it in the wrong place. What can I say?

It could still be a transform issue. I don't know if this well known mesh maker knows what he or she is doing or if they even use 3ds max. If the skeleton was made for Blender, chances are the skeleton is rotated the wrong way, it should face into the positive x direction. It could also be your unit settings, SL likes meters. I don't know how you imported the skeleton into 3ds max. When using the SLAv plugin, you can make mistakes for example.

I'd say either your skeleton has some odd transformations (rotation/scale) or the bonefixer you used didn't add bones, but replaced them in the dae file. In that case the order of the bones could be messed up. What you can do to check this, is comparing the dae you exported from max and the one produced by the script. The bones in the second dae file should be in the same order as the ones in the original file. They should also be the first in the list. Skin weighting is assigning values to a single vertex which determine how much influence different bones have on that vertex. The total weight should be exactly 1.0 for every vertex on your model. There's also a limit on how many bones can influence a vertex, From the top of my head four bones, but I'm not 100% sure.

To me it sounds very possible that even when you as a person do everything to log out of the forums, the system does not actually log you out. Again, you could check this by trying to sign in and see if you need to enter your name and password again. (Go back a page and refresh?) If the forum has trouble logging you in, it's not unlikely it has trouble logging you out. I find that more plausible than the forums randomly logging you in between the moment you log out and want to log in the next day or so or the forum on logon fetching your details from cache instead of asking you for them. Either way, it's something that needs to be fixed of course.