[1.15.2] Questions regarding dynamically-generated GUIs

[Blazer Nitrox]

Okay, so admittedly this is a really complex thing I'm trying to do, but I figure I'd learn some things along the way, so I decided to give it a shot.

My goal is to recreate something like a skill tree in Minecraft. Specifically, my inspiration comes from the Passive Skill Tree in Path of Exile. I definitely do NOT expect to replicate the kind of complexity they've got, as the skill tree has evolved over the course of many years.
I've (mostly) figured out my implementation for the skill tree, and now I need to have a GUI allowing the player to actually allocate their skill points. This, unfortunately, seems to be much harder than the tree implementation itself, while also being extremely important to using the tree (I suppose I could implement the whole thing using commands, but I'm going to have to create a GUI at some point so I might as well ask now).

Currently, I'm trying to future-proof by using a custom registry for my SkillNodes. While this will allow me to easily add nodes programmatically (and will allow other mods to expand upon the skill tree), it also means that I have no way of knowing what nodes will need to be drawn to the tree at compile time, so I have to dynamically generate the GUI. I likewise have no way of knowing what positions I will need to draw the nodes' textures at, which means I won't know until runtime how long I will need to make the paths between each node.

So, here are my questions:
1.  I expect I will need to take advantage of Minecraft's built-in texture stitching, that way I don't have to rebind the texture every time I draw a node. Near as I can tell, there is no built-in GUI TextureAtlas, so I would need to create my own. How would I go about doing that, and would it need to be registered somewhere in order to still fire TextureStitchEvents?
2a.  Since I also don't know each node's position until runtime, I will need to dynamically draw the paths between them, which means I won't know the lengths of each path and therefore can't just draw a texture 1:1 between each node.

2b. I would like to make the paths straight lines between each node, which means I could potentially be dealing with diagonals as well. Can  `Screen` handle either of these scenarios, or would I need to directly access OpenGL?

 

This situation is something I'm not very experienced with at all, so please bear with me. I'll probably be asking several more questions to make sure I understand what I need to do here.

And as I said, I know I'm probably biting off more than I can chew, but I find that I learn best by bodging a solution together at first and then rewriting it with the knowledge I gained.

 

 

[DavidM]

43 minutes ago, Blazer Nitrox said:

While this will allow me to easily add nodes programmatically (and will allow other mods to expand upon the skill tree), it also means that I have no way of knowing what nodes will need to be drawn to the tree at compile time, so I have to dynamically generate the GUI. I likewise have no way of knowing what positions I will need to draw the nodes' textures at, which means I won't know until runtime how long I will need to make the paths between each node.

You could specify the position of the node as part of its data, which should be part of the instance you use as the registry entry, and draw each node according to its position data. This allows you (as well as other mods that use your mod) to have more control over where the newly added nodes should appear. This also circumvents the "dynamically position the node and draw line between" problem.

 

43 minutes ago, Blazer Nitrox said:

2a.  Since I also don't know each node's position until runtime, I will need to dynamically draw the paths between them, which means I won't know the lengths of each path and therefore can't just draw a texture 1:1 between each node.

2b. I would like to make the paths straight lines between each node, which means I could potentially be dealing with diagonals as well. Can  `Screen` handle either of these scenarios, or would I need to directly access OpenGL?

Directly using OpenGL should be the easier approach, as it has more flexibility (and Screen uses OpenGL anyways). Create a texture of a line and scale/rotate it to point it to other nodes. Some trigonometry will be needed.

Edited May 27, 2020 by DavidM

[Blazer Nitrox]

29 minutes ago, DavidM said:

You could specify the position of the node as part of its data, which should be part of the instance you use as the registry entry, and draw each node according to its position data. This allows you (as well as other mods that use your mod) to have more control over where the newly added nodes should appear. This also circumvents the "dynamically position the node and draw line between" problem.

