Itâs all without billboard currently and for the prefered size I tried multiple: (2f, 0.2f, 0f), (1f, 0.1f, 0f) and something with a z value but the output was always the same.
So you think itâs a scaling error? [Without scaling at all it looks like the first pic, only bigger]
Edit: localScale of 0.01 makes the bar look quite realistic and good but the Problem with the preferedSize stays
Edit2: The above picture #2 was taken with the line setSize(getPreferedSize()). It does make a difference. Without it I dontât have the four edges z-fighting but still some rectangulars fighting somehow
Paul youâre the best <3
Itâs hard to wrap my head around the concept of scale vs. size though and why a too small size looks too huge (but I guess that might be because lemur doesnât check for stupid users^^)
If I get that right, I now have: Size.x == 100 â 100 * 0.01 â 1 World Unit. Size.y == 10 â 0.1 World Unit etc. so itâs basically the multiplicator?
For the Billboard âProblemâ: I have implemented an CameraAppState which basically takes the girlâs loc/rot and does some quaternion magic to have that over-the-sholder view.
What my problem is: When I donât use Alignment.AXIS_Y, the pBar moves up and down as the camera/toon is looking up and down. I donât want that. I want that it moves accordingly to my cameraâs location only, Like when I am flying in the air, the tags have to point upwards, but other than that, they shoudnât be bothered by my camera rotation.
I guess I just need to adopt the Billboard Control a bit
Yeah, JMEâs BillboardControl positions based on view angle and not based on relative location. I agree itâs unnerving to see things swerve around as you turn your head, if I get your description right. You will have to tweak your own BillboardControl if you want something different, I guess.
Regarding size versus scale, you can change the size of the progress bar too but then you basically have to change everything. All of the margins of the backgrounds, the z offsets, etc. are all defaulted to things that make sense in screen space. In screen space, a progress bar of 100x10 looks pretty good. So generally, itâs easier to make the progress bar look good in the easiest way and then scale the whole thing down for the scene.
Thatâs true for a lot of the default UI elements. Way easier to scale them down versus trying to catch all of the different âsizesâ that youâd have to change.
FYI: Iâve finished coding a Lemur Gems for adding decorators like this. The test app looks like this:
And here is a link to the commented source:
I will try to write up an official article soon.
Edit: note that some things like setting the default style and other things discussed in this thread may not work properly on the 3.0 compatible Lemur that you used. This demo was written with the latest Lemur release as of the writing⌠version: 1.5.1
Hey again,
I am unable to Clone the spatial I attached the progress bar to because lemur.core.guiControl throws a CloneNotSupportedException, was this already fixed in a newer Version?
Sorry for the late reply, I was quite busy in the last days
Basically you can reproduce it by simply adding a progressBar somewhere in the SceneGraph (as a child to any spatial) and then trying to clone the spatial. This will recursively invoke clone on all children.
There is an easy workaround to this, you simply remove the progressBar from the Spatial and then rebuild the GUI for the cloned object.
In my case, I decided to not use clone as my other Controls werenât really clone-friendly either and it would be a special case where cloning is needed (I now create a new instance or reuse the spatial when possible).
If I remember correctly, you need clonable for save/load anyway, so you might look into that, as basic load/save of a GUI wonât work then (An usecase would be to have a user-customizable (movable) gui. There you could simply save the elements)
The issue is that itâs hard to fix-up the layoutâs children with the spatialâs children once cloned. Java cloning doesnât easily support this kind of cross-referencing either⌠and JMEâs is basically Javaâs. I thought of (and designed) a different cloning mechanism that was more like serialization. It has a registry where you can find shared objects. Itâs a pretty invasive change, though.
Anyway, there is a solution even within regular serialization, itâs just not trivial or straight forward and so far has been low priority.
When the NPCs walk (that essentially means: Changing their localRotation), the BillboardControl starts failing as it doesnât take the parentâs rotation into account.
I basically know that multiplying quaternions means applying those âone by oneâ. So If I would modify the billboardâs localRotation by multiplying it with the negated parents Rotation, would that fix the issue?
I tried to change the Color of the progress but the online ressources mainly focus on defining a style, but I want to change it during runtime.
Presumes that the background component is one of the ColoredComponent implementations (QuadBackgroundComponent, TbtBackgroundComponent, etc.)⌠which it will be with any of the default stylings.
Now the thing is, when I move the spatial (BCC.setViewDirection), the Billboard-Control isnât facing the Camera. When the Spatial then rotates so it walks in the direction it intentionally spawned, the BillboardControl is facing the Camera again.
If it hasnât been done yet then my question for that issue is, will JME saving/loading ever be abstracted so that custom implementations can be done by the developer? If it is already done I apologize, I have been away. Just got my hands on the alpha and liking it.
Holy shizzle, this new forum layout is so weird. You reply to a topic but it also posts your reply at the bottom.
My original reply to you:
If you already can then my question is moot. Good to know for my current little experiment. Just getting back into JME after a venture into LibGDX. JME seems more efficient for a big project.
So I created a test case and could track it down. Before opening a thread could you maybe confirm whether itâs broken or just misuse?
b.setAlignment(BillboardControl.Alignment.Screen); // This works fully
b.setAlignment(BillboardControl.Alignment.AxialZ); // Couldn't check, does wierd things :P
b.setAlignment(BillboardControl.Alignment.AxialY); // This is the one I am using, leads to trouble
b.setAlignment(BillboardControl.Alignment.Camera); // This is like without BillBoard (and I used the flyCam here)
Note: They all work when applied to the parent axis (where they basically override the actual rotation) but not as a child axis.
package mygame;
import com.jme3.app.SimpleApplication;
import com.jme3.material.Material;
import com.jme3.math.ColorRGBA;
import com.jme3.math.FastMath;
import com.jme3.renderer.RenderManager;
import com.jme3.scene.Geometry;
import com.jme3.scene.Node;
import com.jme3.scene.control.BillboardControl;
import com.jme3.scene.shape.Quad;
public class Main extends SimpleApplication {
Node n;
public static void main(String[] args) {
Main app = new Main();
app.start();
}
@Override
public void simpleInitApp()
{
n = new Node("myNode");
Node o = new Node("subNode");
Material mat = new Material(assetManager, "Common/MatDefs/Misc/Unshaded.j3md");
mat.setColor("Color", ColorRGBA.Blue);
Quad q = new Quad(1f, 1f);
Geometry geom = new Geometry("Box", q);
geom.setMaterial(mat);
o.attachChild(geom);
BillboardControl b = new BillboardControl();
b.setAlignment(BillboardControl.Alignment.AxialY);
o.addControl(b);
n.attachChild(o);
n.rotate(0f, FastMath.HALF_PI, 0f);
rootNode.attachChild(n);
flyCam.setMoveSpeed(flyCam.getMoveSpeed() * 5f);
}
@Override
public void simpleUpdate(float tpf)
{
n.rotate(0f, FastMath.HALF_PI * tpf, 0f);
}
}
Edit: Checked the Code that comes with my 3.0 SDK:
In rotateScreenAligned (the one that works), there is: