Jump to content

NiranV Dean

Resident
  • Posts

    781
  • Joined

  • Last visited

Everything posted by NiranV Dean

  1. There is no source code required. The Viewer itself is sufficient and any Viewer can simply be modified/translated. Look into the skins/default/xui/ja folder, find the viewer_menu.xml and see how its done, find the original file in skins/default/xui/en and translate it according to that
  2. And this would be the end of all good. This could lead into everyone hoarding their stuff (more than we already do) and only giving it out for money which i highly doubt LL is willing to pay eventually leading to complete stagnation in open source development and the death thereof. Look what Bethesda got for making mods paid. They got a massive ****storm, deserved.
  3. If this is about Black Dragon then it its intended. Normally the Viewer renders invisible meshes when they glow. In BD i specifically do not render them as they will otherwise be treated as full opaque meshes resulting in them casting shadows (as if they were fully visible). Not to mention something that is invisible should be... well invisible, it should not glow or in any way shape or form be visible, transparency has priority over everything else. If you want to have rigged meshes that's invisible with glow you'll have to use workarounds such as using transparent textures which have opaque parts where they should glow.
  4. Framerate and impact cannot scale linearly due to how framerate is calculated. Say a full frame takes 10ms to render this corresponds to 100 FPS (1000ms / 10ms). If any part of the rendering has a certain impact, say the avatar has a total impact of 5ms impact it will have drastically different FPS impacts depending on how little the baseline render time is. 5ms on top of 10ms would mean dropping from 100 FPS to 66.6 FPS (1000 / 15), whereas adding 5ms on top of 100ms would drop you from 10 FPS barely under 10 FPS, it wouldn't make a noticeable difference. This means small millisecond impacts don't make much of a difference when we're talking about low framerates, whereas if you are getting into the range of 30-60FPS they start to make a difference.
  5. Every chat window in CHUI has this button to pop it out, including the nearby chat. A popped out window then has the option to be collapsed to a chatbar or brought back to the conversations window. Collapsing to a chatbar is only really helpful with the local chat obviously, that way you can have a free floating chatbar that you can put anywhere you want it (including into the lower left corner below local chat) like i had it since CHUI. You can expand it to see the local chat history at any time if you need. I'm surprised this is unknown considering its right there and will be found in a matter of seconds of checking out the very few buttons the chat window has. BD also has the option to change the chatbar behavior more to the V1 one by making it auto defocus or auto hide after sending a message (hitting enter), or alternatively whenever the chat loses focus (which in combination with auto defocus does the same as auto hide on enter except it also hides when clicking out of the chatbar).
  6. None of the non-V1 based Viewers ditched the V2 interface. We all use it, we just lay it out differently. The V2 interface is actually pretty good and very powerful under the hood, just no one seems to want to look into it and use it (especially LL, they make it extremely obvious that they are unaware of the capabilities of their own UI, which isn't a surprise considering that the team making it got ditched after receiving heavy flak for what essentially boils down to people not wanting a more modern interface and some initial issues which are to be expected considering that it was a total rebuilt of the entire UI). I prefer the V2 UI (pre 2.7+) over V1 and V3 (post 2.7). No one except Firestorm and V1 has that bottom chat bar, although you can put it in the bottom if you pop it out.
  7. But here's the problem already, everyone wants to do certain things and doesn't want the other things, every one wants the viewer to be something specific. All the people who don't care or have the same vision already work together (namely Firestorm). If it was that easy to just collect a couple devs together and make another Firestorm, it would have been done by now.
  8. I'd like no CHUI too. I want my good old chiclets back. Someday...
  9. Which means you are either not demanding enough of a certain feature that both offer or you don't demand a specific feature BD offers over FS. However, this does not change the fact that having more people do more inside a single Viewer will ultimately result in overall lower quality of each feature in question. A small focused team of like minded people can make a Viewer excel at a specific task, finding said people however is hard. For instance i could work with/for Firestorm, what stops me from doing it? Their entire idea of the Viewer and what it should be, everything i do and want contradicts what Firestorm does and wants. I could work with/for Singularity but its a V1 and i hate the V1 UI also i'm sure they don't want to touch the UI like i would want to. Same with Alchemy, we both share similar goals but i don't feel like my idea of an UI matches what Alchemy wants (a stock-style UI). Would you want me to touch any of their UI's? I suppose not. Working for/with any other Viewer would mean i'd have to take compromises, i hate compromises and avoid them at all costs but that's just me. I'm sure some other devs were fine with the compromises they had to make to join any of the other teams. I'm certainly not, especially if it involves one of the major things i do.
  10. Which is not going to work because you'll end up with Firestorm's situation again. You'll have too many people wanting too many different things in the Viewer and the Viewer will simply have no focus at all, a jack of all trades but a master of none. Quantity != Quality.
  11. Restarting doubling down as "resync" is just a nice side effect, it was never meant to do that, but there is said option. I'm not planning to include a resync animation option (apart from it already being there as explained) as i find it incredibly useless when you have a poser and change/edit poses to match anyway. It also overlaps other controls too easily. WASD and CTRL/Shift/Alt in any combination are extremely dangerous shortcuts as they are used for camera and movement and can easily overlap (Advanced menu toggle does for instance)
  12. 2) You can turn it off, just not in the Viewer but regardless of any Viewer. http://wiki.secondlife.com/wiki/Show_Look_At 3) You can resync animations. Dragon - My Useful Features - Animation Controls - Select everyone you want to sync, hit Restart. 4) Hardly an annoyance if you can change it, its just a side effect of a much less forgiving complexity system. 6) You can highlight local light sources like in any other Viewer, the option has also been recently added to the options window of the Build floater. Otherwise you can find it in the Tools menu (like in most Viewers), Dragon - Tools - Options Horror stories from people that didn't check the FAQ, didn't ask for help and did not check the Keybindings tab in Preferences that allows fully customizing controls.
  13. Now this is something i'd be highly interested in, i tried doing this via fast timers but fast timers does not allow dynamically naming each timer section according to the avatar (i'd have to name them manually). Actual CPU time spent on avatars would help a great deal making the complexity floater and breakdown more accurate. Also, i've said this a million times before, the current complexity values from LL are trash, outright wrong and in no way shape or form are even remotely accurate, they penalize actual good avatars and give free roam to the worst of the worst. (which made me change it completely in the first place)
  14. So i just downloaded and tried the new performance floater. I'm getting very bad vibes from this floater. I mean good lord, finally someone with some UI knowledge touched the UI, it looks clean and fancy and kinda modern too (still wastes a lot of space though). But the floater itself really... doesn't do anything. It's completely pointless, its a pointless rehash of a few very select options and some very generic tips that always say the same "this option may or may not cost frames". The complexity section is... barely functional to say the least and really is not helpful at all.... 21... 21 what? fishies? Also, what 21, whats making it 21? I want a full on breakdown what and why its 21. What does it consist of, what does it use, whats the lion share of these 21 fishies. It presents me yet another number that has no meaning, this time even more confusing than last time. After spending 1700+ hours on VRChat and getting performance rankings and working hundreds of hours on avatars and optimizing them i'm really spoiled by their performance ranking system. I've implemented a basic version of that into my Viewer already: A full on breakdown is there too and even then i feel this is still too little: Here's an example of the on-upload performance rating system:
  15. Sounds like AA is not working because Deferred Rendering is not enabled, for AA to work you need to have "Advanced Lighting Model" enabled, also everything above 2x does nothing, unless its Firestorm in which case i heard they brought back the Multisample AA thus making 4x and so on actually work. I do not recommend forcing AA via drivers as it applies to everything including the UI and text making it harder to read.
  16. Additionally your hardware will only work as hard as you allow it to run, if you turn everything up you should expect your hardware to work more whereas with default settings you should get similar results to the LL Viewer. Also, under normal circumstances hardware does not overheat as it is cooled (unless its faulty in which case it could happen everywhere) not even if running at 100% at all times, that is not counting external influence of course. Laptops are generally cooled worse and they produce a lot of heat, having one run at 100% for extended times in a closed room at above average room temperate and no air circulation (or in hot summers for instance) can quickly cause overheating (at which point as Henri pointed out they will start throttling or worst case shutting off) not just your hardware but will most likely turn your room into an oven, but that is to be expected given that heat has to dissipate somewhere and hardware produces heat... but then again who lets their PC run in a hot summer... right? right?!
  17. That's why they are called Ultra settings, they are ULTRA. I wouldn't expect a 18 year old engine to perform decently well with settings labeled "Ultra" unless they are potato graphics in reality. No, thats due to the Viewer using the free image decoding library OpenJpeg rather than the paid (and very expensive) KDU library (which is supposedly a lot faster)
  18. Is walking around broken or did i miss something? Last time i checked you could walk around just fine and all basic functionality the LL Viewer offers worked too. What would make you say that?
  19. Ohwow. Does that mean my Snapshot window improvements finally come out of their grave?
  20. There is no gain for fullscreen and its an artifact of the past. Fullscreen Mode comes from a time where we had very limited hardware resources and games very frequently hit their limits, where every single bit counted. Having the OS take up a couple megabytes of your precious 128MB GPU memory was simply not good. Nowadays exclusive Fullscreen is just a waste of implementation, it serves no purpose with most anything frequently not even using most of your hardware resources, on top of that it is often buggy and very crashy because it requires the application to do full render refreshes when tabbing out which frequently crashes games (SL especially, which is why i heard it was removed in the first place). Do yourself a favor and ignore Fullscreen mode unless it is a borderless window (sometimes also called borderless fullscreen or windowed fullscreen) mode, borderless gives you the best of both worlds, full screen, no accidental clicking outside the app and the ease of tabbing out of the app without risking crashes.
  21. I think you are reading too much into the bad wording. You make it sound like this is solely and exclusively intended to be a copybot that functions in a grey area of LL's ToS and mangles definitions of things so much that LL doesn't see the copybot attempt. Also as i said before, whatever the secret intentions of OP is, what the actual thing does in the end is still up to the implementation, as long as it does exactly what its supposed to while not overstepping the TOS i see no issue here. And as long as it would be implemented as a simple action/timestamp history of what happened there is no way this could be used for anything malicious that the other viewers can't be used for either since the viewer would just play back said history requiring everything a normal viewer would do too (downloading and caching the assets, decoding textures etc)
  22. Nowhere do i see where she specified this to be done. It was specified that the message stream (action/packet history) would be recorded for later playback. I don't find anything being said of locally saving things.
  23. It doesn't at least implemented properly. This specifically is very important. You'd be recording a playback file, basically an action history of what happens when and where with what and who and play this back. As Henri said, you'd still be bound to what the Viewer does for the most part except there would be no more network traffic (which does improve performance a good bunch, see what happens when you Freeze Time). Since to be able to playback in the Viewer you'd still have to first download and prepare all needed content before being able to play it back there's at least some waiting time included before you can even do something. I'm not even sure if you could manipulate server communication in a way that you request certain things you are not somehow physically part of, such as the region. But putting the pre-requirements aside and assuming you can get the entire scene get prepared, you can have a viewer do such a playback although it would look exactly the same way it would look for any Viewer since all the packages you record are the same a client would receive, so if an object lags or jumps around, it will be recorded and played back like that unless you could manipulate that... but then we're stepping into possibly abusive territory.
×
×
  • Create New...