Dana Hickman

Omg that's too cool, I love this photo! My perv side says there's a joke in there somewhere about handling heat-seeking missiles, but I'm too tired to think atm :smileytongue:

Thank you both for the kind words :smileyhappy: I was just walking through and I discovered that the tree shadows there by the lounge chair had kind of a cool effect. I wasted a lot of SLfilm there before I realized I didn't have the draw distance turned up *facepalm*. I haven't been keeping up with this thread and I have a lot of catching up to do, but so far I'm seeing tons of pics that the only way I can describe them is "Wow! ..just wow!!!" The skills, creative talents, and sheer gorgeousness on display are simply amazing.

Not a vanity shot, just messing around at the cartel hangout, seeing what different results I can get using shadows and deferred rendering at less than ultra settings.

The potential inconvenience of having to enable it (once you know about the feature) is nowhere near as important as the potential problems and frustration it can cause if it's on by default, especially if you don't know about it. Needs to be filed straight into the "first hour experience" and "user retention" safeguards catagories.

squashy Beeswing wrote: Your advice makes me happy because (1) the problem isn't my side and (2) it's fixable. Why can' t i give you kudos for this? You're welcome :matte-motes-smile: and yes, it's definitely fixable. The same problems happen if one fine tunes their physics to a low lag sim, and then they go to a laggy sim like a club or something. Some peoples computers can handle that extra strain and still display things properly, but most won't and they'll probably end up having to make another physics set that's "weighted" (ie - with extra bewb, butt, tummy mass) just to use in laggier places. I made my weighted set while dancing at the same club that had caused my normal set to completely freak out due to the lag there. Kudos not enabled for this forum section, but that's ok... those are only for the kewl kids anyway :matte-motes-tongue:

I can't answer for Phoenix specifically, but I know that in Kirstens the amount of effect you see is greatly influenced by your viewers framerate. If your framerate gets slow & choppy (like at a club or something), it seems like some of the physics frames get missed also and it sends your bewbs into overdrive bounce, with what also seems like no damping applied to them. Electrocuted jellyfish seems a hilariously proper description (lol) for what I've seen. The fix, as was stated by another, is to apply a fair amount more breast mass (under Adv. setting I believe) and the damping setpoints at, or over 70%. I mention this because it may make a difference if your partners system is struggling to render or keep up with SL and yours is not. If it is this problem, adding some mass may help him render and display things more accurately. It may also be that he merely needs to lower his physics detail slider a notch or two.

Cerise Sorbet wrote: Hi, are you using the Phoenix viewer? There have been some reports that it has a bug that causes the physics effect to be exaggerated for some people. Thanks for mentioning that there's a bug related to this. Someone just last night remarked how nice my "minimal" physics set looked, and when I put on the normal set they said it was waayy too much, which I know it isn't. They were using Phoenix and I'm on Kirstens, so that explains it then.

I've noticed the occasional hitching and 1 -2 second pause also, although the pausing I see seems to be specifically happening when I open sidebar catagories (first time or having not had one open for a while), or when I click the X on a group notification or such. Everything else is fine. I'm using an AMD X2, 4Gb, GTX260, 800watt, and the latest Kirstens. There used to be a common issue where these kinds of momentary freezes were caused by extremely heavy disk access, specifically when Windows tried accessing the page file when it was set to "let windows automatically manage page file size", or whatever the wording is. Auto was letting the file get too large, or was letting windows dynamically adjust the file size too often, which was causing these hitches. The solution was to set a fixed pagefile size manually, so it could never get too large or ever be resized. That may or may not be related to your issues.. I dunno.

That's just how the comment was worded, though I assume the person was referencing the difference between profiles and pages like others here have said. It may be that the difference between them in FBs stance is that those other things you listed aren't masquerading or presenting themselves as a character or being of some sort. In that case, such "artificial entities" aren't trying to take the place of a live person, and might not be afoul of their TOS because of the lack of the whole "misleading" thing.. I really have no idea, and since I hate FB, probably never will.

Ishtara Rothschild wrote: Let's hope that Linden Lab get the message. Definitely agree on that one. I think the sole commenter hit it on the mark with "The terms of service prohibit a personal Facebook profile for an artificial entity." As far as I know, none of the SL business or group pages got nuked, only the personal pages.. which reaffirms for me that the personal pages there are searchable in ways the others aren't, and more valuable to FBs advertising returns than the others. LL needs to understand that no matter how much of a media darling FB is, it still is all based on real identities that return real dollars, and avatars are not real identities... regardless of whether it's linked to one or not.

Ansariel Hiller wrote: Sorry, but you miss the point that you can't actually change a protocol that breaks current clients only in favor of future extensions. Well, you can from a technical point of view, but not from the overall scope. You either have to take care you don't break any existing clients or you have to make a cut at a pre-defined point in time so everyone knows when the switch is gonna happen. What LL did is just the same as if today there would be made changes to IPv6 that will suddenly break IPv4 in some way and then claiming "Hey, you all know that IPv4 is reaching EOL soon, so who cares?". The change didn't break current clients, and that's my point.. it broke old clients that have been seperated from LLs development arm for quite some time. They've made it clear that they're not going to stop forward progress just to keep everything natively compatible with an old version that's no longer being developed. Even if the resulting conflicts were unintentional or unforseen, the fix is available and the core changes implemented to move things forward and not remain static were the right ones to be made. What the TPVs do or which protocols they cling to is certainly of concern to LL, but not to the point of actually letting them prevent or negate any future developments LL has planned for their own viewer... or their own grid. I expect more breakages like this one to happen as LL refines and builds onto V2, and V1 (and it's functionality) gets increasingly walled out in the process.

You miss the point that having only the unknown parameters ignored actually makes it easier for future backward compatibility. The old protocol HAD to be broken so it could be reworked properly, without adding more stress to the server. The new method ensures that any future new parameters WON'T cause these same compatibility issues again, and it certainly does seem that these physics won't be the last new AV parameters introduced. Regardless of preference, LL made the right call on this one. You fix the core issue, not put band-aids on it, not make concessions for it which will only complicate things, and not engineer efforts that are counterproductive to your project goals.

You may find the fix to the AV and alpha issues by using the SL Development viewer (2.6.9) or Kirstens S21(7a). In either case, it's advisable NOT to use outfits or inventory links that you created prior to the release of LLs official physics viewer (2.6.3). Wear each outfit piece using the original purchased item, then REcreate that outfit entry by making it a new outfit using the updated viewer. Apparently, the problems come from LL having to adjust things to make room for the new physics data that now gets sent to the server along with your normal appearance and shape data (it never used to until just before 2.6.3 went official). Because of these new changes and the extra data that's now included, most V1 and some earlier V2 viewers are now NOT recognizing the appearance update when it comes back from the server, and as a result of how they are coded they are rejecting it, causing the appearance update to be dropped partially or completely. This is why older outfits and links are causing problems, why so many people using V1 and early V2 viewers have issues rezzing, remaining as clouds, seeing others as clouds or ruth, have issues displaying tattoo or alpha layers correctly, have issues changing clothing layers, and why the famous rebake doesn't seem to fix things like it used to. LL is moving forward with advancements, and those older clients that aren't kept current with the newest changes are experiencing compatibility issues due to the new system changes... in other words, the old V1 way of doing things is slowly being left behind.

2.6.1 is what I meant instead of 2.4.1.. 2.6.1 isn't up to date with the last round of changes that LL put into place, and It also doesn't have the latest exploit patch either. It's what I've been trying to say this whole time, that version is not compatible now that the entire system for appearance has changed. If avoiding outfits helps some on this version, then using the latest official LL client or the newest Kirstens (which I use) will completely fix the issue for you and you can go back to using outfits as well. 2.6.1 came out before physics, and there's been at least 2 major updates to the appearance format since then.. it's no wonder that viewer is getting confused and giving you these problems.

Still a bit unsure as to why so many character tests are needed. I've never had to use that even once in nearly 5 years. Try removing all clothing layers MANUALLY from the worn tab, clearing the cache (to rule out any previous textures involving those dreaded polkadot shorts), relog, and use "show unloaded avatar" to get rid of the cloud (set to true in debug settings, or may be in the menus depending on what viewer your using). Doing it that way doesn't change any inventory worn. You may also turn off "use HTTP Textures" as there's still some wierdness with it in some viewers, and I would advise against using "allow HTTP Inventory" (if your viewer has that option) in the current situation. If your trying all this on the 2.4.1 you said you went back to, none of this will fix it.. that viewer is too old and does not have the latest updates.

