I don’t have a use for that behaviour (at the moment), I just thought it would be generally useful for people…so don’t rush to put it in on my account 
Good to know, I’ll post a patch any moment then with my current modifications.
@Sploreg There goes the patch. Please tell me what you think. Let me make you a brief of the changes:
- LevelTool now has some ExtraToolParams. Precision, that means the height will be set absolutly, and Absolute, that instead of getting a value from the marker, get’s a float value.
- Added the Slope tool. It has precision attribute as well. The tool itself it’s buggy for now, as I couldn’t solve limits to the slope. I don’t want it to create a slope if you try to apply over beyond the marker. But I really think this behavior could be both changed or maintained.
- TerrainTool.actionSecondary only get’s called on button pressed, instead of both pressed and released (if user right clicked, move the mouse, stops the mouse and release, it was being called again).
- Added simple way to create new ExtraToolsParams menus. Please take a look at the Design (they are grouped in Other Components) and on TerrainEditorTopComponent.setHintText
Sorry, too long to paste, there goes a link.
https://dl.dropbox.com/u/3279456/patch.diff
1 Like
Thanks @shirkit! I will test this out today. But first, the patch is missing a couple classes: LevelExtraToolParams and SlopeTerrainToolAction
@Sploreg said:
Thanks @shirkit! I will test this out today. But first, the patch is missing a couple classes: LevelExtraToolParams and SlopeTerrainToolAction
Sorry @Sploreg I forgot to add those files. I just can't see things well in SVN, I'm used to work with Git. I improved the Slope tool a bit so it shows a white line between the dots and shows the angle between the markers. Please take a look
https://dl.dropbox.com/u/3279456/patch.diff
Looks good. I added it all to SVN. I really like the precision option for the level tool.
I noticed the slope tool can create a little bit of a “bucket” effect if the ramp is wide. I’m sure you have already seen this though.
Keep up the good work!
Yeah, problem is that I can’t find out when the stuff is beyond the marker. That’s why I tried this (http://hub.jmonkeyengine.org/groups/graphics/forum/topic/rotation-problem-2) but I couldn’t fix it completly. I’ll try something else now, but I don’t know if it’s going to work 
Ok, I give up. I don’t know how I’m going to solve this. I have 2 points, the init and the end of the slope.
Given the first 2 points (black), I wanted to calculate if other points (gray, purple and green) are between those 2 points, or better, if that point is the orange space.
All the ideas I tried to solve this problem have failed. If anyone has any, please, tell me. I couldn’t come out with a working solution.
Notice the angles on the red lines.
https://dl.dropbox.com/u/3279456/Screens/points.png
Edit:
My last attempo was this. First, calculate the formula (given the two black points).
[java]private void calc(Vector3f point1, Vector3f point2) {
Vector3f perp = point2.subtract(point1);
Quaternion q = new Quaternion().fromAngleAxis(FastMath.DEG_TO_RAD * 90, Vector3f.UNIT_Y);
Vector3f mult = q.mult(perp);
Vector3f add1 = mult.add(point2);
Vector3f add2 = mult.add(point1);
a1 = (point2.z - add1.z) / (point2.x - add1.x);
b1 = add1.z - add1.x * a1;
a2 = (point1.z - add2.z) / (point1.x - add2.x);
b2 = add2.z - add2.x * a2;
}[/java]
Then, for each possible value I wanted to check if it’s the orange area, I’d do this
[java] private boolean check(Vector3f check) {
float z1 = a1 * check.x + b1;
float z2 = a2 * check.z + b2;
if ((check.z >= z1 && check.z <= z2)) {
return true;
}
return false;
}[/java]
Doesn’t work, as you know. I just can’t find a solution.
Edit2: I can’t past through here:
Once, I do this
[java]Plane px = new Plane(Vector3f.UNIT_X, 0f);
Plane pz = new Plane(Vector3f.UNIT_Z, 0f);
float d1 = point1.length();
float d2 = point2.length();
if (px.whichSide(point1) != px.whichSide(point2) && pz.whichSide(point1) != pz.whichSide(point2)) {
d2 = d2 * -1;
} else if (px.whichSide(point1) != px.whichSide(point2) || pz.whichSide(point1) != pz.whichSide(point2)) {
// something should happen
}
Plane p1 = new Plane(point1.normalize(), d1);
Plane p2 = new Plane(point1.normalize(), d2);[/java]
And for every position I want to check if it’s in the orange secion, I do this
[java]if (p1.whichSide(new Vector3f(locX, 0f, locZ)) != p2.whichSide(new Vector3f(locX, 0f, locZ))) {[/java]
The problem is, when the points are inverted on only 1 axis (like, divide the map in 4 points +x/+z | -x/+z | -x/-z | +x/-z now, pick -x/+z or +x/-z) the thing isn’t working. For +x/+z and -x/-z everything works, but when just one of them are on oposite sides, this won’t work well.
Link to the patch diff. @Sploreg I’m out of ideas
https://dl.dropbox.com/u/3279456/patch.diff
I’m not 100% sure what you are trying to achieve here…but the simplest solution would be to have the player define a quad and then allow them to adjust the heights at the corners of the quad (or select a side to adjust heights of both corners on that side). Then the heights in between just becomes a simple interpolation between the 4 corners.
Other than that I’m not sure what you mean by the orange area. Does it extend to infinity? What bounds it?
To work out the position of something in the orange area take two steps:
- Create a line between the two points.
2.a. For each point on the map project the point back onto the line.
2.b. Look at that position, if its outside the bounds set by the two black circles discard it
2.c. Work out height by interpolation of position on the line
- Repeat (2) for all points
To optimise this I’d look for fast ways to cull points rather than needing to process them all. You could also do some stepwise algorithms to be a lot faster.
It might be worth looking at how painting programs implement gradient fills…
The orange area extends to infinity. The bounds are the limit of the terrain. The orange area is between those 2 parallel red lines.
The main problem here is how to do the 2.b that’s where I’m failing right now. As said, if the points are in different X or Z axis, but not both (XOR)
You could create a Plane (as in the maths object) following the line between the two point and vertical on the z access.
IIRC (I’ve never used it but think I remember seeing it) the plane has a method to take any point and map it to the plane.
Now it’s a very easy check whether X of the projected point is < start or > end to see it’s outside the orange area - and look at how far along the line it is to see what the y should be.
@zarch said:
You could create a Plane (as in the maths object) following the line between the two point and vertical on the z access.
IIRC (I've never used it but think I remember seeing it) the plane has a method to take any point and map it to the plane.
Now it's a very easy check whether X of the projected point is < start or > end to see it's outside the orange area - and look at how far along the line it is to see what the y should be.
I did that on my last attemp, check it out. DIdn't work.
Updated the patch diff: https://dl.dropbox.com/u/3279456/patch.diff
This getting close to the final one. I still can’t solve this final problem. Any ideas @Sploreg ? Or @zarch ? Can you test this patch and see if you have any ideas?
1 Like
Sorry, my best idea was the projection onto the plane. Are you sure that doesn’t work? The theory certainly seems valid…
It might be worth looking at http://docs.oracle.com/javase/1.4.2/docs/api/java/awt/GradientPaint.html to see if it gives you any ideas.
@zarch said:
Sorry, my best idea was the projection onto the plane. Are you sure that doesn't work? The theory certainly seems valid...
It might be worth looking at http://docs.oracle.com/javase/1.4.2/docs/api/java/awt/GradientPaint.html to see if it gives you any ideas.
By looking at that I managed to see that I was doing it wrong when calculating my Plane's constant. Thank you. I have to make a dot product between the normal and the positionst, not the lenght of the vector to find the constant. Exactly what [java]Plane.setOriginNormal(Vector3f, Vector3f)[/java] does. Thank you @zarch
@Sploreg here's my final patch diff. There still bugs, but I don't think it concers the patch diff I'm submiting. You can only see it if you Log each time you enter the TerrainTool.actionSecondary() method (log whenever you enter it). First, whenever you click, this is entered twice. One when the button is pressed, one when it's released. The other is, on the second click right click (I was able to reproduce on the class I created), if you were pressing the LEFT_CONTROL, the method is entered every possbile call (imagine it's running at 300 fps, the method is called 300 times). When you release the ctrl and press it again, then the problem doesn't happen.
https://dl.dropbox.com/u/3279456/patch.diff
1 Like
Glad it helped
Have you updated to the latest svn copy of the sdk? There are some bad, and what look like old, conflicts with the diff and what was saved with the last diff I applied/committed.
@Sploreg said:
Have you updated to the latest svn copy of the sdk? There are some bad, and what look like old, conflicts with the diff and what was saved with the last diff I applied/committed.
Did you already applied the commit? I didn't knew that :/ I'll try to solve those issues right now. Should take a few minutes.
Edit: Here it goes @Sploreg https://dl.dropbox.com/u/3279456/patch.diff
Glad I could help ^^
1 Like
Sweet, thanks. It is patched in and committed to trunk.
I’m heading on holidays tomorrow for 3 weeks. I will have internet access but not dev environment access. If you have another patch today I can get it in there, but after that it might have to wait until I am back…
If I’m able, I’ll post. I’m doing now a “Snap to Grid” function.