Yellow Dog Man Studios patreon

Next major priority survey - IK or Performance

🕑 Added 2024-05-21 19:50:28 +0000 UTC

Comments

Atticus-023

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!

Antonio

Performance

neooen419

Performance and add "tab" to next fields

bndkllr2

Performance

Zach Randolph

Id say performance

Zero

from 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.

Yellow Dog Man Studios

We 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

It'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

Just 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.

Zero

Agreed. 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.

Taerlyn

Substantial 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.

Yellow Dog Man Studios

We 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.

Meow Wei

Network performance, especially for those who can easily desync with high ping due to physical location.

Zero

Then 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.

Louish

The 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.

Nat Osaka

Filled 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.

Yellow Dog Man Studios

If you can, ask those people to fill out the survey, because that will help show it in the data.

Wynn

Definitely 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.

Joshtiger

I would choose Performance as it allows more room for creativity with really big projects. ^-^

SugrStrz

Fair 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.

Yellow Dog Man Studios

Assets 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

We 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.

SugrStrz

Performance 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.

RedStar Hunter

IK First since Performance for everything would have to be done after either or.

fragilegirl

Ik love ik

Carlos Austin

Perfomance would be very helpful.

zangooseOO

While 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

Zero

performance 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.

dn puǝ sıɥʇ

Performance. There are friends I can no longer interact with on reso because they can't get framerates outside of single digits.

SteelTheWarrior

As someone with a lower-performance computer, performance would be appreciated.

Taerlyn

Performance. IK could be better but performance actively inhibits large gatherings. I'd say prioritize the thing impacting user behavior over nice to haves.

LorneChrones

Performance 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).

LunaryEclipse

I 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

Void_Sentient

I 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.

CJAY SEVEN

I’m all for better IK above anything

LiteLotus

Performance, 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

fluffy

I 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.