Attaching Indicators (Healthbars) to rootNode/SceneGraph

User Code & Projects tonegodgui
1

Hey Guys,

I want my NPCs to show some little healthbars and since I am using tonegod, I thought I could simply add an Indicator to the NPCs Node since it inherits from Spatial.

My Problem is, the bar stays at the fixed position I set to it upon creation instead of the Node’s 3D Location (and an added BillboardControl). How would you solve that task?

I don’t want to add nifty and mix those two or completely recode everything into lemur (would it support that behavior?) but it seems I don’t have any chance?

1 Like
2

Hopefully someone else may answer your real question, but…

a) you wouldn’t have to recode everything into lemur just to use it here.
b) yes, a lemur progress bar is just a spatial and will follow wherever its parent goes.

3

mh you are right with a) but I don’t know how the two libs would work together without interferring?
Because tonegod uses some custom shaders and I don’t know in what way it modifies the guiNode?
I already have 22 Shaders, so I should reduce that count.

Maybe I’ll simply give it a try and see how it works out :slight_smile:

Edit: Your Wiki Page states that it depends on 3.1-alpha, would it work with 3.0 aswell?

4

Lemur just uses standard JME shaders.

Pretty sure that the latest release only works with 3.1 alpha. The last release that was on google code was for 3.0.

…though you should really consider upgrading soon.

Hopefully the answer to that is “not at all” because it would be completely silly to modify the guiNode.

Edit: also you were talking about adding this to your scene objects which I guess aren’t even in the guiNode anyway. (Lemur doesn’t care… they are just regular JME spatials in the end.)

5

Okay, so I have it “working” now, I only encounter three problems:

  1. I call setCursorVisible(false) but lemur seems to override it (Even though I ensured that I call it after GuiGlobals.initialize)
  2. I can only see a small vertical bar (looks like the width would be 0), even though I tried Container.setSize() or progressBar.setSize() (with no change)
  3. My Spatials have values like (-3, 2, 5) for their Positions but Lemur refers to Screen-Pixel-Values. Is there an easy way? Maybe something like Camera.toViewCoordinates()? The Problem is I can’t attach it as a child then?
6

http://jmonkeyengine-contributions.github.io/Lemur/javadoc/Lemur/com/simsilica/lemur/GuiGlobals.html#setCursorEventsEnabled(boolean)

  1. progressBar.setPreferredSize()… though it should have had a decent default already. But in ‘world space’ you may want to adjust it anyway.

  2. Lemur defaults to thinking that it’s stuff is big like screen space but you can give it any values you want. Or just setLocalScale() on it to something reasonable.

progressBar.setPreferredSize(new Vector3f(1, 0.1f, 0));
progressBar.setLocalTranslation(-0.5f, 0.05f, 0); // to center it
mySpatial.attachChild(progressBar);

…should work.

Note: with a billboard control you probably want to have a node that has the billboard control that contains the progressBar as a child, maybe.

1 Like
7

Only one Problem left:
Without the Billboard Control I have a huge green wall infront of me which is not affected by setPreferedSize()
With the Billboard Control I see the bar-shape but it seems I see the backside. It enables me to see through walls, so it basically cut’s holes into the world

Edit: It seems I have another Issue with the Mouse-Controls. I can move the mouse but my clicks won’t be processed by my inputManager?

8

Are you running the old version of the lib on 3.0 or the new one on 3.1? If it’s the old one then you might also have to setSize()… I can’t remember for sure. But really, I’m going to have to start seeing the code because your comment about the billboard control totally confuses me. I’d have to see how you are rotating it to make the billboard control work.

…regarding seeing through walls it sounds like you have some weird stuff going on with buckets or viewports or something.

What Mouse-Controls? Lemurs? To get clicks you register listeners. It only affects input manager if the events are consumed.

9


This is what I see.

When I remove the Billboard Control and use setSize() I have the “blue-only” part as you can see with the two left guys.
Tbh I guess I like it better without the Billboard as it also reacts when you look up or down (though I guess I could fix the rotation in that axis by a simple extends).

Do I need a special bucket for the bar (i.e. NOT the Transparent Bucket?)

Edit: the Input Bug was some wierd Mac-Os Issue again, it works now

10

No, they just need to be in the transparent bucket. It looks like they aren’t.

It would depend on how your scene is setup and again it would be easier then if I could see some code.

11

Putting them in the Transparent-Bucket fixed it partly. I can now see that huge green walls again (the Billboard has hidden them)

Well the code is pretty simple:

nStatsBar = new Node("StatsBar");
nStatsBar.setQueueBucket(RenderQueue.Bucket.Transparent);
progressBar = new ProgressBar();
progressBar.setModel(new DefaultRangedValueModel(0, max_health, max_health));
progressBar.setPreferredSize(new Vector3f(1f, 0.1f, 0f));
progressBar.setSize(new Vector3f(1f, 0.1f, 0f));
progressBar.setLocalTranslation(-0.5f, 2.125f, -0.5f);
//nStatsBar.addControl(new BillboardControl());
nStatsBar.attachChild(progressBar);
((Node)spatial).attachChild(nStatsBar);

The Problem is, when viewed from front you only see the “bar” without it’s contents. The “progress layer” is way behind.

Front:

Back:

12

Yeah. re: the standing off of the background and stuff… it might be better to just set the scale of the progress bar rather than trying to shrink it down. Shrinking it means there are a lot of different ‘sizes’ you will have to adjust as well (like the z-offsets of the layers and stuff).

Probably easier just to progressBar.setLocalScale(0.01f); or whatever.

I will try to put together an example of using a progress bar in this way later tonight.

13

I am ashamed, I somehow overread the setLocalScale() you recommended earlier :confused:
I now have yet another issue (The one I had when simply attaching it to the GUI-Node):

You can only see a pretty small green stripe, don’t know why.
I am using the latest release on google code along with the 3.0 sdk.

I now changed the setSize() and setPreferedSize() to progressBar.setLocalScale(new Vector3f(0.25f, 0.0025f, 0f));

Thanks for your support btw :wink:

14

Hmmm… if it weren’t for the fact that the background looks right, I’d think it was facing the wrong way…

This could have been something that was fixed in the newer version and you might need to call progressBar.setSize(progressBar.getPreferredSize()); Something in my memory gets tingly with that.

I will experiment some tonight to see… but I’ll be using the newer code as I don’t still have any projects using the old version. But maybe I’ll see the same issue anyway.

15

I think I figured it out “a bit”: When I hurt the npc the green bar gets shorter in height, which means the green bar should be rotated by 90° for it to work.

progressBar.getChild(".value" or “value”) return null and from the Docs it seems like this is only a style Id

16

Yeah, that’s only the style ID and has nothing to do with node names. I don’t know why you need it, though. There are already methods on ProgressBar to get the sub-components… but you shouldn’t need those either.

If the green bar needs to be rotated then the whole progress bar needs to be rotated. It’s very strange, either way.

Ah… first of all, don’t do non-uniform scale. You shouldn’t need to and it’s hiding the real issue here. Also, 0 for z is going to cause problems anyway. Set a uniform scale and then worry about the progress bar size itself if you want it shorter/taller relative to the rest.

But the fact that you’ve set y so ridiculously small compared to the x is a key indicator that something is out of whack that your scaling is hiding.

Are you using the glass style or just no style at all? If the latter then you definitely have to give the progress bar a preferred size or it will not have one, I think. Actually, seems true either way. Weird.

17

Well what I saw is, when I make the component bigger, I can see the bar going vertically. If I reduce it’s value I can even see the green parts getting smaller, so I might need to rotate the whole ProgressBar and swap x and y size.

It seems I got the scale concept wrong aswell. with uniform you mean setScale(float)? So I don’t use it to set the Size but rather to define how big one unit is in world space?

Since I call

BaseStyles.loadGlassStyle();
GuiGlobals.getInstance().getStyles().setDefault("glass");

It should work.

Edit: It is definately related to the glass style:
I remebered what you always tell the people :stuck_out_tongue: Do a simple test project. I copied the Getting Started and I am indeed missing the style. I only have the white text and the button-text turns yellow on mouseover.

I don’t have lemur-proto.jar but it shouldn’t be in it, it should be included in lemur.jar. Could there be some troubles with groovy?

18

The style is being loaded fine or you would get an error. But in the older version of Lemur there was no ‘default style’… so you have to pass it to every element you create as a parameter. “glass” in this case.

19

That’s right. Do that and post what the progress bars look like without the billboard control… and with.

20

Now with the glass style my testcase works pretty well and in the GUINode everything works fine (setLocalScale, setPreferedSize) but as soon as you add it to the rootNode you run into some troubles:

While the progress is now along the x axis, the progessBar is miles larger in y-direction.
After using setLocalScale(0.125f) to size it down a bit, it still looks like this (the bar still continues under the earth)

When I additionally use setPreferredSize():