Alright. Now that I’ve hit a milestone, I need to implement some type of collision detection so that when a player gets close to a star he can select that star to move to that star’s solar system.
Since I’m currently using Point mesh, that can’t be picked up using collision.
I tried using Billboards, but those move around with the camera. So no go.
Then, I tried using quads. Only 1 side of a quad is painted because of normals. So no go.
At first, way back then, I used spheres. That worked but with so many stars around, FPS floored. No go.
Is there some kind of sprites I could use? Would that be pickable (collision enabled)?
I guess I could also use an algorithm to detect stars within a certain radius of the ship’s current coordinates. That would work, but then a player wouldn’t be able to travel to a long distance star without having to hop from one star system to the other. That would mean loading screens for nothing.
So what are my options right now?
I thought a sphere was actually the simplest collision volume. It only need a radius, right? Have you tried attaching a sphere volume (not spatial) to your points, as collision?
(Edit: I might not know what i’m talking about, haven’t worked much with collision)
Hmm. I never tried to attach a bounding sphere to a point entity. Not sure if it would work. But I guess it’s a good idea. The best way to see if it’ll work is to test it.
But it’s hockey in 10 mins. I’ll test it out later then post the result.
Since you already use an octree, why not just do this:
[java]BoundingSphere sphere = new BoundingSphere
for each star
sphere.radius = star.radius
sphere.position = star.position
if (sphere.intersects(ray))
player picked “star”[/java]
this is using pseudocode, but this is basically it once you get the octree nodes which you think will have your star
I don’t intend to let players pick out stars from outside the current leaf from the playing screen. The only way they could do that is if they had visited that leaf and been inside the sun’s system already. Otherwise it’ll only be a travel-fest without much exploring. And, of course, within fuel range.
As for what you’re suggesting, since I won’t let players warp to a star without at least a visit, it wouldn’t work. But, if I were to use what you suggest for a leaf, I’d have to iterate through each leaf if the player click only on 1 star. After that, they’re already there for that leaf. Of course, I’d have to reiterate though the leaf once the would leave it and came back to it, but it could work nicely.
I’m wondering about the impact on the system’s resources though. Either with or without bounding boxes. Those boxes don’t have to be drawn, but they do exist, even if invisible. As for iterating through the leaf and putting bounding boxes, it shouldn’t be too hard. But again, it would bring a tiny hitch at the first click. Something I’m not entirely agreeing on.
Food for thoughts and tests I guess. 
Hit a snag here.
Since I’m using a chase cam, I can’t retrieve the cam’s position to shoot a collision ray. The only cam I can get that info from is the cam object (application cam) that had to be attached to the ship. And that only “hits” the ship on which it’s attached to. 
Would it be possible to get the ChaseCam’s location and its facing as methods? Or is there a workaround to get that? Using the ship itself wouldn’t really work since where the ship is pointing at and where the camera looks at might be totally different places.
Also, is there a way to translate a mouse click on the screen to coordinates I can use ingame?
The only cam I can get that info from is the cam object (application cam) that had to be attached to the ship. And that only “hits” the ship on which it’s attached to. :/
You should be able to offset the picking ray to start in front of the ship. Just add a suitable vector in the direction the camera's facing, to the ray's origin.
madjack said:
Hit a snag here.
Since I'm using a chase cam, I can't retrieve the cam's position to shoot a collision ray. The only cam I can get that info from is the cam object (application cam) that had to be attached to the ship. And that only "hits" the ship on which it's attached to. :/
Would it be possible to get the ChaseCam's location and its facing as methods? Or is there a workaround to get that? Using the ship itself wouldn't really work since where the ship is pointing at and where the camera looks at might be totally different places.
Also, is there a way to translate a mouse click on the screen to coordinates I can use ingame?
The chase cam doesn't have a position or a facing it changes the position and lookat of the cam object.
so a cam.getLocation and cam.getDirection will give you what you need.
also to translate worldcoord to screencoord there are convenience methods in the Camera class getScreenCooord and getWorldCoord.
I would caclulate the on scrren positions for stars, in 2d screenspace, then when a player clicks we search for the next star around the point he clicked (lets say we allow 2% of screenresolution around a star maximum).
Pro: easy 2d calcualtions, rendering can stay point based,
No additional objects in Scene tree, cehcking can include a already visited flag
Contra: you have to check fi two stars are behind each other wich one is the nearest and travel to this one.
nehon said:
The chase cam doesn't have a position or a facing it changes the position and lookat of the cam object.
so a cam.getLocation and cam.getDirection will give you what you need.
I'm missing something here. If the shipCam (ChasingCam) is 50 units distant from the ship, from where the application cam is attached, how will that help? Those coordinates will still reflect the application cam's position, not the chase cam's. So if I shoot a ray from that, it will still be from the ship or very close to. Even if I add some units up/down/sideways, the line of sight will still be very wrong compared to what I would hit if the ray was shot from the chase cam since I can't even get the chase cam's distance from where is it attached to.
Is this making sense?
also to translate worldcoord to screencoord there are convenience methods in the Camera class getScreenCooord and getWorldCoord.
Ah nice! But that makes me wonder though. How do the game knows the "z" depth on a translation from the screen to the 3D world? Just curious.
EmpirePhoenix said:
I would calculate the on screen positions for stars, in 2d screen space, then when a player clicks we search for the next star around the point he clicked (lets say we allow 2% of screen resolution around a star maximum).
Pro: easy 2d calculations, rendering can stay point based,
No additional objects in Scene tree, checking can include a already visited flag
Contra: you have to check if two stars are behind each other which one is the nearest and travel to this one.
Sound thinking, but that brings the question of:
How do you know if what you found is really what the player chose if stars are overlapping? I know I would get very frustrated if I had to click multiple times to get the right target.
Also, I have to add that, as you get closer to the center of the galaxy, star population increases by a big factor. That means a lot of overlapping, stars being very close to each others.
I'm not dismissing the idea though.
If you know how far behind the ship the camera is, just add that distance + the size of the bounding box of the ship to the origin of the Ray, then you won’t risk hitting the ship.
That’s the thing. I can’t know the distance the chase camera is from the ship. That variable is protected. I could extrapolate if I had that, although I’d prefer the actual position.
I can set min and max distance the chase cam can go from the attachment point, but I can’t retrieve its current value.
madjack said:
I'm missing something here. If the shipCam (ChasingCam) is 50 units distant from the ship, from where the application cam is attached, how will that help? Those coordinates will still reflect the application cam's position, not the chase cam's. So if I shoot a ray from that, it will still be from the ship or very close to. Even if I add some units up/down/sideways, the line of sight will still be very wrong compared to what I would hit if the ray was shot from the chase cam since I can't even get the chase cam's distance from where is it attached to.
Is this making sense?
Not much :p
But maybe, I'm the one missing something.
I think what you don't get is that the chaseCamera is not a camera, it's a camera handler if you prefer, and it USES the application cam. (btw i already said it but i should definitely change the name to ChaseCameraHandler).
So it's only something that gives a behavior to the application cam. You only have one Camera object by viewport.
So what you are calling the shipCam and the application cam, are at the exact same position because that's the same object.
so the cam.getLocation returns the position of the cam in world space.
madjack said:
Ah nice! But that makes me wonder though. How do the game knows the "z" depth on a translation from the screen to the 3D world? Just curious.
It doesn't :p you give it to the method. this is used for mouse picking mostly, the z value (in view space) is the length of a collision ray shot from the cam.
then having x,y,z in view space the method convert the postion to world pace using the inverted worldView matrix.
If i understand that's pretty much what you want to do.
nehon said:
Not much :p
But maybe, I'm the one missing something.
I think what you don't get is that the chaseCamera is not a camera, it's a camera handler if you prefer, and it USES the application cam. (btw i already said it but i should definitely change the name to ChaseCameraHandler).
So it's only something that gives a behavior to the application cam. You only have one Camera object by viewport.
So what you are calling the shipCam and the application cam, are at the exact same position because that's the same object.
so the cam.getLocation returns the position of the cam in world space.
Ok, I can live with that. But then explain to me why, when I did my picking tests earlier, if I clicked at the edge of the screen, the ship, which was far away, was "picked"? Then, if I stayed in position and continued clicking, it would only pick the "mark"... I have an idea why, but I'd like confirmation first.
Oh and on a side note, either bounding spheres are not pickable (which I doubt), or if a ray collide with an object which isn't a triangle, even if it did hit a pickable along the way, will crash? I'm saying this because I just tried putting bounding spheres around the suns and picking crashed the thread running the picking method. It complained about not being triangles. (Only 'Triangles' mesh mode is supported.)
Unless I'm wrong, and from the examples, I should use a different node to attach my bounding spheres on so it doesn't get to hit anything it won't digest?
If the above is true, then wouldn't it be better that, if the ray picked something valid but along the way there was something not valid, it should ignore the invalid stuff and return only the good stuff? Ultimately, if everything is invalid, then give the Triangles mesh mode only supported.
Don’t use triangle collision. Since you said you’re using points for your stars, there’s no point in using jME’s collision system. Just use the method I’ve given or Empire Phoenix’s.
Yes yes. I know.
But I don’t like those. It’s not efficient.
Dude, how can you say its not efficient when you dont have an idea how to do it else?
Of course it’s an educated guess. Either a ray from a camera directly to something, or iteration through up to 2000 objects.
Guys, I don’t want to argue with anyone. I was simply picking people’s brains. It’s obvious I will have to go through it all, but I don’t have to like it.
Well, in the end, efficient or not, I won’t have a choice now will I? So that’s settled.
Well if you want a efficient solution and don’t mind spending a lot of time , I suggest taking a look at broadphase algorithms, as they greatly reduce the amount of checks required.