I’ve been working on a project and we’ve been having trouble implementing a 3D spatial inventory system. I’ve figured out how to create a 2D inventory system based off of this tutorial series Spatial Inventory Tutorial But I’m having difficulty translating this to a 3D inventory. My current work around is to spawn on the inventory items into the player inventory using a series of box collisions as a grid. However, I’m having issues with trying to get the meshes to be centered in the grid spaces they should occupy.
For example, if I have a flashlight item that should take up 2 horizontal grid spaces and 1 vertical space it instead will overlap into 2 vertical spaces or only take up 1 and a half horizontal spaces.
If anyone has an idea to fix this please let me know, or if you have a better implementation for a 3d inventory it would be a massive help.
If anyone is wondering, I’ve been continuing to work on this and almost have it working. I’ve got 3d meshes spawning within a grid on a player inventory box. I’m working on getting menu interaction setup to allow for movement of items and equipping items. If anyone has some ideas I’m still keen to hear them.
The project I did the inventory on is under an NDA, but I’ll put together some new code here soon and post it. It is a total of hundreds of lines of code though so I’m wondering if it would be better to put together a video going over step by step implementation.
I can try to give some rough details here. So, I had actually solved the inventory back in January of this year. That version mostly used the same idea and principle from the grid based inventory video I referenced in my initial post. Since then though I have been reworking the inventory.
I say that to say that video is still relevant to how I achieved it but its become less relevant with my current rework of the inventory.
In the new inventory Data for each object type is stored in a Data Asset. It could be stored in a Data table as well, but for the game I made the inventory system for Data Assets was the better option. The corresponding data is pulled and used by an “InventoryItem” class that is the physical representation of the item in your inventory. (It also holds user-changed/dynamic data as well since data assets cannot). In the old inventory it used child classes of a master item class to store the data for each item.
The new system adds items based on grid size availability and the grid size requirement of the given item. This is stored in the data asset corresponding to that item. If there is room available the given inventory. Removing the item is done by clicking on the physical representation of the item (InventoryItem class) and moving the item outside of the inventory grid. This spawns in the item and removes it from the inventory.
Saving the data is pretty easy to do. Each InventoryItem class has a custom Ustruct that holds all relevant information to that item (Data Asset to use, customizable/dynamic data, position in grid, etc.) When saving the game it creates an array and adds that struct data to the array for each item. When loading it does have to spawn in the inventoryItems and assign the appropriate struct information for each item. The spawning was significantly slower in the older system I did. Tahnks to the new system using data assets its much faster to get the required data and display the objects appropriately.
Sorting was not something needed for the game I developed this system for, but it could be added in fairly easily. Essentially whatever sort order you are trying to perform (Name, Type, etc) you would create a temporary array of all items and rearrange them to match that order. Then you use that array to remove and re-add those items into the inventory grid. Another option could be to go through the grid size and grid requirements of each item and calculate the correct grid positions for each of the existing items and just change those values in the original inventory. Most likely that method would be more performative, but take some careful math considerations. In my opinion the performance gain from that method would be negligible enough it likely isn’t worth it for most games.
I apologize I don’t know quite what you mean by constraints? If you mean limitations of this system then I think the biggest limitation is performance. Because each inventoryitem has to have a physical mesh to represent it, it will always be more resource intensive than a lot of inventory systems. Because of that I wouldn’t recommend this for a game where you may be collecting hundreds or even thousands of items. I experimented simply adding in static mesh components rather than a new actor to the inventory system but in my case this only slowed performance. You could possibly reconstruct one solid static mesh to represent the full inventory grid and then remove and add to that mesh as needed. However, after a lot of my own experimentation with procedural meshes and procedural skeletal meshes I wouldn’t recommend that.
I hope that helps and I’ll try to get something together to go into more detail at some point.
Yes, so these constraints are setup within the data asset for each item. My older system was limited to 1 per slot, but the new system can take multiple per slot. There is a relative offset value stored as well that is used for some items to reposition meshes as needed or stack the meshes depending on the value. Alternatively each stack size could be represented as a different mesh and stored in separate data asset values.
At this time I have not tried with ISM in the game under NDA. My other tasks were given a higher priority but I suspect that could help with performance as well although probably only marginally. Most experimentation I’ve done with ISM tends to only make a noticeable difference when you are dealing with 50+ meshes. The inventory system could have that many items depending on your setup, but in this game it typically only has 8-12. I will probably explore that option when putting together something to cover this. It will probably still be more performant to use individual actors to represent the items than adding several instanced meshes to the inventory itself. Given how Unreal can be with components. If you try it out and get different results, I’d love to hear about it though