That's what I'm doing, sorry I didn't make that clear. As part of the node's data I've got the position and the resource location for the appropriate texture. My main concern was that since I won't know where the node will be located until it gets registered I can't just include the path as part of the background texture, so I would have to dynamically draw it.

 

32 minutes ago, DavidM said:

Directly using OpenGL should be the easier approach, as it has more flexibility (and Screen uses OpenGL anyways). Create a texture of a line and scale/rotate it to point it to other nodes. Some trigonometry will be needed.

I suspected this would be the case, but thanks for confirming it. I assume I can still use Screen for a convenient way to access the GUI, and then override the various rendering methods in order to actually draw what I need?

Side note: how did you code-ify `Screen`?

[Blazer Nitrox]

Okay, I did some poking around with AtlasTexture, and I think I figured out how to do what I need to. I'm going to record it here for future generations, and as a second post because it just doesn't make sense to me to combine this with the above, since they're mostly unrelated (and the separation will help identify this as me explaining what I think I need to do).

 

AtlasTexture texture = new AtlasTexture(new ResourceLocation(MODID, "atlas"));
Stream<ResourceLocation> stream = list.stream(); //We get a stream of all of the textures we want, probably using Collection#stream()
SheetData data = texture.func_229220_a_((IResourceManager) Minecraft.getInstance().getTextureManager(), stream, Minecraft.getInstance().getProfiler(), 0); //Last argument is mipmap level, we use 0
map.upload(data);

So, first I must actually create a new AtlasTexture, passing in a ResourceLocation which will act as a registry name.
Then, to actually generate the stitched texture, I must call AtlasTexture#func229220_a_. It seems I should pass in Minecraft.getInstance().getTextureManager() (which I can do because I'm specifically doing this on Dist.CLIENT) for the first argument, a Stream containing the ResourceLocation's of all of the textures I want to stitch (so this will be done after all of the nodes are registered, no surprise there), an IProfiler (whatever that is, it seems to be used to track the progress of the texture stitching), and an integer mipmapping level (I would assume I'd use either 0 or 1, since I won't need mipmapping for a GUI I don't think). I would capture the output of this and pass it to AtlasTexture#upload, which would actually create the texture information I would then use for drawing. At this point, the AtlasTexture is ready for use.

 

if (!RenderSystem.isOnRenderThread()) {
	RenderSystem.recordRenderCall(() -> {
		manager.func_229263_a(texture.func_229223_g_(), texture);
      	texture.func_229148_d_();
	});
} else {
	textureManager.func_229263_a(texture.func_229223_g_(), texture);
  	texture.func_229148_d();
}

When we first start drawing, we have to bind the texture. First, we must ensure we are actually on the rendering thread, and ask the rendering thread to do it if we aren't. Then we call TextureManager#func_229263_a, which takes two arguments, a ResourceLocation we want to use as a key for our AtlasTexture and the AtlasTexture itself.  We can cheat the first argument here by calling AtlasTexture#func_229223_g_, which is essentially getRegistryName. This will set up our texture so it's ready to be bound to OpenGL (the above is ripped directly from TextureManager#bindTexture). We then call Texture#func229148_d, which actually binds the texture.

 

((I would provide a code example, except that Screen doesn't seem to provide any way to draw textures using UV coordinates which is all TextureAtlasSprite provides, and directly drawing via OpenGL requires calling Tessellator to get a BufferBuilder, and none of the methods in BufferBuilder (or, for that matter, Screen) have been deobfuscated yet.))

 

Now, in order to draw a texture from the Atlas onto the GUI, we call AtlasTexture#getSprite and pass in the key for the particular texture we want. That returns a TextureAtlasSprite, which contains the coordinates of our texture on the Atlas in absolute pixels as well as the relative min/max UV coordinates of our texture. Asking OpenGL to draw the part of the texture from min UV to max UV will draw our chosen texture and only that texture.

[DavidM]

Few things to add:

1. You might want to check out SpriteUploader.

2. Check out AbstractGui::blit. It is the built-in method of rendering sprites with UV coords.

3. You won't need to check on for the rendering thread if you are rendering in the Screen code (in the appropriate method).

 

On an irrelevant note, almost everything in BufferBuilder as well as AtlasTexture (and a few other mentioned classes) has been deobfuscated on recent MCP mappings. You should consider updating your mappings if you find them obfuscated on your setup.

[Blazer Nitrox]

9 hours ago, DavidM said:

Few things to add:

1. You might want to check out SpriteUploader.

2. Check out AbstractGui::blit. It is the built-in method of rendering sprites with UV coords.

3. You won't need to check on for the rendering thread if you are rendering in the Screen code (in the appropriate method).

 

On an irrelevant note, almost everything in BufferBuilder as well as AtlasTexture (and a few other mentioned classes) has been deobfuscated on recent MCP mappings. You should consider updating your mappings if you find them obfuscated on your setup.

Oh, hey! In the process of updating my MCP mappings I noticed that for some reason Forge was claiming it was 1.15 (and downloading Minecraft 1.15), but it was using the 1.14 MCP mappings, so I had no idea that AbstractGui#blit had a version which took a TextureAtlasSprite.

 

So SpriteUploader seems to do exactly what I was originally expecting, with the added bonus of being able to be called whenever the resource engine reloads. That is very useful, although SpriteUploader#getSprite is set to protected, limiting its use pretty drasically IMHO. I assume the idea is that I would ask it to bind the texture atlas and then access the atlas directly from there.

 

As far as checking the rendering thread, I figured that the relevant methods would always be called on the rendering thread, but since bindTexture does it I figured it wouldn't hurt.

 

All of this has been extremely helpful, thanks a bunch!

[Draco18s]

Might also be worth looking at how vanilla handles the Advancements screen.

[Blazer Nitrox]

6 minutes ago, Draco18s said:

Might also be worth looking at how vanilla handles the Advancements screen.

I hadn't even thought of that, but since it would have to grab each advancement's icon as it draws, that could be very useful. Good call

[Blazer Nitrox]

Okay, having taken a bit to mess around with everything, I think I understand how I need to go about this. I did notice that SpriteUploader doesn't seem to have any markers for being called on reload, is there some way I should be registering it with the resource manager, or does it take care of that itself somewhere that I'm not seeing? There certainly doesn't appear to be any events I can attach to for registration or to manually call reload(), nor does TextureManager provide any such functionality.

Edited May 29, 2020 by Blazer Nitrox
Minor correction in wording

[Turtledove]

What stops you from knowing a node's position at runtime? Try to separate the concept of a node to anything related to your skill tree.

 

If you can calculate/determine what skills a player knows at any time from player capabilities, access it from the GUI. Determine a pre-determined layout of the tree, like where a node will go (the physical node, not the skills attached to it) and where to draw arrows pointing to it. For example, if you have 40 skills in the tree, you could set up a lookup array of size 40 to determine if a node representing a particular skill should be drawn or not. This is the background layer. And in the foreground, overlay your skill name, description, etc over their respective positions. Then within the various mouse action methods, access this array whether it should detect player hovers/clicks there or not.

 

This is something similar I've done, if a player doesn't want to have the third row for example, the node and the arrows pointing to it aren't drawn. Notice that some concessions needed to be made, like the length of the names (I've formatted the string so it's inside the node, but anything longer will make the text go over the boundary). But if I wanted to, I could even vary the size of each node and have a lookup table that tells me how large a certain node needs to be for a certain skill name.

 

Edit: All a node should be is a quad with a texture, nothing more. You shouldn't need to register anything as David said

 

Edited May 29, 2020 by Turtledove

[Blazer Nitrox]

6 minutes ago, Turtledove said:

What stops you from knowing a node's position at runtime? Try to separate the concept of a node to anything related to your skill tree.

 

If you can calculate/determine what skills a player knows at any time from player capabilities, access it from the GUI. Determine a pre-determined layout of the tree, like where a node will go (the physical node, not the skills attached to it) and where to draw arrows pointing to it. For example, if you have 40 skills in the tree, you could set up a lookup array of size 40 to determine if a node representing a particular skill should be drawn or not. This is the background layer. And in the foreground, overlay your skill name, description, etc over their respective positions. Then within the various mouse action methods, access this array whether it should detect player hovers/clicks there or not.

 

This is something similar I've done, if a player doesn't want to have the third row for example, the node and the arrows pointing to it aren't drawn. Notice that some concessions needed to be made, like the length of the names (I've formatted the string so it's inside the node, but anything longer will make the text go over the boundary). But if I wanted to, I could even vary the size of each node and have a lookup table that tells me how large a certain node needs to be for a certain skill name.

 

Under normal circumstances I would have done it that way, however I know that over time I'm going to be adding nodes to the tree (and potentially letting other mods add nodes to the tree as well), so I want to be able to programmatically add the nodes to the tree, meaning I won't know their textures or positions until they are registered. While it does mean I have to do more work in building the screen, theoretically it will also allow me to simply register a new node without having to modify the tree itself. It would also potentially allow me to create a tool later on which allows me to visually build the tree out and then simply export it as a JSON which the mod could then load, although it'll be a looong time before I pursue that route.

[Draco18s]

5 minutes ago, Blazer Nitrox said:

so I want to be able to programmatically add the nodes to the tree, meaning I won't know their textures or positions until they are registered

Again, look at the advancements screen. It positions every advancement dynamically based on the advancements found during resource loading and they never overlap or have lines cross.

[DavidM]

43 minutes ago, Turtledove said:

Edit: All a node should be is a quad with a texture, nothing more. You shouldn't need to register anything as David said

OP wants to use the registry system for skill tree nodes so that he can manage the skill categories easier later on as well as allow other mods to add theirs. The nodes only manages how the tree is displayed; OP uses the registry system for the skill categories, not the actual icon (which can be stored in the registry entry for simplicity given that there is a one-to-one mapping for all of the categories).

 

 

[Blazer Nitrox]

@Draco18s I took another look at the advancements screen and realized I was a complete moron lol. I had been avoiding doing a proper parent/child hierarchy because I want the player to be able to loop around the tree like so:

(excuse the terrible quality, I threw this together in like 2 minutes in Paint because I didn't feel like waiting for GIMP to load)

At the time, I had thought that a parent/child hierarchy wouldn't be capable of this because the last node in the sequence (top right) wouldn't have it's parent node active, and so it would think that it couldn't be activated. And I only just now realized that when the player tries to activate the node I could just... check if any child nodes are activated as well.
 

All of this is to say that I've been a miserable fool who wasted his time because his solution was only half-baked. Nice.

Edited May 29, 2020 by Blazer Nitrox

[DavidM]

34 minutes ago, Blazer Nitrox said:

I had thought that a parent/child hierarchy wouldn't be capable of this because the last node in the sequence (top right) wouldn't have it's parent node active, and so it would think that it couldn't be activated. And I only just now realized that when the player tries to activate the node I could just... check if any child nodes are activated as well.

If your tree is not a tree (as in data structure; in your case it resembles a graph), then there is no need to separate the parent and child. Instead of keeping track of parent and children, create a set for all other connect nodes (given that direction does not matter in your skill graph).

Edited May 29, 2020 by DavidM

[Blazer Nitrox]

2 minutes ago, DavidM said:

If your tree is not a tree (as in data structure; in your case it resembles a graph), then there is no need to separate the parent and child. Instead of keeping track of parent and children, create a set for all other connect nodes.

Right, and that's how I've been doing it. I think you actually might have touched on the underlying problem... data structures have always kind of confused me for some reason, and I think part of the problem is in some ways I'm still thinking of this as a tree when in reality what I need is a graph, just with a pseudo-root node.