edited April 4 in ORK Support
Hello, is it possible to add a Virtual List feature?
For example: I currently have a large number of items in my backpack and if Virtual List is not applied then k jams will occur
For example: I need to display the battle log and not empty it, if I render too much text it will lag, but if I use Virtual List it won't cause this problem.


I don't know if ork3 already has this feature?
I don't think so, as I haven't found any zhi'liao on it.


There is a virtual list plugin in the shop, but I'm not sure how to integrate it into Ork, in fact, there are many parts of Ork that I'm not sure I understand in terms of UI.


er, [virtual list], which means, roughly, Scroll View, can handle a large number of items without lagging, or very laggy if not optimised

Of course, this is only a not very important requirement, so if you don't have this update planned, hopefully you can add it.

Post edited by ranwang520 on
  • I believe what you're referring to is a Recyclable Scroll Rect. I too feel Ork would be better if support for it was implemented. @gamingislove Is it possible to build some type of add on or does it not work with Ork Menus at a fundamental level?
  • Well, the Unity UI module simply uses ... Unity UI - you can simply set it up the way you need it and extend it with custom components.

    Built-in support for non-standard Unity features isn't possible.
    Please consider rating/reviewing my products on the Asset Store (hopefully positively), as that helps tremendously with getting found.
    If you're enjoying my products, updates and support, please consider supporting me on patreon.com!
  • I think the main issue with poolable/recyclable scroll rects is that they require a data class for each possible scroll rect so it knows which data to assign to it's pooled prefabs. So you'd need one for inventory that has the Image, HUD Content, Provided, Status Value, etc. but then Equipment would need an Equipment Status instead, etc.

    I'm not sure how you could implement this in a generic way in the engine, without using reflection to find the given scroll rect data as each time you call a UI box using it. I also don't know nearly anything about reflection and consider it magic :)

    Something I think might work as a hacky workaround would be to implement it as you would thru script, but then add an Awake/Start method on your "Custom Input Prefab" that takes all of the necessary information, finds the parent scroll rect and calls the appropriate information adding, and then deletes itself.

    You'll still have to create a custom data class containing every piece of information and you'll get a worse upfront loading cost since the button will be created and then deleted, but then in theory, the recyclable scroll rect component should have the necessary information and can start recycling/poling the contents.
  • @Acissathar
    Ah, that seems like a lot of work for potentially little pay out. But I'm simultaneously curious if the theory will work in practice.
  • edited April 5
    0.0 .... I find this feature very important at the moment, as Rpg games, especially on mobile, can only display 20 items in the window if they render hundreds of items at any given time, which results in very low Fps.


    I've looked at a few plugins that do something similar to what I'm talking about, and they are all based on UGUI, but I feel like it would be possible to do this with Ork, but of course I'm very new to the Ork UI source code.


    Maybe this will be a pain ......


    Still hoping Jill will investigate and hopefully have something similar

    Post edited by ranwang520 on
  • I would also like to extend ...... with my own hands
    er ......
    My coding skills are very poor, so I'll have to rely on you to add similar functionality.

    Of course, this is still within the scope of your planned update, and as I said at the beginning, it's not 100% necessary for this feature
  • edited April 5
    @ranwang520 I don't have mobile to test, but a few things you can try that are codeless possible performance improvements for scroll rects:

    1. Using ORK's Layout and Canvas settings, set any UI boxes that will be scroll rects onto their own Canvas. Whenever the scroll rect moves, the entire canvas is marked dirty and redrawn so the less extra elements you need to redraw, the better.

    2. Disable Pixel Perfect rendering on said Canvas.

    3. Use a RectMask2D instead of Mask on the Viewport game object.

    4. Remove any Layout Elements or Layout Groups on the objects in the Content. This would be best done by using Custom Input Prefabs for your scroll view buttons, and ensuring each is set to the correct size and spacing that you want instantiated.

    Whether these make a big enough difference I'm not sure, but they are all possible optimizations you can give a shot.

    @Dre788 I plan on finding sometime this week to give it a shot in one of the demo projects and see if it makes a difference (on either end). There's also a more slimmed down generic scroll rect that doesn't need anything special done beyond just swapping the component on the UI Box I'd like to test against too. I'll share the results I find with them.
    Post edited by Acissathar on
  • Well, ORK allows you to predefine inputs and add them to your UI box prefab.
    Also, UI boxes keep spawned input prefabs pooled for reuse.
    Please consider rating/reviewing my products on the Asset Store (hopefully positively), as that helps tremendously with getting found.
    If you're enjoying my products, updates and support, please consider supporting me on patreon.com!
  • I think the issue is when you start getting into triple digit (or double on mobile I suppose) or more items, because Unity is rendering a gameobject for every single UI element in that scroll rect. The Atelier jrpg series for example is all about crafting, so you end up having pretty huge inventories without stacking items as each crafting item component can have different traits, quality levels, etc. (I currently have just over 6600 items in Ryza 3 for example)

    Keeping those as Unity (and by extension ORK) default scroll rect means that you keep all of those UI objects loaded, active, and in memory, rather than just pooling over the 30 or so that actually display at any given time. If you remove the Mask component you'll just see the entire list cover the screen haha. Apparently this is not a problem with the new UI toolkit using List View, but afaik UI Toolkit is still in preview anyways?

    I totally understand this would probably be a hassle to implement as a normal feature set, and would likely require user knowledge to create each data class for the different lists, so maybe a candidate for a group commission?

    But given all of that, here are my extremely non-scientific test runs (note that all avg ms stats include the basic 3D Quick Start game running at ~3.3ms as part of their average):

    Built-in UI
    Items 10 100 1000 10000
    Time to open 0.40s 0.80s 3.61s 2m23s
    Avg ms static 3.4ms 4.3ms 16.6ms 43.6ms
    Avg ms moving 3.5ms 4.5ms 17.7ms 165.2ms

    Then, using https://github.com/ParkingLotGames/Recyclable-Scroll-Rect:
    Recyclable Scroll
    Items 10 100 1000 10000
    Time to open 0.40s 0.43s 0.44s 0.41s
    Avg ms static 3.3ms 3.4ms 3.3ms 3.4ms
    Avg ms moving 3.5ms 3.7ms 4.0ms 4.1ms
  • @Acissathar
    That's one heck of a different. This was set up displaying Ork data correct? How did you implement it? I would like to see it in action.
  • @Dre788 Not directly interfaced with ORK populated buttons no, this was more a Unity Scroll Rect vs Recycable Scroll Rect test, hence the extremely non-scientific disclaimer :)

    The current way ORK appears to handle these UI boxes is to instantiate the children directly in the Content, which I can't directly hook and prevent, without implementing it all the way into the source.

    My methodology was to use ORK to open a UI box (to measure open time) with the child objects containing the respective ScrollRect populated with buttons using image, text, etc. Both the Unity ScrollRect and RecyclableScrollRect used the same set of data, so it wasn't ORK data vs Non-ORK data for what it's worth.

    The main hangup is the hundreds/thousands of gameobjects with RectTransform components coupled with having to constantly be updated due to a dirty canvas.
  • edited April 6
    Ah, well I appreciate the effort. It seems the best method to counter the potential menu build up is to limit the number of items in game.
    Post edited by Dre788 on
  • @Acissathar


    Hmm ...... So, Ork3, there is actually a way to solve the lag caused by too many Items?

  • @ranwang520
    The best method is to just limit the quantity of items the player can have in their inventory at any given time. In Inventory Settings->Space Limit set the value to 100 or 50, or whatever number that will stop the lag. You will just have to design your project around that limit.

    Another option is to use multiple windows of smaller chucks of item (10, 20, 30) and separate the items by type. Again, you'll be designing your game around the limit.
Sign In or Register to comment.