The problem with using multiple meshes is that it would seriously add drain to the GPU memory. Common buildings can have a size difference between 0.05 and 20 on the map, since the buildings are the main filler for the maps it would not be economical to create multiple meshes for each one, as I said, I just have to stop being lazy and figure out this GPU in OpenGL myself anyway. Though I may release the jPCT version first just to get it out there, I have to figure out how to budget new eyeglasses before I can continue testing anyway, not the glasses themselves but the exam, here in Seattle those are $70 or more, even at Walmart, and due to medical problems my budget only has a $50 leeway. But until I get new glasses I can't play 3D games at all, my prescription changed a lot in the last few years and I hadn't noticed since I normally hate 3D games. lol

Yeah, I'm an old skool gamer, but I have to adapt to the market if I want to get back into development.

Quote from: EgonOlsen on December 02, 2012, 09:15:45 AM
....but did the fix that i posted above work?

Sorry, yes it did actually. Now it works perfectly.

Quote from: EgonOlsen on December 01, 2012, 11:26:01 PM
BTW: I still fail to see the relation between doing stuff in OpenGL and collision detection. One has nothing to do with the other. The means that jPCT offers to do collision detection can be used, but they don't have to be used. You could use any other other physics library out there, if you want to. jPCT's own ellipsoid collision detection is based on http://www.peroxide.dk/papers/collision/collision.pdf with some additions and fixes.

If I have to override the collision detection myself then I may as well write the whole thing from scratch because the only thing I'd be using from jPCT is the loader and OpenGL work. Also there are a lot of rendering capabilities I am not finding a way to access, though I don't remember how to do it off hand, I will have to look through old code again, there's a way to change the color of shadows on individual objects, as well as altering the specular color using OpenGL which would be a nice effect to have access to. Also there's non-uniform scaling, which offers a lot of useful manipulations.

I mean, jPCT is great, don't get me wrong, but some of the features I need just seem to be out of reach. If it was Open Source I'd go through your code and figure out ways to implement them without having to rewrite anything. Since every time I attempt to implement shaders the program locks up, and I'm almost clueless in that arena. I can't find a way to make it work the way I need to. But the collision is too important to overlook, I need that to work as expected, and I need it simple and integrated. Really, I'm just seeing my code use less and less of jPCT with each new development, and having to do a lot of it in my library, which also requires me searching for a method to override the jPCT portions. My library, and game, is just too involved to have to deal with headaches like this. I mean, seriously, the collision just went boom.

Quote from: EgonOlsen on December 01, 2012, 09:11:42 PM
I'm a little confused about what writing stuff directly in OpenGL has to do with collision detection, but anyway... I'm still not sure what exactly you mean. You scale the map, i.e. the objects you want to collide with and if you do that, the collision happens too early, i.e. when there shouldn't be any collision at all? Is that the problem? Do you have a test case for this?

It would be easier to start from scratch than to attempt to find a flaw that is possibly part of the library. I'm stressed because it all worked until this one point, which means I'd have to go back and rewrite some of the original code as well as develop loaders and all that.

The collision is happening too early, and I have everything at the lowest settings. It only happens when the objects on the map are scaled, as I said an average of 8 is when it's noticeable, I didn't notice it until I tested an area with objects that had to be scaled that much to avoid memory consumption, reusing the meshes. Just load a map with a bunch of objects and scale each object by at least 8 to 11, take another object you have the correct ellipsoid for, tested in environments without scaled objects, and you should see it. To better simulate what I am seeing you should have different scale values for the map objects, and shared meshes, though even objects without shared meshes still have the error. The case I have right now would be a huge upload/download, because it's part of the demo version of the game and depends on all the extra stuff to load properly.

Quote from: EgonOlsen on December 01, 2012, 11:49:12 AM
Just fiddle around with the ellipsoid sizes. An ellipsoid as always an approximation of the object. If you make it so that it includes all polygons, it might be (depending on the object) too large for realistic collision behaviour. Also keep in mind (just in case you haven't) that the size of the ellipsoid is its radius, not its diameter.

That's just it, after some testing, it's not the ellipsoid, it effects camera collision to. The solid, static, map object collision is really far from the actual polygons, it's noticeable when you scale them by an average of 8. Anything not scaled is not effected. So the ellipsoid of the moving object, based on what yo have stated here, is not the issue, and I can't figure out what is the issue. If I can't scale map object arbitrarily then I'm probably just going to have to get off my lazy but and write it all in raw OGL so I can.

Quote from: EgonOlsen on December 01, 2012, 08:20:06 AM
The ellipsoid is given in units in object space. If you an object, you have to scale the ellipsoid as well.

Ah, well the object that's using the ellipse isn't being scaled, oddly Blender units import to jPCT very well. So the bounding box should be usable for creating an ellipse, then scaling that as the object is? Or would it perform better to have the ellipsoid represent the aspects of the object?

Sadly this doesn't seem to help much with the strange problem I am having of the objects being collided with. The collision is still farther from the objects than the actual polygons.

After looking over some things, how is the collision ellipsoid used? Is it a number of world units or a multiplier of some sort? That could be my problem, I'm basing the ellipsoid on the size of the object, for the one that's moving, based off the bounding box, but now I think this may not be correct.

If it's already constructed, and not compiled look into object.getPolygonManager() to access each polygon, or object.getMesh() to gain access to each vertex with an IVertexController.

Not sure if it's my code, or jPCT, as I still can't figure out exactly what's going on. But it only happens with scaled objects, almost as if the collision detection is scaled twice the object's scale. I'm using the ellipsoid detection, and the moving object is fine on objects scaled 1.0, it's any other scale value that has the effect. That's the best I can do to describe it. Any ideas?

Quote from: hamedf_hamedf on November 29, 2012, 03:26:24 PM
Dear Egonolsen,

this code rotate camera around itself (cam.rotateAxis)
but i want to rotate camera by center of object, like earh(camera) around Sun(object). and camera look at it.

A radial camera, or that's what I call it. Now, here's the method that works in jPCT:

1. Translate the camera to the location the object is, matching centers.
2. Rotate the camera's y by the angle you want it to be, and x if you're doing that as well.
3. Get the camera's x axis.
4. Translate the camera along that axis the distance you want it to remain.

Done.

Two more:

Quote from: EgonOlsen on November 28, 2012, 11:12:02 PM
Both... The latest official version doesn't care about them. The beta (http://jpct.de/download/beta/jpct.jar) also ignores them unless you set Config.useNormalsFromOBJ=true;

Ah, that's what I did wrong, thanks.

Just a quick question, if normals are included in the OBJ file, does jPCT use them or ignore them?

Best option is to create a small texture for each, and paint the name on using Java.

If you use an ITextureEffect you can dynamically change the name without recreating the texture, it works pretty well that way. I use a dynamic texture class that maintains a BufferedImage and applies an ITextureEffect when the text is changed, which I use a BufferedImage, loaded png, for the text font. for something that has an "unknown" number you may just want to do blitting, to conserve memory.

It's a huge image, but I have to show off. Now I'm getting serious about the game models: