Jump to content

Danny Nolan

Resident
  • Content Count

    73
  • Joined

  • Last visited

Everything posted by Danny Nolan

  1. The fact that this isn't live, is kind of silly. It's not going to 100% morph with the avatar mesh. Alpha layers will still be required. This isn't much of a problem in my eyes. The whole point of the deformer project as to allow you to put on one attachment and have it stick to your av regardless of shape. Mesh deformer does this. The delay upon calculating the weights isn't really an issue in my mind. It's a 2-3, 5 second delay. That's not really a reason to just .. not release it. People can make less poly garments, or the customers can wait a few ... seconds for it to deform lol. I think the reality here is just the tension between Qarl and LL. He made a pretty valiant effort to help them out, and Linden Labs, for some reason refuses to be helped. He even offered to give them the align tool, for free as I recall, but they still refused lol.
  2. I'm not a DEV either; my only coding gift to the world was boob physics for emerald. But, I really don't feel like allowing more vram would be much of an issue. Prob just not something they've thought about or considered. Enabling SLI, though I can see as being a bit more steep. It involved working with the renderer, which is def more difficult code. But, it'd help pretty substantially. Shadows + DoF + Materials + SSAO + Screen Space Reflections. We're actually pushing a lot of work into the GPU - and we're at a point where SLI would actully be benficial. Even if, say increasing max vram, isn't just as simple as I'm thinking - then why is it still an issue? LL has programmers - those of which get paid. Difficult or not, if it's in the best interest of your product, then I feel like it should have a substantially higher priority. *shrug*.
  3. Nalates Urriah wrote: Dude, where have you been? Most of the last part of 2012 was doing just that. Read through these: SL Server Articles. Okay. Those are server changes. While they're appreciated, they're not in any way related to my original post lol. I'm talking core engine optimizations.
  4. Don't get me wrong. I enjoy tech upgrades - the material project is pretty awesome, and something we def need. As was mesh, shadows, etc. But a major project whose soul purpose is purely just optimization, I think, is something we really need. All this tech is getting crammed into a client that's already crammed. Things I'd like to see is more threads, option of using more vram, SLI/crossfire working/helping again, network system cleaned up/optimized, etc.
  5. Perrie Juran wrote: Danny Nolan wrote: Prims not showing up until you right click on them is without a doubt a client problem. I'm not going to dig up JIRAs to see if this was confirmed or not, but if it was a server issue - right clicking on it wouldn't make it show up. The fact that you can select it at all means that your viewer is aware it's there - just for some reason the viewer's forgetting to render it. I also see this problem with attachments, hud elements, etc. Been here for .. idk I feel like almost a year now. I think I actually posted a JIRA about it a loong time ago. But why is the client suddenly having a problem it didn't have two months ago? In Firestorm which has not been updated in several months the problem is growing worse. It's there in the official viewer too. Something the Server is not doing is not flicking the switch to tell the Client to 'show' that prim. A check-sum for a cached textured perhaps breaking down? This is totally outside my technical expertise. Something is not tripping the switch in the Viewer to tell it to display that Prim when I first arrive at a location. Hmm. I'm not sure. I've personally had this problem - like I said before, for what feels like almost a year? If I teleport somewhere, sometimes HUD attachments just never show up until I right click them - same with some avatar attachments, and random geometry in world. It's possible the server tells your client when all the data's been transferred - although that seems kind of backwards to me. I sorta feel like the client should be aware of that on it's own. There's def some sort of a lack of "oh it's done." If I can right click on it, and make it appear with all it's textures/geometry/parameters, then obviously all the data's there. But for some reason - the client didn't get the memo. It's also possible the problem I have is separate. Second Life definitely doesn't like to play well with my slower connection (infinite mesh transfers maxxing out my net - mentioned that on page 4 of this thread).
  6. Prims not showing up until you right click on them is without a doubt a client problem. I'm not going to dig up JIRAs to see if this was confirmed or not, but if it was a server issue - right clicking on it wouldn't make it show up. The fact that you can select it at all means that your viewer is aware it's there - just for some reason the viewer's forgetting to render it. I also see this problem with attachments, hud elements, etc. Been here for .. idk I feel like almost a year now. I think I actually posted a JIRA about it a loong time ago.
  7. But , if you close the main HUB window, it closes all child windows also. Unless that's changed recently.
  8. Oh that's right. I forget about that. I mirrored the JIRA on firestorm's JIRA. Should be able to see this one: http://jira.phoenixviewer.com/browse/FIRE-8842
  9. I have a similar problem that you could look into. When you're experiencing this ghost bandwidth consumption, open up your log in SL and see if you're seeing this problem: http://jira.phoenixviewer.com/browse/FIRE-8842 In summary, for me being on a slower connection, my client will attempt to load 32 (default "meshmaxconcurrentthreads") mesh items at the same time, and on a slower 1.5mbps connection, getting all 32 transfers to complete in under 30 seconds is impossible. So what happens for me, is I get these monsterous amounts of threads downloading mesh, timing out, then starting over - which will literally continue to happen forever until I relog. On my jira post, I've posted a very - very simplistic fix that should completely alleviate the issue. Edit: Changed link to firestorm's JIRA.
  10. If not a driver issue, it's more likely SL being pro nVidia. Heard a lot of peole have rendering problems on ATI cards. A lot of people run SL fine on ATI cards, but most rendering problems stem from either old drivers, or the person using ATI.
  11. Triple Peccable wrote: Nalates Urriah wrote: My CPU (Core2 Quad) putts along at 40 to 60%. That is a major misconception about hyper-threaded processors. Your Core 2 Quad has 4 cores, but the operating system thinks it has 8. So anytime you see it at 50%, it is actually running at 100%. Pretty sure the CPU is still actually running at 50%. A thread can't occupy 100% of one core. Thusso, running your CPU with hyperthreading turned off is actually better for gaming, since it'll at most use 2-3 threads. In relation to the original post. SL relies on your CPU/ram. Second Life's main thread is horribly coded, and literally waits for certain things to happen. Thus, it's a engine bottleneck. Not necessarily a CPU, nor a GPU bottle neck.
  12. Do you use Hamachi or Tunngle? Or any program that's creating a fake VPN, or lan connection. If so, you're going to need to set the precedence of your network adapter over it in order to connect to second life. If you don't use either of those, you'll prob want to do these steps anyway. Open up your control panel and go to network and sharing center (assuming you're on windows). Click change adapter settings. Hold alt. This'll open up the hidden menu at the top. Chose advanced -> advanced settings. Now find the network adapter in which your internet is connected to. For me, it's LAN1. Chose it in the connections pane, and make sure it's on top. If you're not on windows .. wel then I have no idea. Haha. Someone who uses mac/linux will have to answer that.
  13. Deferred rendering now using FXAA instead of the normal AA method. It's faster, but it's ugly. I agree completely with you. I'd pefer a little less FPS over uglier antialiasing.
  14. Toysoldier Thor wrote: LOL I wish I were smart enough in technology to even be considered to be on the Emerald crew or any TPV crew for that matter. But yess... how did Emerald go under with 1000's of staff on board? lol There was 1000s of us working on Emerald? Haha.
  15. I see two possible reasons for all these bad decisions. Either 1) They have something "big planned." As in, something that'll change SL completely. Or 2) they just have no idea what they're doing. I'lla ssume the ladder. I seriously feel like half the time LL is just stabbing in the dark, and hoping for the best. Their decisions seem eradic, and really have NO backing whatsoever. Noobs getting harassed? rofl. I think it's because LL doesn't want us seeing Linden employees on TPVs (which I have seen before, btw). I've managed to keep quiet about all my frustrations with LL, but lately it's getting ... VERY hard to do so. I was actually very into the V3 client. Even the V2 client. I loved it, I used nothing but it for a long time. Then about less than a year ago, I started getting a bug which got so bad that I couldn't even be connected to SL for more than 15-20 seconds. https://jira.secondlife.com/browse/VWR-28441 surfaced. And hey, guess what? Still not resolved, nor alleviated. I literally can't use LL's viewer. And haven't for almost two years now. I've been forced to use other viewers, for the simple fact this hasn't been fixed. it's not that I want to, I have to. I've never felt like I actually am losing a lot of interesting in SL, but lately with LL's management .. I've been feeling it. It's just getting rediculous.
  16. Selene Gregoire wrote: *tries to stop giggling long enough to make a reply* I'm not concerned about it. I countered the misinformation and provided the links so she could go look up the information for herself. *still giggling* I'm laughing because I don't use what is now called Avatar Physics. Never have and seriously doubt I ever will. And just fyi, it does seem to be working quite well for the majority of those who use it. And yes it does make one wonder (every great once in a blue moon) out of the hundreds of JIRAs posted on LL's JIRA in a month's time just how many have actually been resolved/fixed and how many were closed because LL has no intention of "fixing" them. Anyway, I believe the point(s) have been made so I think I will wander off and find something better to do. Like helping people get thier issues fixed. They often close down a lot of JIRAs as "will not add/fix." They actually resolve a fair amount of JIRAs that linden lab employees actually post. But the fast majority of outstanding, and important issues that the users post go unnoticed. Took then like 2 years to fix inventory jump-to. Prob took whoever fixed it 10-15 mins. And Avatar Physics are def a hit or miss with people, as I found out. LOTS of people liked it, LOTS of people didn't. It goes either way. Physics work well if your framerate stays 100% the same. It goes all to hell, though at lower framerates. https://jira.secondlife.com/browse/VWR-25545?
  17. Miranda Umino wrote: You can t compare the backlog of issues because the both jiras have not created at the same time , because they have not the same number of reporters , and because it has no meaning for Quality Assureance . Okay, then by that same logic couldn't you say that Firestorm would have more reported issues because it's newer, and that they've fixed technically more bugs than LL has in the last 30 days?
  18. I wouldn't worry about it Selene. This person's defending a company who has made a load of poor choices, and I'm not sure why. I guess there's always got to be one of "those." Comparing the Firestorm team and Linden Labs is a horrible comparison. The Firestorm team are not getting paid by linden labs to fix and improve LL's base code. And, the number of resolved issues? Out of the thousands and thousands of jira posts they've only "resolved" 150 of those in a month? Plus, resolved doesn't necessarily mean fixed. This whole narrow view on TPV is really another nail in the coffin. And I mean .. comon. If you're going to steal my idea of boob physics, at least finish it and make it work right.
  19. *golfclap*. Outstanding Job LL. Let's not bother fixing any of the outstanding, game breaking bugs that have been in the viewer for years and years, nor bother to finish any of things you started that could actually have been useful. Let's also not bother to listen to the community, patch/fix/add things that THEY want. You know .. the people who put that money that's sitting in your pocket right now. If it weren't for the USERS, you wouldn't have made a cent. It's abominable things like this keep happening. For years now, they've been giving nothing but constant oppression and disrespect for the users. People can defend LL all they want, but this is just starting to get ridiculous.
  20. Performance reasons? Adding an extra bolean to the script would cause performance issues? Wat?
  21. Web profiles wouldn't be so bad if SL's networking code was better. As would be a very large portion of second life itself. I can't count how many posts I've seen, and how many complaints I've heard from friends about how things just don't rez anymore. People can be on 30meg connections, and still have to sit around and wait for textures, which often, don't even rez at all. It's dumb The worst part is, LL truly doesn't seem to care. As was mentioned, they're notorious for just kind of shrugging off ideas from the users. I guess I'm just kind of venting, personally. Things not loading really .. really destroys productivity and just overall enjoyment. I teleport to a sim, and tell my friends "brb waiting for textures to load." 6 minutes later, everythign's still grey. Only way it rezes is if I run my mouse over them, then they start to load. Most of them finish, substantial amount just never do.
  22. SLI is completely broken as of right now. I have 2 480GTX, and I can go from 150 fps in a skybox, to like .. 10 with SLI on. SLI isn't really necessary with not running shadows and DoF .. but with both of those on, SLI would help substantially. But LL doesn't seem to really have any intention on fixing it. So. *shrug*
  23. I'm confused by posts like this. Personally, SL's never ran better for me. I'm on build 3.2.4.246064, and I'm at my friend's store which is a skybox with a buncha sculpties, and a fair amount of adds/prims in the store, I'm getting like 150-200fps. However, I'm on a "good" machine. So what it seems like .. is SL's starting to run better on "certain" hardware. But, some people with newer and still decent hardware are reporting less framerate. So I'm not sure. While I feel like Second Life is finally starting to take advantage of my computer, I still feel like SL is horribly optimized. I think, it's using more of my hardware, however it seems like they've just bloated the crap out of the viewer with unoptimized code. So, it's using more of my hardware, but doing so because the viewer's just requiring more resources. *shrug*. But, people are right. You just can't expect to run modern software on an ancient machine. In many ways, SL is more demanding than even games of this and last generation. Core i7 980x @4.5ghz GTX 480 x2 @ 800mhz (running single card, obviously) 12gb of Ram
  24. What Mircea is saying, is to have movement client side. What happens right now when I push forward, is my client notified the server that I'm pushing forward. The server moves my avatar, then notified my client that it was moved. My client completely depends on the return signal from the server machine. So, when I push forward, there's a slight "delay" on when my character actually starts moving, depending on latency. Client side movement would be a lot better. If movement where client side, my client wouldn't wait for the reply from the server. Instead, when I push forward, my character would move immediately, and notify the server what I did. Then, my client and server would keep in touch, making sure that my avatar's position is the same as where it is on the server. And, if it isn't, correct it. I support client side movement. Movement in SL has always felt clunky, ESPECIALLY when you teleport into a new region or something, and your net's busy downloading textures and you try to move. Takes like 4-6 seconds to start moving, and often you run into people on accident cause you can't really control your av.
  25. You know .. for what you're actually seeing in that screenshot. Some walls, a floor, and a couch. That's like .. what 10 textures? At very low resolution. And SL's engine can only produce that image at 66 fps? That just .. blows my mind. With how little is actually in that scene we should seriously be seeing like 300-400fps. Saying that people use a lot of 1024x1024 images is what's slowing it down. Yeah, it does slow the game down. But it shouldn't be as much as it does. Games these days use textures that are SO much bigger than that. They're able to render scene with just as many textures as SL. You could say, that yeah, SL is a dynamic world and thusso has an increased need for processing .. you're right. If it's horribly optimized. A prim should be 100% static, until the server tells my client that it needs to change, render the change(s), then return to being fully static. The OpenGL vs DirectX argument kind of bothers me, too. Yeah DirectX only works on windows .. so make the client able to use both. WoW does this, and runs on pretty much any machine. It, also isn't that optimized, but moreso than SL. They added shadows, and it doesn't 1/5th my framerate like it does in SL. I think it just really comes down to how much time, work, and money LL is willing to put into their viewer. I understand these things can be costly and time consuming but .. I think it's just something that's going to be necessary to happen, and fairly soon. The renderer, as it is, worked decently years and years ago, but now that we have much more taxing thigns, like a much more complex UI, mesh, sculpts, updated physics, avatar physics, etc, there's just an increasing need to start optimizing and/or a complete rewrite of the renderer, and how threads are handled.
×
×
  • Create New...