Hi

Thanks for your last message, it helped me resolve the issue by looking at the python script used by Blender to export 3DS. Here is what I did, I hope this can help someone...

Firstly, all the keyframe export section was commented out in my version with the following comment

# COMMENTED OUT FOR 2.42 RELEASE!! CRASHES 3DS MAX


I uncommented all the relevant sections, and then checked the flags used. I noticed that the script is using different conventions, and here are the relevant ones:


#------ Main Chunks
OBJECTINFO   =      long("0x3D3D",16);      #This gives the version of the mesh and is found right before the material and object information
VERSION      =      long("0x0002",16);      #This gives the version of the .3ds file
KFDATA       =      long("0xB000",16);      #This is the header for all of the key frame info

#>------ sub defines of KFDATA
KFDATA_KFHDR            = long("0xB00A",16);
KFDATA_KFSEG            = long("0xB008",16);
KFDATA_KFCURTIME        = long("0xB009",16);
KFDATA_OBJECT_NODE_TAG  = long("0xB002",16);

#>------ sub defines of OBJECT_NODE_TAG
OBJECT_NODE_ID          = long("0xB030",16);
OBJECT_NODE_HDR         = long("0xB010",16);
OBJECT_PIVOT            = long("0xB013",16);
OBJECT_INSTANCE_NAME    = long("0xB011",16);
POS_TRACK_TAG = long("0xB020",16);
ROT_TRACK_TAG = long("0xB021",16);
SCL_TRACK_TAG = long("0xB022",16);


I checked what values are set for these, and the one that is interesting here POS_TRACK_TAG (0XB020) was forced to zero, as the author of this script uses it as a position and not a rotation center:


# meshes have their transformations applied before
# exporting, so write identity transforms here:
if ID==POS_TRACK_TAG:
    # position vector:
    #track_chunk.add_variable("position", _3ds_point_3d((0.0,0.0,0.0)))


I changed the last line to


track_chunk.add_variable("position", _3ds_point_3d(obj.getLocation()))


And all is good now!


01-29 12:46:32.024: I/jPCT-AE(23839): Name in hierarchy found: balancier
[...]
01-29 12:46:32.034: I/jPCT-AE(23839): Setting rotation pivot of object balancier_jPCT0 to (0.3,-0.3,0.0025380924)


The conventions used in the original python script and in the JPCT loader are questionable as there does not seem to be an "official" 3DS specification, but this works great for Blender/JPCT-AE usage.

Regards
Nicolas

Hi

No there is no such message.

It's definitely stored somewhere though. I exported two 3DS files, one with pivot in (0,0,0) and one with the pivot I mention above. When I load them back into Blender from the 3DS files, the loaded objects have the correct distinct pivots. I attached the two files.
Do you use some external software to parse the 3DS? I'm happy to have a look if you can help me browse the file.

Also is there a way on runtime or in the jar file to confirm which version of JPCT I am using? JAR files do not seem versioned.

Thx
Nicolas

[attachment deleted by admin]

Sure:


01-07 22:55:51.995: INFO/jPCT-AE(7558): Static references cleared...
01-07 22:56:10.284: INFO/jPCT-AE(7558): Loading file from InputStream
01-07 22:56:10.303: INFO/jPCT-AE(7558): Expanding buffers...16384 bytes
[...]
01-07 22:56:10.533: INFO/jPCT-AE(7558): Expanding buffers...409600 bytes
01-07 22:56:10.533: INFO/jPCT-AE(7558): File from InputStream loaded...337755 bytes
01-07 22:56:10.563: INFO/jPCT-AE(7558): Processing new material Material.005!
[...]
01-07 22:56:10.583: INFO/jPCT-AE(7558): Processing new material Material.001!
[...]
01-07 22:57:43.843: INFO/jPCT-AE(7558): Processing object from 3DS-file: break
01-07 22:57:43.993: INFO/jPCT-AE(7558): Object 'break_jPCT9' created using 228 polygons and 122 vertices.
[...]


