Feature Requests

Please check out the following guidelines before suggesting a feature! Off-topic posts will be deleted.
Update to the number of triangles in the performance ranks
Current problems Almost all avatars have a performance rank of "Very Poor," making it virtually impossible to block avatars based on their performance rank. This means that blocking based on polygon count or texture size, which directly impact performance, is currently impossible. While other blocking methods exist, such as blocking by download size or uncompressed size, these are insufficient alternatives as they are also affected by texture compression settings and the size of other assets. As a side note, because the performance ranking system is effectively non-functional and has no limitations, the polygon count of avatars and costumes sold on BOOTH seems to be increasing year after year without limit. Recently, commonly used avatars have approximately 150,000 tris, and costumes have approximately 200,000 tris. Request details I think the triangle count in the performance ranking system needs to be updated. Currently, all grades below "Good" have a uniform polygon count of 70,000. This limitation is a bit excessive for current hardware. https://creators.vrchat.com/avatars/avatar-performance-ranking-system/ Remarks I have conducted some (very simple) testing in the past. I believe that optimizing to under 300,000 tris is sufficient for instances like talking with a small number of friends, and under 70,000 tris for large instances like events. The testing was done with a single avatar, but I created a tool to ensure that each mesh is a separate asset for the testing. https://misskey.niri.la/notes/aggjg6jmjz I'll leave the final updated figures to the VRChat staff, but I have roughly the following figures in mind. Poor: 300,000 tris Medium: 150,000 tris Good: 70,000 tris Related posts https://feedback.vrchat.com/feature-requests/p/option-to-not-take-polygons-into-account-when-enabling-minimum-displayed-perform https://feedback.vrchat.com/feature-requests/p/client-side-polygon-limit-slider https://feedback.vrchat.com/feature-requests/p/avatar-polygon-limit-in-safety-settings https://feedback.vrchat.com/feature-requests/p/increase-the-polygon-limit-by-30k-for-medium-ranked-avatars-on-pc https://feedback.vrchat.com/avatar-30/p/incremental-triangle-limit-for-performance-rankings https://feedback.vrchat.com/feature-requests/p/add-performance-rank-that-exceeded-polygon-limit https://feedback.vrchat.com/feature-requests/p/performance-ranks-below-very-poor 日本語 / Japanese 現在の問題 ほとんど全てのアバターのパフォーマンスランクがVery Poorであるため、パフォーマンスランクを使用したアバターのブロックが事実上できない状態になっています。つまり現在は負荷に直結するポリゴン数やテクスチャサイズでのブロックが不可能です。他のブロック手段としてダウンロードサイズ、非圧縮サイズによるブロックも存在しますが、テクスチャの圧縮設定やテクスチャ以外のアセットサイズによっても変動するため代替とするには不十分です。 余談ですが、パフォーマンスランキングシステムが事実上機能しておらず制限も存在しないため、BOOTHで販売されているアバターや衣装のポリゴン数が年々際限なく増え続けているようです。最近よく使われているアバターのポリゴン数はおよそ15万ポリゴン、衣装はおよそ20万ポリゴンになっています。 リクエスト内容 パフォーマンスランキングシステムのトライアングル数をアップデートする必要があると思います。現在ではGood以下は一律7万ポリゴンです。この制限は現在のハードウェアにとっては少し過剰です。 備考 私は過去に(非常に単純な)検証を行いました。少人数のフレンドと会話するようなインスタンスでは30万ポリゴン以下、イベントなどの大人数インスタンスでは7万ポリゴン以下を目安に最適化すれば十分であると考えています。検証は単一のアバターで行われていますが、メッシュはそれぞれ別アセットになるようにツールを作成して検証しています。 https://misskey.niri.la/notes/aggjg6jmjz 更新後の数値の決定はVRChatのスタッフにおまかせしますが、私は大まかに以下の数値をイメージしています。 Poor: 300,000 tris Medium: 150,000 tris Good: 70,000 tris 関連する投稿 https://feedback.vrchat.com/feature-requests/p/option-to-not-take-polygons-into-account-when-enabling-minimum-displayed-perform https://feedback.vrchat.com/feature-requests/p/client-side-polygon-limit-slider https://feedback.vrchat.com/feature-requests/p/avatar-polygon-limit-in-safety-settings https://feedback.vrchat.com/feature-requests/p/increase-the-polygon-limit-by-30k-for-medium-ranked-avatars-on-pc https://feedback.vrchat.com/avatar-30/p/incremental-triangle-limit-for-performance-rankings https://feedback.vrchat.com/feature-requests/p/add-performance-rank-that-exceeded-polygon-limit https://feedback.vrchat.com/feature-requests/p/performance-ranks-below-very-poor
28
The photo to print correctly even if it’s taken with the image flipped left to right.
◆Current problems Please fix the issue where, if I take a photo while the camera screen is flipped left to right, the resulting image is also saved with the image flipped left to right. ◆Details of the Problem If you press the button in the upper-left corner of the camera to switch to selfie mode, the camera screen will flipped left to right. If you take a photo in this state, the resulting image will also be output with the image flipped left to right. When taking photos in VRChat, I often use selfie mode because I’m usually taking pictures of myself or myself and my friends. If the photos you’ve taken of yourself or your friends didn’t turn out well, you’ll need to use photo editing software to fix them. Since many VRChat users are particular about their avatars' appearance, it's preferable to take phots without flipping the image horizontally. ◆Request details I would like a feature that prevents the image from being flipped horizontally in selfie mode, or one that automatically corrects the horizontal flip when the image is exported. ◆Related posts https://feedback.vrchat.com/bug-reports/p/about-inverting-the-saved-image-when-taking-a-selfie-with-the-camera ◎日本語 カメラ画面が左右反転している状態で撮っても出力された写真は左右反転していない状態で保存してほしい ◆現在の問題 カメラ画面が左右反転している状態で写真を撮ると、保存された画像も左右反転してしまう問題を修正してください。 ◆問題の詳細について カメラ画面の左上にあるボタンを押して自撮りモードに切り替えると、画面が左右反転します。この状態で写真を撮ると、撮影された画像も左右反転した状態で出力されます。 VRChatで写真を撮るときは、自分や自分と友達と一緒の写真を撮ることが多いので、よく自撮りモードを使います。 自分や友人の写真を撮った画像が左右反転していた場合、ペイントソフトなどで修正することになります。 VRChatのユーザーの多くはアバターの外見にこだわりがあるため、写真を撮影する際は画像を左右反転させない方が望ましいです。 ◆リクエスト内容 自撮りモードで画像が左右反転しないようにする機能、あるいは画像をエクスポートする際に自動的に左右反転を修正する機能を追加してほしいです。 ◆関連する投稿 https://feedback.vrchat.com/bug-reports/p/about-inverting-the-saved-image-when-taking-a-selfie-with-the-camera
3
Create a new version of VRCStation
VRCStation needs an alternative for many reasons. Here are some: Too many issues with the introduction of every new feature. Too many undocumented behaviors which seem to change from (client) update to update. Full of difficult-to-reproduce, obscure bugs that are much too time-consuming to debug for more casual creators. Excessively sensitive to implementation and usage factors to the point of total absurdity (Try putting an Udon behavior on the same object as a Station and writing to another Udon behavior's variable.) Changes behavior based on the number of people in a world. (I've seen this several times and it breaks the game.) It doesn't even know which player is sitting in it. Solutions to some Station issues are already in the SDK but not implemented apparently such as the animator fix for full body tracking which exists in the Avatar SDK but is missing in the World SDK. In practice, UDON Solutions and workarounds to VRCStation issues can work less effectively over time, demanding constant maintenance and causing worlds to stop working entirely. PROPOSAL: Because numerous existing worlds currently make (hard fought) use of VRCStation's quirks for actual features, you can't simply get rid of it, as this would break a huge number of very cool worlds. Instead of re-engineering the existing VRCStation (nobody wants that!), Create a brand new VRCStation alternative and creators may choose between the two (an extremely worthwhile choice to present compared to the alternative of not fixing anything). This new VRCStation2 should have the following: The Player must never be misplaced or "thrown" because of playspace origin or other factors separate from and totally irrelevant to the transform of their head. Players must always be positioned where they are expected to be at all costs even if it hits the frames a little to correct it (because the UDON acrobatics we have to do to make this happen without this assurance are going to hit frames harder anyway. Nothing is being saved by doing this quickly but incorrectly. I cannot stress enough how important this is.) The Station must have a public variable or method by which to get the VRCPlayerApi object of the player seated. The Station must be movable by any mechanism by which a GameObject can be moved (Animation, RigidBody, updating the value of the transform position/rotation), with no exceptions or conditions. Usage of this must be as simple as possible with no hidden/undocumented behaviors. The Station must not immobilize the arms of a player by default. In practice, players are expected to be able to interact with things with their arms when seated so it would never make sense for this to happen without the world dev explicitly specifying it. The Station must have a facility for player exit by calling a method on it/sending an event. This is imperative for ergonomics and feature-rich worlds. The Station must have the ability to NOT restrict FBT movement, as this is widely used by many players and there are entire forms of emergent gameplay and experiences which depend on this. There is currently a community workaround for this, don't break it. Stations should be able to sync their positions relative to their host GameObject. If a player is adjusting their seat, their position should be synced because without it, players don't know where each others heads are and this interferes with social interaction. It is unreasonable to require a world dev to have to crack into Networking in order to sync the position of seats because Networking is among the most difficult parts of UDON and most world creators will just skip it if this syncing isn't included in the component (and you can't really blame them, some people just want to casually make a room with a couch or something and don't have time to learn Networking). Stations should orient the player to match the Up direction of the Station's local transform, and NOT the Up direction of the world. The current implementation which orients to world's up creates a huge amount of nauseating misalignments where players end up sideways in a seat because it's on a vehicle, if the vehicle isn't completely flat, and in-practice it is absurd to ask players to only enter a vehicle when it's on flat ground. This might be a lot of things, and in general with some exceptions, it matches the functionality of VRCStation, but the key is that the new one needs to prioritize expected behaviors and cannot have the entropic "decay" in reliability exhibited by the current one. I have spent many hours trying to drag VRCStation into doing exactly what it's supposed to do, entirely because I needed to get events from it or any myriad of other various ways it can find a reason not to work right. This component's vagaries have even evaded the skills of friends that are far better at this kind of thing than I am. This component is a disaster and it's only getting worse with time. Surely, I can't be the only one who is at the end of their patience and resources in dealing with VRCStation. So please, for the sake of future world development and the health of the platform, please consider creating an alternative to the existing VRCStation component. Thank you.
18
EAC Blocks VMs Conflicting With VRChat's Statements Not Caring If People Use VMs
To be clear this is not asking for support, this is asking to configure EAC to not run it's VM detection at all. EAC can still run the same as it has and the security it provides is not changed. This will remove the Epic VM whitelist/exclusive special sauce for allowed VMs (to my knowledge only GeforceNow), and allow VM users such as ShadowPC and regular end-users to play in a VM without workaround s or custom patches to VM host software or guest software. This is not new but since EAC has been deployed it has been configured to block execution from within a VM. The current workarounds in the wiki do not presently work as of around the middle of January this year, and even at the time prove that EAC was attempting to block VMs, as it was looking for common VM smbios values to block the execution in conflict with VRChat's previous statements that they do not care if an end-user runs a VM or not. How it presently is trying to detect a VM I do not know exactly but I can tell that the methods to get VRChat to work solely with VM config tweaks do reduce performance and are windows guest exclusive: 1)Run with the hypervisor CPU extension disabled. (small performance loss) 2)run windows with the hyper-v platform enabled after ensuring the vendor virtualization cpu extension (SVM AMD/ VMX INTEL) is enabled. (massive performance loss) It is possible to configure EAC to not block VMs, all Fromsoft titles I have (Armored Core, Elden Ring, Nightreign) that include EAC run in a VM fine with no workarounds on both Windows and Linux. Tupper Promised to read this at a minimum :) (please and thank you)
19
Load More