Jump to content

NiranV Dean

Resident
  • Posts

    1,147
  • Joined

  • Last visited

Everything posted by NiranV Dean

  1. A) This is not a bug. This is intended behavior. B) The description of that bugreport is so off and the pictures even show that whats being said is not the case. You can very clearly see Depth of Field working on both shots. Infact Depth of Field is exactly the same in strength on both shots, the only difference is that the other image is much bigger thus the effect is diminished relatively seen to the total size of the image. C) It's sad how little people actually look at their pictures after taking, they would have seen that Depth of Field is there.
  2. Well in that case, congratz Firestorm, you finally arrived at the issues i had months ago.
  3. Ah, it sounded like you were talking about bugs in Black Dragon.
  4. Your connection has no impact on your performance other than slowing down/speeding up the download times and thus the amount of things that can come in at a time as well as the time it takes for a scene to fully load, after that performance is solely hardware and viewer/settings.
  5. That's not a shadow issue and seems to be Black Dragon Viewer, an outdated version at that. This is actually an issue with alphas not getting lit by lights, one that should be fixed in later versions if this is Black Dragon.
  6. All screen effects requiring additional finetuning for higher resolutions is not a bug, this is normal behavior. All your settings are made for the resolution you see on screen, which is the original window resolution, taking a snapshot at any other resolution requires finetuning these settings for that new resolution. In other words, you have to configure your settings for the target resolution. That's why there is a preview window. All Viewers show this behavior and this is totally normal due to the way these effects are calculated (absolute rather than percentage based). Note that higher resolutions require much higher/stronger settings which in turn need higher hardware requirements which multiply with the already increased hardware requirements of higher resolutions, this can and will quickly lead to a crash if your GPU isn't at the very least a GTX 1060 (6GB) and up. I tested up to 12.000 x 6.000 shots and even those will eventually lead to a crash if done often enough.
  7. That is not a bug. That's actually a feature. This on the other hand...
  8. You shouldn't believe everything people say somewhere on the internet. Especially something so user-specific.
  9. That's because the GPU unlike the CPU is not limited and can be used almost completely by Second Life via everything that is shader based.
  10. With all this talk about Multithreading and Optimization, i guess its time i should look into Multithreading again. Looked really fun and if you know the catches it is technically not all that complicated to implement, its just a lot of work. Years ago i made an experiment to speed up the Preferences window creation because opening it for the first time (and potentially all subsequent ones that update the Avatar Render List) caused the Viewer to stall for quite some time (even more if your render list gets bigger), to reduce this to a minimum i moved the render list creation to an extra thread and only have the main thread fill in the list with the data collected in the extra thread, this significantly reduced the hitch to an absolute minimum. This ofcourse was a small scale test and the situation was perfect since all of this stuff was heavy work and was done in order and could be easily done all at the same time. But there are many parts in the Viewer that do things in order that do weight in quite a bit and could be offloaded into another thread, things that don't need to be up-to-date at all times due to SL's extreme sensibility which in turn has SL hardened for a lot of weird situations where information is not yet available, which in turn means multithreading could be easily applied as the Viewer won't care and will simply update the information whenever it is ready. Single Thread vs Multithreading
  11. How would having them protect you from said issue? How does having LL's address protect you from them simply wiping your account? You and only you are responsible for what happens, LL clearly states that they are not in any way responsible for something that happens when using TPV's and having their addresses/phone numbers is going to help you how? Are you going to call them? Find them and beat them up at their door? I don't see how having this very private information protects or helps you even in the slightest, you wouldn't even be able to call the support, they would laugh at you. Distrusting the developers is one thing and i can understand that but distrust because of a missing address/phone number... idk that sounds very far fetched.
  12. They got rid of that because it is the only sensible thing to do. You should not be able to see who is hiding from you, that's the sole point of hiding in the first place. It's called privacy and should not be circumvented. What do you need a physical address or phone numbers for? I'd be kinda scared if someone just popped up in front of my door to tell me that there is a security issue, something they could have told me via the million other ways to contact someone (Mail, Discord, Inworld, Website, Forums and so on).
  13. Not anymore since they introduced the new one, i couldn't get that one to work and gave up after a while, it simply denied to compile.
  14. Update the Viewer, you are using a years old version. (How the hell did you even get that?)
  15. The answer is because neither of these (or any other engine) would be able to do what is required to do for SL to function without changing so much of the engine that it is questionable whether you are still using said engine (aside from the tools/editors and QOL/features provided). You might as well rewrite SL's Viewer in its entirety, that would be a similar amount of work (although as said engines would offer some benefits like tools that would help potentially creating more stuff in the future faster) It's like taking a racing game engine that was solely ever made for racing games and using it for a shooter, unless heavily modifed and extended you'll basically play a hacky shooter that feels like you're driving a car.
  16. Sitting is easy. When sitting you no longer count as physical object and thus no longer need to calculated physics for, you simply become a static object (or disturbance for other objects that bump into you), this saves a good chunk of resources. I don't remember what exactly was said but i think they said physics are currently the highest cost. Standing on ground and standing on large objects should theoretically make no difference, whether you are standing on a surface, whatever that surface may be should not matter, you are simply calculated as physical and react as such, whatever that reaction may be (usually just standing still, sometimes sliding off on slopes). A possible reason why standing on ground might be faster is due to the collision for terrain being baked, so its a static cached thing that only ever changes when necessary, this saves time as it does not need to be processed before calculating your physics, objects on the other hand do need to be figured out first since they can change constantly (just like you do). Technically speaking something similar could be done with the navmesh baking but would require a rebake every time an object changes position and constantly moving objects would quickly destroy any hopes of that ever happening unless constantly moving objects are excluded and calculated separately.
  17. https://jira.secondlife.com/browse/STORM-2150
  18. And i'm still waiting for that second meeting that was supposed to happen to further discuss the details of the Poser implementation WITH the requested synchronization this time.
  19. Yes, that small group should be US, the TPV developers who A: have to deal with it when it releases and B: work both as long time users and as developers.
  20. Interesting, i specifically checked before i made that comment. I remember them removing something in this window (from the commit message) and opening the window reveals that the personal script info was removed, for whatever reason. I have never touched this window, the window is 100% stock so i would not know why the merge would have erroneously removed the wrong tab. I also vaguely remember an upcry about the removal of said personal memory info and other than a toolbar button (and the land info Script Info button) i don't even have an option to open this window. In any case i can re-add it if it was not removed. Just another thing to add on my todo list. EDIT: Going through LL's menu_viewer.xml confirms my suspicion that they "removed" it from the above window, they did not however remove it entirely, just made it its own window which got a new menu entry which was not added due to my Viewer having its own custom menu. You'll be able to find it in the next update in Dragon - Edit - My Scripts
  21. Okay, let me rephrase that and further refine what i said. Whoever in in charge and has the final say that leads to all of these projects being half assed does not care enough to ask those that have more experience on the matter for help/feedback/suggestion and even if, does not follow through with them due to either budget limits and/or unwillingness to delay a project for the sake of doing it right. Maybe they should... gather some feedback you know?
  22. LL removed the script memory tab for yourself a year or so ago.
  23. Irrelevant, they do it all the time, breaking our content and that is to be expected in a virtual world. We're not talking about a closed system like a game for instance. SL is open and dynamic. Where were you when they broke years of my content with the decision to bring the legacy shiny to Deferred Rendering. What about EEP, it has broken specularity a couple times, not to mention it has broken lighting and a lot of your windlight presets that have been created the past 10 years. Leaving something the way it was is exactly the kind of thinking that has caused SL to stagnate so much, they fear backlash from breaking things, so they rather leave everything as it is, even if that means leaving in a 20 year old bug (such as some of your attachment slot X Y Z not being mirrored on both sides) but at the same time they get confirmation that they should not do anything that risks breaking content because every time they do break something they get backlash. Their problem is not that they get backlash, it is the fact that it is highly deserved looking at their history track of half-assing everything they do but they take it as confirmation for their expectations of a user who doesn't want change. LL has to learn to differentiate between deserved backlash and undeserved backlash, they have to learn that to move forward you cannot go backwards and more importantly they have to learn to work more with us, integrate us more into their workflow, keep a close watch on suggestions. I have 10 years of experimenting with different things, i can immediately tell them if what they are trying to do will earn them backlash. Take EEP for instance, did they listen when i told them that making presets a permission-based marketable item? No. The idea of making them items has been there before and was already part of TPV's long go, back then they were not subject to permissions however. Nowadays a text file that contains a set of values is considered intellectual property, rather than the contained marketable items only (textures for moon/sun/clouds) like it was before. I can't go to a SIM anymore, play a little bit with the windlight and then save it for later anymore (say when i come back or want to share it for others to make similar pictures), in case of the Official Viewer you can't even change all of the parameters, the personal lighting window is still missing a good chunk of settings. Instead now i have to write the values down and painstakingly paste the values into a new preset, how was that necessary and how did this help preventing "stealing" presets? This makes taking pictures (something i have loved doing for over 10 years) unbearable to the point that i stopped doing the very thing i loved. Did EEP help me as photographer? No. It broke everything and made everything unnecessarily hard and annoying to use. Did they care? No. Why should they, altering a couple settings? Oh right, Oz told me once why... "no one has yet complained", when i asked him why the Depth of Field defaults are still ass, i'd call that straight up a lie, i'm sure many people have complained. LL is just lazy and extremely inconsistent.
×
×
  • Create New...