I have used [...] to strip some lines:

• Expanding other buffers on the first one
• Processing other materials on the second one
• Processing other objects with the same log on the two last ones

Regards
Nicolas

Hi

great to read that 3DS pivot support has been added. This will be a really useful feature. Unfortunately I could not get it to work properly. If I load the attached .3DS file into JPCT-AE 1.24 beta (the url above), and set the flag correctly:


private static Object3D[] loadModel(InputStream is)
{
Config.useRotationPivotFrom3DS = true;
return Loader.load3DS(is, 1);
}


I get a (0,0,0) rotation center. I am not sure whether the issues comes from the 3DS file though, as I do not have any tool to look into it, but in Blender it rotates around (-0.409, -0.179, -0.036).



Thanks
Nicolas

[attachment deleted by admin]

Any chance we get that supported in a future version? I agree it should be disabled by default, but could be useful in some cases to be able to enable it.

Nic

Ok sorry I just misunderstood the following (or rather misread)

QuoteOr was culling disabled on the model? In that case, you will create holes for the collision detection on all faces that would otherwise be culled, because collision detection doesn't happen on back faces.

Thx
Nicolas

True, but the issue is the radius of the sphere would have to be huge so that 1/ it appears rather flat and 2/ user does not get back to the airport too quickly by flying in the same direction Thanks for the idea though

EgonOlsen I think you are right, I will probably go for 2)

Thx
Nicolas

Actually I still think the behaviour is weird. I've turned culling back off:


plane.setCulling(Object3D.CULLING_DISABLED);
ground.setCulling(Object3D.CULLING_DISABLED);
sky.setCulling(Object3D.CULLING_DISABLED);


Now the code works fine when I check if the plane can move downwards (y and z are flipped):


final SimpleVector uiDz = new SimpleVector(0, 1, 0);
final float minDist = ground.calcMinDistance(plane.getTransformedCenter(), uiDz);


minDist takes correct values. Now I want to know if the plane has gone underground, I assume I just have to flip the "direction" vector.


final SimpleVector uiDz = new SimpleVector(0, -1, 0);
final float minDist = ground.calcMinDistance(plane.getTransformedCenter(), uiDz);


Issue is this always returns COLLISION_NONE, even when I go trough the ground.

Nic

That makes completely sense - culling was disabled. I've reenabled it now after sorting the normals. All behave well.

Thx
Nic

It seems that the sign of the return value of calcMinDistance is dictated by the direction of the normal of my plane. I fixed the normals in Blender and it works good now.

Thx
Nic

Edit: Correction before I'm told off by EgonOlsen , if does not just dictate the sign of the return value, it seems to dictate the direction where it moves for collision detection, hence sometimes I got COLLISION_NONE as it was moving in the opposite direction

To illustrate this, rolling always is fine until I get to the point on the picture below. I can see the end of a face (with the texture being discontinuous) and when I get to the next one, I fall through it.

It does return COLLISION_NONE.

modelDz is how much the model would like the plane to move. I check how much I can move in that direction (minDist, which should rather be called maxDz), and I can move less that what the model wants to move, I stay still Z-axis wise.

I really think there is like  a "hole" in the ground, as no matter how I approach it, it goes trough the floor at the same place.

Thx
Nic

Hello

I am using collision detection from a plane to a point using the calcMinDistance method. I use the following code:


public double checkLeftGearCollisionDz(double modelDz)
{
final SimpleVector uiDz = new SimpleVector(0, -1, 0);
final float minDist = ground.calcMinDistance(leftGear.getTransformedCenter(), uiDz);
if(!(minDist == Object3D.COLLISION_NONE) && minDist > modelDz) // values are <0
{
return 0;
//return minDist < 0.5 ? 0 : minDist*modelDz;
}
return Object3D.COLLISION_NONE;
}


I place my plane a bit over the ground, and it falls nicely on it. Collision works fine, as I can see in the figues I write in the logs. Then I start rolling forward, and at some point it will fail. The values I pass to the collision detection are consistent though:


Z before(22996): 4.150430202484131
dZ tentative(22996): -0.11481471204757691
actual dZ(22996): 0.0

Z before(22996): 4.150430202484131
dZ tentative(22996): -0.10089619320631027
actual dZ(22996): 0.0

Z before(22996): 4.150430202484131
dZ tentative(22996): -0.12035272479057313
actual dZ(22996): 0.0

Z before(22996): 4.150430202484131
dZ tentative(22996): -0.10804409158229827
actual dZ(22996): -0.10804409158229827


Z before is the position of the plane before calcMinDistance. This remains constant. On each frame I try to move the plane by dZ tentative and check if this makes it collide with the ground. If yes, I use 0 for actual dZ.
On the last frame, my Z before has not changed, the dZ tentative is a value I have tried before, but calcMinDistance returns Object3D.COLLISION_NONE and actual dZ is non zero -> the plane goes trough the ground.

I have taken a look at this thread
http://www.jpct.net/forum2/index.php/topic,1376.msg9655.html#msg9655
I increased the value of collideOffset to 500 with no success (even tried 5000, made no difference)

I also saw this one
http://www.jpct.net/forum2/index.php/topic,335.msg1825.html#msg1825
And I tried using an octree:


final Object3D world = loadGround(is, 1);
world.setCollisionMode(Object3D.COLLISION_CHECK_OTHERS);
final OcTree o = new OcTree(world, 100, OcTree.MODE_OPTIMIZED);
o.setCollisionUse(OcTree.COLLISION_USE);
world.setOcTree(o);     
world.setCollisionOptimization(Object3D.COLLISION_DETECTION_OPTIMIZED);
r.ground = world;


Tried difference values for the maxPoly. I get a StackOverFlowException for values <100, and no difference in collision detection for values >100.

It seems to me that there is an area in the ground where collision just won't happen.

Thx
Nicolas

Hello

I am trying to find out what would be the best approache for using a (very) large map. This is for a plane game, and the user needs to be able to fly around with very little restrictions.

I have thought about a few approaches for this:

• Create a huge Map in Blender, export it, and hope the user won't see the end
• Create a less huge Map, and add some limitations within the game that makes it impossible for the player to see the edges (for example traffic control sending fighter jets to take you down like in GTA
• Use a seemless terrain 3D tile and repeat this as long as the user keeps going...

I know pretty much how to achieve 1 and 2, but not sure about 3. I thought I could have some basic tiles that I load in my game, and create them on demand with clone and place them in case they become visible. But this causes a few problems:

• Drop in FPS when cloning an object? When disposing it when it is no longer visible?
• Ability to place an object at runtime, accurately enough so that player does not see any space/overlap between the tiles
• More difficult it seems, detecting when a surface becomes visible and what type of terrain should be there (mountain, sea, shore?)

I would be quite interested to read if anyone has ideas on this, specially the third bit on detecting what a new object should be created and placed at runtime. Anything available in JPCT in map tiling? Does anyones have any good experience in this?

Thanks
Nicolas

From what I have read on some forums, the "repeating" option in blender is not exported, it is a blender only thing so it is of no help here.

I realized than even with removing


citydayc.setTileModeXY(TileMode.REPEAT, TileMode.REPEAT);


the textures now repeat correctly. There are still a few artefacts but I reckon this is more to do with my UVmapping than with JPCT.

I get about 28-30 FPS on my Desire HD, but it drops to around 20-24 when I hover some more complex textures, and same values when collision detection is playing.

MrM, I see your point. I think I will continue with the route of smaller images however and let JPCT repeat them. This seems to be the best performance/look ratio. Thanks a lot for your help.

Rgds
Nicolas