Dana Hickman
-
Posts
1,008 -
Joined
-
Last visited
Content Type
Forums
Blogs
Knowledge Base
Posts posted by Dana Hickman
-
-
I've had this many times before, and it doesn't matter which viewer you're using, you can still get this bug. It's caused by bringing another window up in front of the SL viewer (when it's not minimized), or from interacting with background controls while a SL popup window has cursor focus during the time when the AV textures are still downloading. Somehow doing that tricks your system into replacing those SL textures with some from the active element (whatever it is), then they wind up getting baked into the AVs final texture during the appearance update. It's a corrupted texture inside your texture cache that's causing manual rebake to fail, because SL looks to the cache first and will use the one there if it exists. The inventory wierdness pic also shows portions of the titlebar where the baked morph point pictures should be for each slider adjustment. This is also the same issue. Somehow focus was taken away from that shirt Edit window right when it was reloading the minimum and maximum slider pics (reloading usually happens when you first go to that window, and right after you hit "save" on that clothing layer). The solution is most definitely to clear the texture cache.
-
honerken wrote:It's like I can't go anywhere these days without someone complaining that my avatar is too tall. I didn't know SL was real life, and we have to look 'realistic'.Perhaps I should just walk around a 2 foot gnome. I'll show them.
If it's women saying this to you, perhaps it's just you missing the hint that maybe if you were a little bit shorter, you and whoever said it just might fit on a naughty poseball set together.. :smileysurprised: ... Not everything that sounds critical is really a criticism, especially if who said it seems otherwise genuinely interested in you. It may have been a pass at you and you just tanked it.
-
Willow Danube wrote:Davier however has the All American feeling with his brown leather jacket , worn out jeans, and nonchalant posture which exude rugged sensuality. Get him a pair of boots and cowboy hat and you can almost smell Malboro on him.
I definitely agree. The one thing he doesn't need is to ruin all his hard work by turning his AV into some unmanly metrosexual... and that's not hard to do. All it takes is a few poor choices (or following popular choice) in attire and *BAM*.. he's sitting around sipping girly drinks with his pinky extended and ordering quiche.
Ok, maybe not all that, but I will say that my preference is most definitely (I mean like 50 to 1) a ruggedly handsome man. I don't care for any of the modern sophisticated, "well dressed" looks, mostly western European stuff... blah and boring IMO. Give me a scruffy badboy that isn't quite so domesticated any day.
For Davier, although it's well known that women are subconsciously attracted to men with somewhat tense, pensive, or brooding looks about their faces, there is such a thing as too much. I see this on a lot of guys AVs and never say anything, but be careful of how low them eyebrows get. IMO yours are right on the limit. They match your face, but the setting itself looks to be very low and that part of the mesh looks quite scrunched up to me.
Just my
. -
Marianne Little wrote:I agree that appearance matters. Sometimes I overhear noobish looking avatars (often men) hitting on female avatars who's clearly spent a lot of time and §L on their look. The same men turn nasty and often accuse them of beeing "Superficial" when they get a cold shoulder. Pot, meet kettle...
This^^^^
I could go off on a 30 minute rant about completely noobish AVs (mostly men) hitting on all the hottest, most heavily invested females they can find, but I won't. I do just have to wonder what they think the counter-compliment SHOULD be when they look like that, and then proceed to compliment ones looks and wait for the same in return...
-
Myra Wildmist wrote:Yes, I'm really delving into AV physics...
My next question is on drag, the setting under advanced parameters. Does my logic make sense?According to the Help, drag "controls the effect of air resistance. A higher number increases the air resistance."So with that in mind, I would think breasts would have less air resistance, because there's a more noticable effect from air pressing on the breasts as you walk around. (Of course most of us wear bras in real life, but let's ignore that...) So a lower drag number is needed for breasts, the butt a little higher, and the belly the highest of all.When setting drag, breasts should be lower than the butt which should be lower than the belly. Does that sound right to everyone?Thanks
Think of the drag settings as adjusting how thick the air is around them. Moving your body though regular air with a low drag setting equals quick response and little resistance. Setting the drag high will be like trying to move through yourself through thick pea soup, lots of resistance and your wiggly parts will lag behind your movements.
Generally, I'd say drag on all parts needs to be near 0. I say that because the drag setting doesn't care if you move a tiny bit or a lot, it still lags that body part behind you the same amount regardless. It can look rather dumb IMO. Use a slightly higher mass setting instead to get the same "lag & catch up" effect, but it won't look 'tarded because it does react differently depending on what movements you are doing. The gravity setting helps determine how sensitive the effects due to mass are.
-
And just another reminder for people tweaking their settings... Anyone using the latest LL V2, Kirstens, and at least one other TPV which I can't remember will be seen with exaggerated physics movements when viewed by anyone using Phoenix, Ascent, or any TPV that isn't up to date with the newest tweaks that LL put in. Likewise, any of the Phoenix group users will be seen by the V2/Kirsten group users as having much less physics movements than they intended.
I've personally tested this using Kirstens S21(7a) / S21(8)RC1 & 2 against Phoenix 1102 and there is in fact about a 40% bloat to nearly all applicable settings when viewed through Phoenix. A mild 30 seen in V2/Kirstens equals roughly 60+ when those physics are viewed through Phoenix, which is a pretty large discrepancy. Something set to be noticible, realistic, and just right in Phoenix won't be seen at all, or is barely noticible when viewed through V2/Kirstens. The adjustment scale between the 2 groups of viewers is different... just so you know....
-
Venus Petrov wrote:I am much more boring. Here I am today in Misty Mountains.
*cough* *sputter*
That is NOT boring, that's gorgeous... Both you and the photo!!
I'm also obligated (as a brunette, I think it's in the rules somewhere) to say that the darker, reddish hair adds mystery and brings out your eyes... it's all in the subtle details and the eyes. /me approves
-
It's bewb clappin (aka together or seperated, highly affected by the mass and gravity setting).
-
Void Singer wrote:Racheal Rexen wrote:I dont get this meeroo thing at all,I thoughtabout getting some but it seems a waste of money
I think I have spotted the trouble in why it seems like a waste of money to you =DLmao w/snortz !
-
oh why not...
First arrival: Ahern
First L$ purchased: Approximately 20 min after arrival
First Purchase: Hair
First inventory item deleted: the skin I bought with my second purchase (it looked like crap, little did i know it just hadn't fully rezzed yet)
First land purchase: Linden First Land, 512m - southern continent
First friend: The nice guy that heroically chastised the guy who gave me my first crude pick-up attempt
First lover: The guy who gave me my first crude pick-up attempt :smileytongue:
-
Storm Clarence wrote:Education. To me it is all about education. The more we rewrite history by NOT mentioning the history - the more we as a people will begin to forget what really happens in our world.
.. and the more we forget it, the more we're doomed to repeat it. Someone pretty famous said that I believe :smileytongue:
-
Jane Corvale wrote:To update on the situation, I have:
- reinstalled the client completely
- tried other viewers
- updated java, flash and graphics drivers
- disabled and re-enabled the ATI Catalyst AI
- tweaked various graphics options both in the CCC and in-game
- given the process a higher CPU priority
- checked my bandwidth and network settings
- ripped out almost all of my hair trying to figure this thing out
Try using a large, fixed size for your windows page file.
(in XP, sorry i dont have win 7) It's System properties-->Advanced-->Performance settings-->Advanced-->Virtual Memory (change)
Select 'Custom Size' and enter a number between 5500 and 7000, BOTH initial and maximum size need to be the same.
It wants to be set a good safe margin above your peak usage, but not too high. You can monitor your current page file usage from the performance tab on windows task manager to get a rough idea how much you use during a SL session, then add a couple thousand MB's to get the right number to set.
-
Thank you Sylvia :smileyhappy:
Ok, here's one more of me and that bird... although this time he may become lunch :smileytongue:
And one more stray pic from Costa Rica -
-
1
-
-
More fun with alts -
A passing fancy -
And a morning fire repost -
Thank you again, windlight team :smileyhappy:
-
1
-
-
leliel Mirihi wrote:What you're talking about sounds like a form of occlusion culling known as portals, it's a very good system for occlusion culling that was first used in Quake I believe. The problem is that it only works on static geometry, you have to pre compute all the data for it. Obviously this won't work for SL.
Yes, it was Quake, but it's not portals. Portals were used to link areas and condense the physical geometry of a location, so that the entire area didn't have to be built out in visible space. They do use culling tied to POV, but that's only an add-on so they can appear non-existant while seamlessly linking multiple geometries together over a distance. Yes portals need to be precomputed, there's just too much math, but what I speak of is akin to the POV culling add-on used standalone, and it's not why portals need precomputing. One can easily see this by using game editors and just placing occlusion zones in the geometry somewhere. Live and in real time you can see portions of the geometry disappear based on the cameras POV, and if the affected area is large enough (or your system is weak enough), you can also watch the associated workload drop dramatically. This again is live, well before a single thing is ever compiled. There is no reason why it can't be brought to SL, the ground work is already in.
The viewer uses render culling, yes, but it does not take advantage of that to also drop the associated processing of what's already been completely culled, and that is where the issue lies. SL already does those high latency tests you speak of when it render occludes and computes POV in the first place, and what I mention is only a branch off of that, not a completely new thread. Certainly many newer techniques can be adapted and used, and in fact those are preferrable because of their efficiency, but that still doesn't change the fact that SL doesn't do this at all and most others do, which is my point. It needs to get here for hardware performance reasons above all else.
What you mention about zone gaps in walls only applies if one is trying to completely occlude every single thing, and such precision is not necessary to still acheive major reductions in the number of prims the viewer is having to think about at one time. It matters not that a thin slice between adjoined prims may indeed allow a handful of objects to be seen from straight on when it really doesn't want to, it's only the total number that matters in this case. All the builder need do is add a single invisible phantom "sheet" prim inside the wall interior to block the gaps and thus occlude the entire walls area with 1 prim instead of many. It doesn't get any more efficient than that.
-
That's a rather good, in-depth guide for using the prim / mirror method to help guide proportion... thanks for sharing it.
One of the comments was also dead correct when they said that AV's wanting to be around 5' tall will look best at 7 to 7.5 heads, and those intending to be taller should fall in the 8 to 8.5 range. There is no actual standard number of heads measurement that spans all the different heights, because if one actually takes a minute and studies others in RL, they'll see that even though taller people tend to have slightly longer heads, their bodies are also a greater number of their heads tall when compared to average height people, and a lot more than short people. Some will swear up & down that it's always 7, and that's incorrect. 7 heads tall will make a fairly short AV look like their head's too small, and make a tall AV look like a bobblehead. It's a moving scale, not a fixed one.
I know I fall closer to 8.5 heads than I do to 8, and may even be a little over that, but I made this shape years ago when I actually was one of the so-called amazons. Since the scale of what's considered tall has actually increased over the years, I'm now closer to average height in comparison to the masses, and the side effect is it's thrown my overall compared proportion off. Fixing it means a lot of work and I've just been lazy about it.
-
Penny Patton wrote:This doesn't affect performance so much as load time. There's certainly a CPU hit as streamed content is processed, but it's fairly minor compared to other issues.
That's correct, which is why that paragraph about what I didn't see mentioned so far was seperated from the rest which is about performance. It's an observation only. Your answer above though, is exactly my reply to what you said regarding the misuse of multiple large textures where one 512 would do. Just like you say, it's many times more a LOAD TIME hit, not processing, and so all the mumbo about texture misuse translates directly into network and latency issues, and not anything tangible relating to render performance.
Penny Patton wrote:There is maybe only 200 prims visible in this shot.That's great! A good example of how prim efficiency can make some minor improvements on the rendering workload. Now go back to that same sim and go into wireframe or turn off texture use. THAT is how many vertices your renderer is processing, not just what's "in view". Why are all the prims and vertices that are behind the visible walls and large objects, all the way out to the end of your draw distance also being processed? Because there IS NO zone occlusion in SL. If there was, showing the wireframe mesh and vertices like that would ONLY show specifically those ones that are directly in your line of sight and not hidden behind an occluding object... everything else would be void or blacked out, and moving your camera around would cause some objects to pop into processing and some to blink out as the system dynamically decides which new prims to start processing and which ones now out of "line of sight" to stop processing.
Like I said prior, "processing" or zone occlusion is not the same as "regular" or render occlusion. Render occlusion is what decides which objects to partially display so they appear to be behind nearer ones, or to not display at all because it's hidden behind something else, and without it SL could not function at all in any 3D sense. One needs to understand that the displaying of an object is only the last step in a long sequence of pre-render calculations, and it's those calculations that cause the big burden. Zone occusion is what keeps all the unnecessary calculations on objects not even being displayed yet from taking place until they are needed. SL does NOT do this and the proof is right in wireframe, or the skybox test scenario I posted earlier. With zone occlusion, being in a closed skybox would get you exactly the same framerate when the box is placed in the middle of sculpty hell as it would in the same sim at 4000m. We all know SL doesn't behave that way, and it's because there's no zone occlusion that it acts the way it does.
You make a case for inefficiency, and that's fine. I don't disagree that it can cause problems. MY point, however, is that whatever prim inefficiency that exists wouldn't wind up being the straw that broke the camels back if we weren't already having to process and pre-render every hidden object as well as the ones that are visible. Eliminate the inefficient workload instead with zone occlusion and the prim inefficiency now becomes mostly a non-issue, because now you have the extra horsepower to take the much smaller bumps that poor prim use gives you in stride.
-
Interesting and informative discussion. One thing I noticed however, is that during all these comparisons made between graphics of this game and that game, NObody has given weight to the fact that everything you see in SL has to come down the ethernet cable before you can see it. That is NOT SO in every game mentioned or compared to so far. The entirety of the content in those games ALREADY resides on the users computer, in the form of either a fixed, precomputed environment, or made available through PRE-loading of update packages before runtime. It is NOT streamed live at connect time like SL is. The only things that SL reads locally is the avatar mesh, a few of the simpler effects and settings, and whatever cached content you might have. The burden that places on ones entire system, not just rendering, is many times that of other games. Of course those other games will run many times better than SL does on most systems... duh.
With all the talk of non-professionally made content in SL, you'd think that it's a pro game design firms worst case scenario, when in fact such cases of gross / widespread ineficiency and misguided use in SL are pretty rare. Of course one can point to an example of such here or there, but that in no way indicates that all, most, or even a lot of the content in SL is to blame for ones poor performance.
The differences to be had by eliminating much of the user-created inefficiency you see is not as large as some may think, because the issue lies not in the content but in the underpinnings of WHY user-created content can potentially cause such issues. Two terms... zoning & world space occlusion. Everyone else has them, and has had them for at least 10 years... SL does not. As it stands, SL forces you to download and process every single thing within your draw distance and between the edges of your POV render area, regardless of whether you're overlooking an open valley or standing nose-up to a mountainside and fighting the content that exists on the other side of it. It is precisely why skyboxes get better framerates than the same box would if it was on the ground in a crowded neighborhood, even if it has no windows.
Every major game developer programs into their game so that the enclosed space within the 6 (or however many) sides of a primitive shape has a positive world space attribute.. it has positive volume (Unreal engine is backwards but functions the same way in reverse). It is used to differentiate the space inside from stuff outside of it (which would be negative space, or negative world space attribute), and that's what a zone is. They can have multiple properties or attributes, but for sake of this discussion, the important one is "occlusion = true". SL already calculates the POV, and what objects are inline with the POV and within the draw distance. The only thing missing is an additional prim properties flag that tells the viewer that anything that's completely hidden behind it is "do not process". The viewer sees it and immediately does not process geometry or textures that are 100% obscured by the object, for the cameras current point of view. Such calculations are not heavy at all, done 99.5% client side, and are routinely done on the fly as an industry standard "trick", so to speak. LL land and land patches could easily use a flag such as this so that the viewer doesn't have to process stuff that's below the ground or hidden by it, as in the case of a mountain or hillside. Prims used to make structures, like walls, floors, ceilings and such, could easily be set to occlude what's inside.. that way someone standing outside facing the building will NOT have to process everything inside of it, or what's behind it that he cannot currently see. Those inside wouldn't have to process or render any part of the outside world until they encountered a prim or window that doesn't block their POV with an "occlude" flag. Prims with transparencies, of course, cannot be set to occlude, and prims smaller than 2m should not be allowed to be set to occlude, because that can cause issues in and of itself. Only two additional numbers ("flags", values of 0 or 1) would get sent by the server along with the prim infomation, one is for positive or negative space, the other is for occlusion on or off. This is not the same thing as normal occlusion, which is what lets one object appear to be behind another, this is complete render and process occlusion (basically exclusion), which means the system forgets about it entirely (except where it is) until some part of it becomes visible.
We were doing this process more than 10 years ago with the Unreal and ID Quake engines so that the players didn't have to compute and render an entire level all at once. It's not some pipe dream, and the savings in terms of performance are HUGE.. with a capital H. Make no mistake, it can be done here, and most of it is already done. It's the lack of this standard feature in SL, not someones poor building or texturing skills, which is 90% at fault for your viewers getting hammered down by too many polys to render at one time. Don't blame peoples inefficient content, because you're yelling at the tip of the iceberg on this one.
-
Ahh my bad. "Like always" I took to mean with eyelashes like the SL default.. lol. No worries then.
It seems there's been some kind of changes to it, yes.. I've noticed many skins that do use the skin alpha now seem to have the lash parts whited out, ghosted, or not even transparent at all.. and they never used to. The plus side is hiding the lash mesh part with an alpha layer will rid you of the dreaded alpha texture bug if you happen to also wear prim eyelashes, so at least that's a good thing.
-
Catwise Yoshikawa wrote:anyone knows what would be the problem?edit: Ok, I tried adding skin head to an alpha layer and now it looks like allways. I guess they broke the alpha thing for lashes in skin layer...nice
Alpha layer textures can only be black, white, or a mix of the two. When using any other colored texture (like the head texture from a skin), any texture colors darker than 50% will default to black (do not show), and any colors lighter than 50% will default to white (show)... that is how the alpha layer system works. If you did like you said and have a light skin tone, it would likely default to all white and the alpha layer would have no effect. I just logged in, so I'm sending you my eyelash alpha layer, and the separate texture itself to use in other pre-made alpha layers (like the ones that come with shoes). If there's still an issue then I'd suggest you clear the cache and try again, because I can guarantee the alpha map i send is correct (been using it for months).
-
These critters remind me an aweful lot of Disney rabbits drawn by Don Bluth. Not only in shape, but in texture as well.
-
I like the way it is now. I don't save links to sub-pages or threads, but I DO try to find threads I remember reading recently, and this helps tons by cutting down the number of sub-forums it could be in. It was too diverse before and like topics were getting scattered throughout the place. Thanks Lexie :smileyhappy:
-
I keep every CARD I've ever gotten, but I do remove people from my friends list when they go missing for a long time. I should actually go clean out some of the ancient ones that I have no idea who the person is.
-
Bree Giffen wrote:I just switched to a new viewer (Kirsten's) and I got this too. I adjusted one of the eye shaping sliders to get rid of it but I think I'll try the cache clear.
I had the same thing a while back when I also switched to Kirstens, and once I had cleared the cache and then saved the first change to my shape it cleared up. Kinda spooky, and really bad when you smile lol. Adjusting the AV details slider may also help.
.
Facebook
Instagram
Twitter
YouTube
Flickr
Most Avatars have their arms too short
in Your Avatar
Posted
Standing straight up with hands at sides, a line from wristbone to wristbone should cross halfway between naval and genitals. Fingertips should reach to "bottom of pants pocket" length. It's helpful to use the AV mesh as a rough guide because many SL skin designers have no darn clue where the human bellybutton is supposed to be.