LMAO.. actually it's not just your pants but your whole appearance. They added extra number spots to the appearance data that gets sent to the server (when you save or rebake), so if someone IS wearing a physics layer then those slider numbers get sent right along with your shape numbers and worn item info. Instead of making a separate update procedure just for physics, they opted to combine the two so it's more efficient is all. In the process I'm guessing some of the older things got jumbled out of sequence from how they used to be, which is why some people on older viewers (or using older outfit assets created on them) are having appearance issues when they never did before.

That's because there's been changes to the structure of the outfits format as well (to allow for the addition of physics data and new clothing item type), and using a 1.x (or pre-physics) created outfit isn't sending all the necessary info to the update. Try NOT wearing an outfit using a physics-enabled viewer, then recreate that outfit from the original parts (not links previously created in 1.x) in that newer viewer. If the physics V2 version of that outfit works as it should (which I'm betting it will) then it's proof that 1.x outfits are for 1.x and early 2.x, but not for the latest versions of 2.x.

Kascha Matova wrote: It's pathetic. :smileymad: Part of the problem is because LL changed what's included in the appearance, they added the AV physics data fields to the appearance data when they introduced 2.6.3. Most viewers that aren't current with the latest appearance setup are not recognizing the new physics data that's now included, and as a result are dropping the entire appearance update. That is why many aren't able to change outfits / certain body parts / alpha & tattoo layers, and why many cannot get their AV out of cloud form lately. It is also why many of those with older viewers are seeing newer V2 users as clouds or ruthed, because their older viewer cannot recognize or accept the new appearance format. LL has flat out said there's no way they'd consider NOT expanding on options and things for the AV, and reverting the code to preserve backward compatibility would mean just that. It's now up to the individual TPV developers to keep their viewers compatible and their users in the loop with these new changes. Chances are, using the most current LL viewer, or the 2.6.4 or 2.6.6 development viewer, or Kirstens RC4a will fix the problem. There are also other TPVs that I believe are current with LLs latest appearance changes, though I've heard that Firestorm IS NOT (not yet).

I'll third what has already been suggested. Blast out the dust buildup in the video cards heatsinc with a can of compressed air, and possibly pull the card out and reseat it back in. Check and tighten both ends of the monitor cable and keep an eye on your video card temperature. Video artifacts such as blocking, tearing in rendered surfaces, stuff rendering in front of things they shouldn't be, and so on are almost always the first sign the card is running too hot. On a technical side-note, the Radeon 9250 is just about bare minimum to run SL.. I have a 9200 mobility in my old laptop (which is almost identical) and it WON'T run SL at all anymore. That should also be a red flag that your poor old chip is working it's little butt off struggling with SL, and another clue that heat might be an issue (more work = more heat produced).

Just R-click and save this texture, then upload it into SL, then edit whatever alpha you're wearing for your shoes and add this texture to the "head" part. You can also just make a new alpha set, and add this texture as a stand alone "no eyelash" one for when you have no shoes on.

Bell Lectar wrote: Dana Hickman: ~~~~"Gain: Determines the balance of the triggered physics effects. 0 = off. Low = nearly all effects for that body part will be small, subtle movements. Medium = balanced, half of the triggered effects will be small, half will be big. 100 = all triggered effects will produce 'Max Effect' level bounces."~~~~ Again, what do you mean by "balance of triggered effects"? Every single effect is separated into different sections in the edit window, and every separate effect section has it's own Gain slider that controls it. It is Max Effect that controls how far it will move, and the first movement is always the biggest with following ones being smaller. And if you check it, and compare the difference between a 0 Gain and 100 Gain, it changes nothing. Or is there something you see it actually doing and I just don't notice it? Can you tell what exactly, not in a vague "size and balance of effects"? Sorry for the confusion.. I shouldn't have had "effects" plural in that name. For each effect category, like you say, it's the max effect that controls the LIMIT to how how far each effect CAN move.. but if you look closely (with gain set to 50) you'll see that not every effect that happens (as a first effect, not a retriggered jiggle) is as large as what you have set for max effect (upper limit). It is the gain slider that adjusts the intensity of all those smaller movements that fall in between effect level 1 and max effect level. For each category like bounce, sway, and cleavage, you have a gain to set how large you want the majority of bounces to be, and a max effect to set a limit to the biggest impact and prevent black eyes. Gain seems to function very much like a threshold slider. The reason you weren't seeing any difference between gain 0 and gain 100 is you were either telling it to ignore anything less than a max effect jolt (gain 0), or telling it to make everything that's less than a max effect jolt BE a max effect jolt (gain 100). They look identical as far as motion, but you'll see a lot more of them with gain 100 because it's also giving max effect impacts for all the little bounces as well. One of the other things that make all the nice subtleties of gain hard to adjust (or even see) is having too much set on Advanced-->Mass and/or Gravity. Those 2 settings seems to counteract gain and eat up the lower end of its adjustments, so if they're too high you actually lose smaller effect movements that normally would've shown.

Jenni Darkwatch wrote: The trick to realistic physics settings seems to be in understanding what the sliders actually _do_. It took me a while, and I'm not sure I figured it out correctly (I'm not usually in human shape). This is what I gathered on what they do: Changes in timing and velocity are what determines if enough G-force has been reached (through body movement) to justify a physics effect. If there's enough then the effect is triggered and it runs 1 iteration (one time through), although it's possible through your settings to have many REtriggered effects play back to back for a single movement (think jiggle). Max Effect: The maximum relative distance that a triggered physics effect can move that body part. Spring: How fast the triggered physics effect takes to complete a single bounce/jiggle/flop (1 iteration). Functions the same as "rebound" does in Phoenix. Gain: Determines the balance of the triggered physics effects. 0 = off. Low = nearly all effects for that body part will be small, subtle movements. Medium = balanced, half of the triggered effects will be small, half will be big. 100 = all triggered effects will produce 'Max Effect' level bounces. Dampening: (deadening, falloff) The amount of resistance against the effect once it has been triggered. Set low to allow for more Retriggers (more jiggles to each wiggle). Set high to stifle a really big flop and prevent it from REtriggering again.

Lyssa Starsmith wrote: I've been trying to think of a way to describe it for a while, best I can come up with is "cone shaped torso" I decided to take a comparison screenshot instead. Well the torso on the right looks like a cone shape to me. What I think you're seeing is "fad rebound". A year ago or so the extreme form of the shape on the left was popular, but then the underlying fads got pinned, and the popular voice started being less impressed by the "wasp waist", "shelf hips", and "big ol' chunky ass" things they had going on. Rebound is , of course, to smooth out the hip to waist line, but as always with trends there's the lame "one-upping" thing that causes many to go way too far with it. I've seen some that also appear to be reducing their upper body and shoulder sizes, and my honest guess about that is either they still want their "I'm all booty" look, or they've fallen victim to the recent "small chest/small bewbs are cooler" fad that's also making it's rounds. Personally, I think any amount of shapeshifting based on what other people are doing is pretty sheepish.

LOL! Ahh yes, the clinically insane things that tend to happen when skilled second lifers with lots of inventory don't want to get bored. Those nearly always make for the most hilarious times :smileyvery-happy:

The short answer is the creating of UV's needs to be done in a 3D program that can alter the mesh itself, Photoshop cannot... "However, Photoshop can create UV overlays as guides to help you visualize how a 2D texture map matches up with the 3D model surfaces. These overlays act as guides when editing a texture." UV overlays are not the same as UV maps, and are for visual reference use only. Any changes to the UV display that occur inside Photoshop are for Photoshop use only, as they just change the way Photoshop displays the mapping OF the current models UVs, not make changes TO that UV mapping. If using an .obj model that has had a texture saved to it as mapping, like one that comes with, on, or is matched to the model, then one can use that accompanying texture within photoshop as the UV layout and paint on it. If you're creating a 3D model from scratch, IIRC you'll have to unwrap the physical models UVs, apply a diffuse layer texture, save the mesh and UV'd texture combo as a standard format 3D file, and then save the UV'd texture out of it as a base texture which you can paint on in Photoshop. The process is different for different 3D programs, so rtfm...err.. consult a tutorial for that particular program. I haven't done it in quite a while, but when I do I always use PS CS4 Extended to texture objects, but always have to apply a base texture to the mesh using the official UV layout in Blender first. Then just import it to PS and paint or layer over the base texture layer in PS. Otherwise the model has no UV/Texture info, what you paint in photoshop won't have any mapping to it, and it won't be correct (or even recognized) when you pull the mesh/texture combo into another program.