Kwakkelde Kwak

Drongle McMahon wrote: Each vertex adds 16 bytes, while each triangle adds 6. Oh I didn't know triangles counted aswell, makes sense..and good to know.

Indigo Mertel wrote: Could the odd shading be caused by vertices not being perfectly aligned? Yes and no, it depends on the faces. You see the effect on faces around a single window aswell, those were all on the same side of a prim, so obviously perfectly aligned. If different prims were not aligned properly, it could give the effect aswell, but not per mesh face, only per prim face (which is at least two mesh faces for a box). Another option is the importer not importing the vertice locations perfectly. Just scale all the vertices that should be aligned to 0% along one axis. Again, I can't tell you which buttons to click unfortunately.

This would be a better topology, if you want the least amount of faces AND connected vertices (no overlapping edges). Both walls are exactly the same btw, one is triangulated though. There are two issues with overlapping edges like you use them. First is the lighting, you already mentioned it yourself. If the size of the different faces gets big, you will see odd lighting effects in SL. The other issue is the vertices on the overlapping edges will all count. So while the number of faces goes down, the number of vertices could go up. In your left picture there are 7 squares for the wall without windows, so 7 x 4 = 28 vertices. In your right picture there are 25 vertices. In the picture shown above, there are 20 vertices for the wall. The less vertices, the lower the landimpact and upload costs. Usually I am all for the least amount of faces possible, but in this case I'd prefer the least vertices. Not for the landimpact/upload costs, but because it will look better in SL. If I had to choose between your two models, I'd use the one on the right. if you want four different textures for the four quadrants of the wall, that one is even preferred over the one I made. EDIT... The strange lighting you see in Blender might either be a Blender issue or it could be unwelded vertices/different smoothing groups. Someone who uses Blender could certainly tell you how to fix it if the latter is the case. (for the version on the right that is, not the left, that would be unfixable then)

Very nice, now that you mentioned "shaders" I was able to find realtime shaders for 3ds max, seems they've been around for a couple of years. That might come in handy when the new materials are introduced. For the normal high poly scenes I build, I suspect those shaders will kill even my brand new computer. Either way, good to know it can be done, if I understand correctly, nothing is standing in the way of adding these features in the new SL material system then? What I don't understand about your example video, is you mentioning baked lights. Does this mean the textures sent to your graphics card are not the 256x512 ones, but a whole load of unique textures baked using those small textures? That is maybe low in memory as far as bandwidth goes, but sounds like it would result in a far higher memory usage for a graphics card. If this baking is done viewer side that shouldn't be a real issue I assume. People with a slower computer can then turn it off like they now can with shadows and other fancy features.

Could it be something as simple as some people being taller than others? The physics are 100% server side, it shouldn't matter one bit which viewer people are using.

The meshes are the reason in a way, but they aren't in a way.... They are the reason, because when you link a sculpted or "normal" prim to them, the landimpact, or primcost if you will, will be calculated as if they were meshes aswell. I suspect the physics weight of the cylinders is the reason for the increase. Edit your item and set the physics for the cylinders from "convex hull" to "none". The meshes aren't the reason, because the weights for meshes are already calculated like Rolig discribed. It's possible to turn 2 meshes worth one prim each into a combined landimpact of 3, but just as likely into 1. That's because the three different weights are added up and then the highest will determine the overall weight. Two identical meshes worth 0.6 will be 1.2 which is rounded to 1. Two identical meshes worth 1.4 will be 2.8 which is rounded to 3.

I'm well aware of the possibilities with scripts, but that doesn't mean a script is easier to use than the UI, even if they make the UI ten times more complicated. I would like to see control by script aswell. Particles controlled by UI would be a blessing to a lot of people. Not everybody likes the coloured text input which, although I more or less know how to use it, is nowhere as intuitive or fast as buttons one can click. Same for animated textures. People are more likely to experiment with a menu than with scripting which might frighten them. Like stated in the other answer to your post, you must be out of your mind saying the UI is complex when you're comparing it to scripting, imperfect as the building menu may be.

Recently there was a thread about the same issue. Did you by any chance install SkyDrive?

Qie Niangao wrote: (Futile though it may be to mention: it's not necessary to further clutter-up the viewer's build tool with any UI for this. I don't actually expect that viewer devs (LL and TPV) will be able to stop themselves from hanging yet more floating complexity off what are already UI abominations, but it's an option to instead simply let scripts define how users manipulate these.) I couldn't disagree more (and I doubt LL will not use the UI for this). Writing a script, finding the face number, finding out I made a typo, having to resave the script over and over and over when trying to find a nice repeat, my god, that's the last thing I need when I simply want to apply a texture. I don't see where you find all this UI clutter when building? Pretty much everything you need is in a couple of tabs in one single menu.

