Glad you like it, and thanks a lot again for your precious help !

It's just the begining, we'll use our concept for other projects.

It's really strange, it does not require anything special, and it works for sure on Nexus 7.
However it could indeed be a language problem, for now we've just enabled the apps for a few countries (France, Belgium, Spain, ...)
Where do you live in ?

PS : yeah I know it's quite expensive, I'm not the one who set the price. I'll send you an APK in private. Also, we may soon use our engine for other stuff, and it could be free.

Hi,


My apps are finally released !!     ===> https://play.google.com/store/apps/details?id=com.faceausud.aspelescun

The goal was to make an interactive version of already existing mountain hiking maps (on paper), for both PC and Android.
Areas covered are located in the Pyrénées, south-west of France.
Hiking pathes are represented by polylines, and places by billboard planes.
You can see your position and path using the phone GPS, and with the right orientation thanks to magnetometer/accelerometer/gravity sensors. You'll never get lost in the mountain again ! 
The Java (PC) version is actually an editor allowing to build a guide from scratch, by placing points of interest, picking paths, ...

App demo video ===> https://www.youtube.com/watch?v=xpeNPrsTxTo

Some technical features :

• advanced billboard system (rectangular billboards for better picking, billboards have always the same size on the screen whatever their position, ...)
• advanced blitting GUI (interaction with blitting elements, blitting drag with mouse / touch, buttons magnification, menu animations, blitting tooltips, ... )
• fast vertical projection on map (using a kind of simple polygon research)
• custom shader : add color on map depending on the altitude, and display altitude iso lines
• high resolution texture (4096x4096) available even for android
• camera : orbit camera, "walkink camera", camera smooth animations, compass-like camera rotation using android sensors, ...
• atlas system for huge amount of small textures (billboards)

I still have to improve a few things, but it's yet 100% functionnal.
For now only 2 apps (2 different areas) have been released, but new area are comming very soon.


A big thank to Egon, who is of course credited in the app description.
Please add it to your Projects page if you like it.

Hi,

I would like to know what are the differences between reduced and non-reduced serialized objects, and also why shouldn't we use reduced objects on desktop program ?

I've noticed that when I use a reduced object on desktop, loading time is faster and the serialized object takes less memory on disk than both obj and non-reduced serialized object. And it works great ! So why should I avoid using it on desktop ?

Thanks in advance, cheers !

