Jump to content

Danny Nolan

Resident
  • Content Count

    73
  • Joined

  • Last visited

Community Reputation

0 Neutral

About Danny Nolan

  • Rank
    Advanced Member
  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.
×
×
  • Create New...