Drongle McMahon wrote: Not sure what you are saying about 3Ds. In Blender, it is very easy to combine diffuse and/or specular and/or normal maps at different repeats etc, even to use different mappings/projections. It's also easy to use different modes of superimposition (mix, multiply, add, overlay, difference etc...). You have to bake them into one texture to see them in real time in the 3d editing window though. Maybe that's what you mean? So you could say it's that sort of baking that I would like to see in the viewer. Probably too resource hungry*? That is exactly what I ment yes. Ofcourse 3ds can have various UVs, but it won't show them realtime, in the viewport.

Drongle McMahon wrote: At the mesh UG, Geenz indicated that the initial implementation would have the specular and normal maps tied to the same size and parameters as the texture. I'm by no means an expert of what goes on inside a server or graphics card or anything, but I have the vague idea a texture has to be baked onto a surface before it can be rendered onto your screen. This would mean when you add a layer of occlusion to a diffuse map (with a different UV), all the textured surfaces either become unique or turn into one huge surface instantly. Even 3ds max won't allow you to show two "effects" (diffuse, ambient, normal, bump, specular etc) at the same time in your viewport. Maybe someone with some more technical knowledge could shed their light on this? Afterall it is possible to have shadows and occlusion through the renderer realtime.

That is not how it works. As I said, the physics cost can't be over 32. The LI makes no difference, as long as it isn't determined by the physics cost. Try linking 256 boxes and set them to convex hull. You will have no problem making the linkset physical. Change 5 of those linked boxes into tori and you will get the error message "Can't enable physics for linkset with physics resource cost greater than 32".

I'm pretty sure only the number of triangles on screen have an impact, so yes. The thing with avatar attachments however is they are usually on screen and pretty up close, no matter how you turn.

Nalates Urriah wrote: So, one can only go so far with that upgrade before one is into serious upgrade. Very true, but if you can keep the cpu, a motherboard is nowhere near as expensive as a high end graphics card. So all the "seriousness" is in having to rip your computer apart, not in costs.

You can set a 255 linkset to physical on the main SL grid aswell, as long as you make sure the physics weight is not over 32. Did you test it with a vehicle with a higher physics weight than 32? And did you simulate a "critical" sim, such as a racetrack, with let's say 10 of those vehicles around and colliding with the ground, walls and eachother? I'm pretty sure the hardware used today could handle more than the 32, that number hasn't been raised in years. If I recall correctly, it used to be 28 or 29, but I could be wrong. Anyway, part of being creative is pushing the limits. 32 should be plenty for any vehicle, whether it's a bicycle, car, boat or airplane.

Luc Starsider wrote: I'm quickly running out of things to check... Other completely different things to look at: Avatar attachments, I've seen outfits with hundreds of sculpts or with meshes so dense they looked solid. Amount of (available) physical memory? If you run out of RAM your hard disk will take over, that grinds things to a halt quite nicely.

Try not to get too dizzy..and yw

Yes that's the default, but you could have accidentally set it to local, in that case the rotation will always be 0.

Did you by any chance set the rotations to local? You could try to reset xforms in the utilities menu, the hammer on the right, that's how I always do it.

When the picture is fullbright, there can be no lighting effects, so specular and normal maps won't show anything then. EDIT Looks like it will or at least might. Bumpiness works on fullbright objects, so does shininess. I guess I spoke too soon.

Exactly how did you reset the rotation? If you right click the rotate icon, does it give you all zeros?

groovyloopylou Aya wrote: mine uploaded with 10 however the polys assigned to the 'extra 2' didnt show in the model Yes that's what I ment, the first 8 will upload, anything over 8 won't

real short answer: Yes, 8. Anything over 8 won't be uploaded at all.

What do you mean by "lag"? You said it was low fps, but exactly how low are you talking about? If you are comparing the fps and texture rezzing to some 3d game you are used to, the answer is very simple: That's just the way SL is. For the better part built by people who don't know how to minimise resources, or simply don't give a hoot. A 3d game is built to run fast, by people who know exactly what they are doing, most things in SL are built by amateurs who go for good looks no matter how much the load will be on the system. This means far more geometry and far more unique textures. On top of that, everything has to be sent from the servers to your viewer. If you are getting really low fps, like 10 or 20 under normal circumstances, something more is going on though.

Holy macaroni, how could we have overlooked that ?!