(oups, sorry i didn't want to post this in the Project section, thanks EgonOlsen for moving it into the right place !)

Ok, that's what I was afraid of...

Thanks !

Hi,


I have noticed that on both JPCT and JPCT-AE the polylines are limitted to a maximum width.
This is not really a problem for me on PC because screens all have pretty much the same pixel density. But on android, it's a different story...

So my question is : is there a way to overcome this polyline width limit ?


Thanks in advance, cheers !

Ok, thanks for your answer.
I think I'll finally add some polygons as you suggested.

I've made a simple workaround which works fine in my case : the 4 small textures actually cover a slightly bigger area than a quarter of the orignal texture, so as the UVs won't be outside [0,1] range.
It looks basically like this :



float reductionPercent; // example : 0.9f if the original image has been reduced at 90% to solve side effects (and then cut into 4)
float ratio = 2 * reductionPercent;
float margin = 1 - ratio/2;

[...]

for(int i=0; i<nbTriangles; i++) {

// read polygon UV :
SimpleVector uv1 = polygonMgr.getTextureUV(i, 0);
SimpleVector uv2 = polygonMgr.getTextureUV(i, 1);
SimpleVector uv3 = polygonMgr.getTextureUV(i, 2);
u1 = uv1.x;
v1 = uv1.y;
u2 = uv2.x;
v2 = uv2.y;
u3 = uv3.x;
v3 = uv3.y;

boolean west = u1 < 0.5;
boolean south = v1 < 0.5;
if(west) {
u1bis = u1 * ratio;
u2bis = u2 * ratio;
u3bis = u3 * ratio;
}
else {
u1bis = (u1 - 0.5f) * ratio + margin;
u2bis = (u2 - 0.5f) * ratio + margin;
u3bis = (u3 - 0.5f) * ratio + margin;
}
if(south) {
v1bis = v1 * ratio;
v2bis = v2 * ratio;
v3bis = v3 * ratio;
}
else {
v1bis = (v1 - 0.5f) * ratio + margin;
v2bis = (v2 - 0.5f) * ratio + margin;
v3bis = (v3 - 0.5f) * ratio + margin;
}
if(west && south) texID = textureID1;
else if(west && !south) texID = textureID2;
else if(!west && south) texID = textureID3;
else if(!west && !south) texID = textureID4;

polygonMgr.setPolygonTexture(i, new TextureInfo(texID, u1bis, v1bis, u2bis, v2bis, u3bis, v3bis));
}




This can only be used with 2x2 textures (not NxN), but is usefull to bypass texture maximum size on terrain (epecially on Android...)

Sorry, I forgot the comment : this is the center of the model, where the four regions meet.
We can see the repeating textures on polygons that intersect several regions. These bad polygons have actually several textures, but we can only see one because I use TextureInfo.MODE_REPLACE.

Sure :


texture2x2 by atreyu64, on Flickr

Hi,


I'm trying to split an object texture into 2x2 parts without modifying the mesh, just by re-asigning UVs.
The problem is about the "border" polygons (which overlap several parts, so they may have several textures), because the result is ugly either with clamping or repeating textures.

Is there a way to make a kind of "invisible" clamping, meaning that UVs outside [0,1] range would be completely transparent ?

I hope what I'm saying make a sens... 


Thanks in advance, cheers !

Hi, it's really funny that I've just come across this topic right now, because I may soon have to develop an app using a much more bigger area than I had before.
So I was thinking of using "Geomipmapping" or other solution to load dynamically a huge terrain (huge model and huge texture, from real world).

I've given Ardor3D a try because it implements a solution ( https://github.com/Renanse/Ardor3D/wiki/Terrain ), but I'm giving up as it's poorly documented, much more difficult to use than jpct, and seems to be kind of obsolete.
So for now I don't know how to do it, I'll maybe just keep things static but try to reduce mesh / texture as less as possible, as the app would only have to run on a recent PC (no android version planned for now).
By the way do you know a GPU allowing to load textures bigger than 8192² ? And is there a limitation in the max number of polygons in JPCT / OpenGL ?

Anyway, I'm still working on my other apps (with reasonable mesh and texture sizes...), I've developped an editor allowing to pick/modify hiking ways (polylines), to create and place signs (billboards), etc... so as my partner (not a computer scientist) can at the same time create contents easily.
We still plan to release theses apps (one app for each montainous region) as soon as possible, but we really want to polish it a lot and it takes some time... I'll keep you in touch !

• camDist is the distance between the camera position and the camera lookAt point (the orbit radius).
• camYMax is the maximum Y value of my camera, maybe you don't need it
• lookAtYMin and lookAtYMax are Y min/max values of the lookAt point, you shouldn't need them neither.

I've set these min/max values to prevent my camera from going below my terrain or too high, but I let the camera shift on x and z axis infinitely.

That is perfect, works like a charm, thank you so much !
Is (or will) it be also available on JPCT AE ?

By the way, what is the Polyline.setParent(Object3D) method for ? Just to make the polyline follow the parent object when moving ?

Well, this is pretty much what I actually do, if you want to see the result :  http://sangla.axerito.perso.sfr.fr/TopoMapNeouvielle.jar
I use a few more tricks to prevent camera from going where it's not supposed to, but basically this should be all what you need.

Hi, I've developed this kind of camera behaviour, but I use a different approach.

Basically I manage four things for the orbit control :

• a vertical angle (on y mouse drag)
• an horizontal angle (on x mouse drag)
• a "look at" point to shift the orbit center (on right-click drag)
• a distance to the "look at" point.

Here are some keys to do it...


protected Camera cam;
protected SimpleVector lookAt = new SimpleVector();
protected SimpleVector camPos;
protected static final float angle2Max = (float) (Math.PI / 2 - 0.001);
protected static final float angle2Min = 0;
protected float angle1 = 0; // angle around y-axis, as measured from positive x-axis
protected float angle2 = angle2Max; // angle up from x-z plane, clamped to [0:Pi/2]
protected static final float dragGain = 0.01f;


Camera Rotation (with min/max angle) :
protected void leftButtonDragged(float dx, float dy) {
angle1 += dx * dragGain;
angle2 = Math.min(angle2 + dy * dragGain, angle2Max);
angle2 = Math.max(angle2, angle2Min);
cameraChange();
}

Camera shift :
protected void rightButtonDragged(float dx, float dy) {
cameraShift(dx * dragGain, dy * dragGain);
cameraChange();
}

Camera shift is a little bit more complicated :
private void cameraShift(float screen_dx, float screen_dy) {
if(screen_dx ==0 && screen_dy == 0) return;

float distRatio = (camDist/camDistMin);
screen_dx *= distRatio;
screen_dy *= distRatio;

camPos = cam.getPosition();
cam.moveCamera(Camera.CAMERA_MOVERIGHT, screen_dx);
cam.moveCamera(Camera.CAMERA_MOVEDOWN, screen_dy);
SimpleVector shift = cam.getPosition().calcSub(camPos);
lookAt.sub(shift);

if(lookAt.y > lookAtYMax) lookAt.y = lookAtYMax;
else if(lookAt.y < lookAtYMin) lookAt.y = lookAtYMin;
}

Update camera position and rotation :
public void cameraChange() {
         camPos = cam.getPosition();
         updateCamPosition(camPos, lookAt, camDist, angle1, angle2, camYMax);
         cam.setPosition(camPos);
         cam.lookAt(lookAt);
}

public void updateCamPosition(SimpleVector camPos, SimpleVector lookAt, float camDist, float angle1, float angle2, float camYMax) {
double t = camDist*Math.cos(angle2);   // distance to y-axis after being rotated up
camPos.x = (float) ((t*Math.sin(angle1)) + lookAt.x);
camPos.y = (float) - (camDist*Math.sin(angle2)) + lookAt.y;
camPos.z = (float) ((t*Math.cos(angle1)) + lookAt.z);
}


Hope it helps, do not hesitate to ask me some more details if you are interested.