Next major priority survey - IK or Performance
Added 2024-05-21 19:50:28 +0000 UTCWith the Settings UI update implemented, we are now considering what is the next major project for Resonite. Our original plan was to rework the IK system, but after re-evaluating the current state of the platform, we feel that we might consider another goal: major performance improvements.
We’d like to ask you, the community - both new, old, both regulars and everyone watching Resonite from afar - what is most important to you, to help us make the decision on the path forward.
We will keep this survey open until June 4th, because we want to give you enough time to read through it, digest it, discuss it with your friends and community before submitting answers. We will send a reminder two days before it closes.
Our current focus is on smaller bug fixes and additions. We will give you, the community, sufficient time to provide feedback before making a decision on which of these major updates will happen first and which one will be done after that.
You can also ask us questions about these priorities here: https://github.com/Yellow-Dog-Man/Resonite-Issues/discussions/2066
Anyway, thanks all for now! Thank you for your time reading this and filling it out, it will help us a lot to know where it's best to direct our focus to make most impact and help this platform grow and make it more enjoyable!
Comments
performance. even tho my pc isn't top of the line, it's still pretty high performance, but still struggles a lil w resonite, sumtimes. i can only imagine what the ppl w potato rigs r going thru!
Atticus-023
2024-06-05 06:07:34 +0000 UTCPerformance
Antonio
2024-06-02 07:05:36 +0000 UTCPerformance and add "tab" to next fields
neooen419
2024-06-01 18:03:03 +0000 UTCPerformance
bndkllr2
2024-06-01 02:16:54 +0000 UTCId say performance
Zach Randolph
2024-05-24 16:44:07 +0000 UTCfrom my experiences Ive always stuck to modern c++ over .net for a lot of those reasons you have mentioned but that requires a lot more code to achieve the same levels of function, however I compare OpenGL as .net and Vulkan as c++ the extra work is worth the performance gains alone. the amount of code to fully initialize OpenGL is around 30 lines, the same for Vulkan is 1000 lines. Many wrappers have been written to handle the tedious side of that if it is not something you want to tackle and once it is done and you have your render pipeline done the rest of the calls are no more complex then the calls from OpenGL. You say it is a complex process but a single person can code a Vulkan render engine in less then a month if they work on it from standard 9-5 hours taking it easy. Sure garbage collection and other more complicated will take longer but they in themselves can be completed fairly quickly if one puts there head to the grindstone. But I know it can be done because I've done it myself. Yes OpenGL is old but its been well maintained by all the card manufacturers for years and Opengl would infact not be a reduction in performance if it gets you away from your .net complexity even as a temporary means to fix things, Sometimes you have to take a step back before you can take a step forward. Also conversion of OpenGL to Vulkan is a fairly easy process. I have been writing video games since 1992 and game engines since 1996 and currently work as a teacher and consultant to studios. I am well aware you are looking through different engine choices to find what might best work for your project however since youve gone the route of writing everything on a seperate layer from any exisiting game engine to me the logical conclusion is you shouldn't try and take the "easy path" and should simply write your own render pipeline and garbage collection, schemes, etc. Id rather see this project succeed because it was done right from the second start? rathern then watch as you struggle with integration/interfacing of other peoples engine code when you could implement your own and get solid ground under you. Your going to take what ever path you feel is right for you however and thats ok, I would just like to see this project succeed as best as it can.
Zero
2024-05-23 21:20:21 +0000 UTCWe are also working on switching away from Unity completely to a more modern render pipeline, which will utilize Vulkan and provide significantly better rendering performance and capabilities. However this is a much bigger project and it will take longer before it's completed. The main goal of render pipeline switch isn't to address the hitching either - the rendering pipeline isn't the source of the hitching. We will not be using OpenGL for the new project - in fact this would be a bad choice and lead to more performance problems. Notably OpenGL, similarly to DirectX11 and other older API's aren't very well designed for multi-threaded and asynchronous interactions, as Vulkan or DX12 are, so switching to those would not help at all.
Yellow Dog Man Studios
2024-05-23 17:19:23 +0000 UTCIt's a complicated problem. One of the sources of hitching during asset loading is the GC (garbage collector). Asset loading causes heavy memory allocations, which triggers the GC to run. The GC used in Unity (which we don't have control over) is very primitive and it will at times freeze the entire process to scan the entire memory, even if very little memory can be freed. Switching to modern .NET runtime will mostly get rid of this source of hitching, because the memory management and GC are far superior and more efficient. It's actually a case where the asset loading being decoupled and multi-threaded makes things worse in some regards, because the Mono + GC aren't able to handle with that load too well - which is one of the reasons we want to switch away. There are certain other sources too, particularly for some mesh data, where the upload of the loaded data (which was done asynchronously) to the GPU must be synchronized with render thread - this is a limitation of Unity & DirectX 11, with potential workaround by implementing custom upload & timeslicing like we have for texture data.
Yellow Dog Man Studios
2024-05-23 17:15:44 +0000 UTCJust a point of clarification - we don't expect the performance improvements to have any effect on the LibVLC integration, that's fully independent of this. However the rest we do expect to be heavily improved by it - bigger meets and better accessibility to hardware.
Yellow Dog Man Studios
2024-05-23 17:10:22 +0000 UTCAgreed. It should not be happening and it needs to be addressed. Just imagine moving through a game world and having your game freeze every time you hit an asset load point where data is being removed and added. It would be unplayable. While vr takes a frame hit for rendering left / right displays and the higher peek resolution of modern headsets, there is no reason asset management and core functions should be hitching the render side. If your issue is because of the way your choosing to interface to unity then you should either find a better way or write your own render pipeline, Hell at our current performance point and with our curret set of shaders it could easily be done in opengl if your team does not have the skillsets to handle modern API's such as Vulkan/DX12 in short order and easily match up with current levels. Freezing and Stuttering and all the current graphical issues we are having are driving players away and need to be addressed.
Zero
2024-05-23 00:42:46 +0000 UTCSubstantial hitching occurs on new players joining and even opening inspectors at times. If asset loading is decoupled, that freeze shouldn't be happening, right? The latter isn't even loading substantial elements for display, just thousands of textual elements and relevant data.
Taerlyn
2024-05-23 00:22:21 +0000 UTCWe have some updates for this in progress, but those aren't considered major focuses, so they're things that can be done as smaller things in parallel from these two major issues.
Yellow Dog Man Studios
2024-05-22 18:35:30 +0000 UTCNetwork performance, especially for those who can easily desync with high ping due to physical location.
Meow Wei
2024-05-22 16:26:51 +0000 UTCThen what is it specificaly that is hitching the render pipeline? networking? Hard freezing when loading in new assets is a bit on the bad side in a modern engine application. There are several ways to handle data between the renderer and the engine. I have no issues with my own vulkan based engine in this regard loading far more data over a short order between ram and video memory.
Zero
2024-05-22 10:10:17 +0000 UTCThe performance is awful and in my case has seemingly deteriorated over time. My game struggles to reach above 20 frames in vr & is unplayable for me. The IK is passable but make the game run good before prioritising the IK.
Louish
2024-05-22 08:10:41 +0000 UTCFilled it out! Honestly, even though I can run Resonite just fine most of the time and head based IK would be great, performance for other players is a much bigger issue, so I would say that. IK can come later.
Nat Osaka
2024-05-22 06:08:36 +0000 UTCIf you can, ask those people to fill out the survey, because that will help show it in the data.
Yellow Dog Man Studios
2024-05-22 03:05:01 +0000 UTCDefinitely IK. Its the main reason why most people I know wont touch Resonite. Its really hard to get over your avi not feeling right when you're used to it being solid 99% of the time.
Wynn
2024-05-22 02:38:03 +0000 UTCI would choose Performance as it allows more room for creativity with really big projects. ^-^
Joshtiger
2024-05-22 02:03:43 +0000 UTCFair point. I read a bit too quick while at work and was excited. Still stand by performance being a bigger focus as while IK is nice, performance has a much more positive benefit and boost to users across the board. Appreciate the clarification though and pointing out my missed reading lol.
SugrStrz
2024-05-22 01:59:14 +0000 UTCAssets are already loaded separately from the render pipeline for the most part. The only part that needs to be synchronized with the render pipeline is the upload of loaded data to the GPU, which is timesliced, so it shouldn't impact performance strongly. Making that fully asynchronous isn't possible with Unity and DirectX11 because of how these work, so that specifically won't be addressed as part of the performance work.
Yellow Dog Man Studios
2024-05-22 01:56:42 +0000 UTCWe specifically state in the survey that IK work will NOT impact performance in any significant way. IK will take a good chunk of time to handle and will not improve performance. We strongly recommend reading the rest of the survey text, because it goes into detail on what will each work involve and not involve.
Yellow Dog Man Studios
2024-05-22 01:54:44 +0000 UTCPerformance would be great but IK Im sure can actively impact performance so they may not be so difference. If IK doesnt take too long to handle, IK but Performance first in all other instances.
SugrStrz
2024-05-22 01:24:22 +0000 UTCIK First since Performance for everything would have to be done after either or.
RedStar Hunter
2024-05-21 23:28:06 +0000 UTCIk love ik
fragilegirl
2024-05-21 23:25:10 +0000 UTCPerfomance would be very helpful.
Carlos Austin
2024-05-21 22:38:51 +0000 UTCWhile i personally see the ik and dynamic bones as the main "features" VRC has over Resonite, those are at a stage where improvements would be nice to have. Yes, a major complaint for new users is getting their avatars set up, but something that 100% keeps people from coming back, at a much broader scale, is performance. There are so many meets that cannot happen on Resonite due to inability to scale session size, so many users i know who would love to play more but literally cannot due to it just being too hard on their hardware. I appreciate the poll but quite frankly i think this is a case where there is in fact a right and wrong answer. Even more so since the changes made for performance improvements would have cascading effects on other areas, like being able to update libvlc, another major pain point for me personally
zangooseOO
2024-05-21 22:38:23 +0000 UTCperformance please... your already using a mainstream IK library, client side performance and optimizations as much as you can do with a .net platform will also improve IK responsiveness. More core utilization and seperating the render pipeline from loading assets would make resonite run a lot smoother and reduce hitching.
Zero
2024-05-21 22:19:19 +0000 UTCPerformance. There are friends I can no longer interact with on reso because they can't get framerates outside of single digits.
dn puǝ sıɥʇ
2024-05-21 21:29:23 +0000 UTCAs someone with a lower-performance computer, performance would be appreciated.
SteelTheWarrior
2024-05-21 20:58:04 +0000 UTCPerformance. IK could be better but performance actively inhibits large gatherings. I'd say prioritize the thing impacting user behavior over nice to haves.
Taerlyn
2024-05-21 20:44:21 +0000 UTCPerformance please, the data model rework would help greatly and make Reso accessible to more folks (maybe even cross continent). IK is fine as it is right now and the folks doing wacky IK stuff are already pretty talented (most folks are fine with just being a simple bipedal, two armed avatar).
LorneChrones
2024-05-21 20:27:45 +0000 UTCI would say IK is a better option for now. As for fbt as it keeps us on more and not hate the ik that is now. It is good don't get me rong but after 7 months I would like a Ik overhaul
LunaryEclipse
2024-05-21 20:26:23 +0000 UTCI think performance is the way to go, get more people onto the platform and playing more often maybe, improving general accessibility over QOL for one specific aspect of the game, though I do understand its been a long time coming for many users here.
Void_Sentient
2024-05-21 20:12:36 +0000 UTCI’m all for better IK above anything
CJAY SEVEN
2024-05-21 20:11:20 +0000 UTCPerformance, please! I've been struggling with running resonate for so long, it's genuinely the main reason I don't play as often as I want to
LiteLotus
2024-05-21 20:01:03 +0000 UTCI would say IK. If VRChat has proven anything, it's that modern social VR users are way more tolerant of suboptimal performance than of any immersion-breaking that occurs to bad limb placement.
fluffy
2024-05-21 19:55:24 +0000 UTCPeople had been eating up the current performance as is, IK would please more people in the long run
Plaster
2024-05-21 19:52:52 +0000 UTC
