Multiplexity: Space Commando (working title)

[vgo]

Thanks. I'll put that on my "list of things to do if I have time".

I have soooooo many things to do before deadline. Just finishing the scene saving/loading routines, I might still be able to make most of the stuff for the mission in my scene editor. Should be a lot of easier than trying to put everything in place in the game code (too much trial and error for object positioning etc.).

I've written a sort of property wrapper for my base class in the game engine, I can now load/save all object properties to/from a XML file or DOM node, display them on Object inspector (similar to the one in Delphi) and modify them. Makes my life a whole lot easier.

[WILL]

What FPS speed is the game supposed to run at? When I tried it out for the Highlights video the space movement seemed a bit sluggish. Then again it could be just the spacing between large body objects such as planets and stars.

Mind you the steering was very slow. Maybe some speed-up should be implemented, unless it's just my system running the game slowly. Then maybe it's a LOD issue. *shrug*

It was looking very good though, I wish you continued success. :thumbup:

[vgo]

The movement was a bit sluggish indeed (in some cases). You should try these executables and let me know if they work any better.

It's starting to look like I'm not gonna make it before the deadline... Still too much stuff to get working... Now I'm having trouble with the collisions again, I have no idea why they don't work anymore, in my test bed they worked just fine, but not in the game...

[vgo]

I'm trying to solve the collision problems by rendering the collision geometry, but I just can't get it working. I always get access violation and I have no idea why.

Here's the wrapper class' method starting the rendering:
[pascal]
procedure TPhysicsObject.DebugRender;
begin
if NewtonBody <> nil then
NewtonBodyForEachPolygonDo(NewtonBody, @DebugShowGeometryCollision);
end;
[/pascal]

Here's the callback
[pascal]
procedure DebugShowGeometryCollision(Body: PNewtonBody; vertexCount: Integer; faceVertec: PFloat; id: Integer);
var
i: Integer;
p0, p1: TVector3f;
va: array of TVector3f;
begin
SetLength(va, VertexCount);
CopyMemory(va, faceVertec, VertexCount * SizeOf(TVector3f));
p0 := va[0];
for i := 1 to VertexCount - 1 do
begin
p1 := va[i];
glVertex3f(p0.x, p0.y, p0.z);
glVertex3f(p1.x, p1.y, p1.z);
p0 := p1;
end;
end;
[/pascal]

This callback works ONCE and after that I always get access violation when exiting the procedure. Why?

[vgo]

Ok, I figured out that one. I added "cdecl" after the procedure and it worked. It only took me ONE DAY to figure out! :shock:

Now I can render the collision geometry and I can clearly see what's wrong...


What's happening here is that I have three modules that I've positioned to make a space station of sorts, then I created tree collision for them, but the collisions are a bit of... Eh...

In my original test the whole space station was one big static model, but here it's made of 3 separate objects that are connected together, I can move/rotate/etc. it in the editor.

I already figure out that tree collisions are static and it seems that the body matrix doesn't have any effect on them.

The question is: How am I gonna get my moving/rotating space stations and spaceships working? They have exterior and also interior where the player can move around while the ships/stations are moving/rotating. :roll:

If I can't figure out this one then for me the competition is over.

EDIT: The green lines in the screenshot showing the collision geometry are in the original position relative to the object center which initially is at 0, 0, 0 but when I move the objects then the collisions don't match up anymore.

[Huehnerschaender]

If I understand you right, you move your models and your collisions do not move with them. Is this right?

Which is your approach to make your ships moving?

So you move them yourself by rotating and moving them, then drawing them and "hoping Newton will do the same"?

Or do you let Newton do the work and physics and just use the Newton matrices to draw your models?

In the second approch, everything should work fine if you use the Newtonbodys matrices.

In the first approach you need to set the changed matrices to the Newtonbodys by calling NewtonBodySetMatrix.

It's a little hard to help here with no insight of what you are doing...

[vgo]

If I understand you right, you move your models and your collisions do not move with them. Is this right?

I can't move them. I can't apply any kind of force to them and setting the body matrix does absolutely nothing. If I throw in a simple box it works as I'd expect, but these don't work at all.

In the editor from which that screenshot is I've placed the station to the center of the scene (but I don't want it there, in my scenes the sun is in the center and everyhing else is around it). The station is made of 3 models, two cubes and a sort of tube which I've connected together in the editor so that the game knows these are the parts that make the station. These modules have interiors, with walls, doors, windows, desks whatever and I want the player to bump into them too.

The green collision geometry lines show the positions where the collisions would be if I'd just throw all 3 models to the center of the scene, but obviously that wouldn't make much sense, so I've moved them to match the portals (basically a hole in the wall covered with a rectangle telling the game that you can go through this to another module/part of the station) that are used to connect the modules to make a station.

I can't make convex hull collisions for the modules because, as you can see, they are not exactly convex hulls.

Imagine your average Quake3 level flying around in space, that's what I'm trying so hard to do.

For me it seems that the developers of Newton imagined that a tree collision is terrain or your average Quake level that just sits there and the players bang their heads on walls and it does this nicely, I've tried it and it works. But my terrains/Quake levels need to fly in space and collide with planets, spaceships and whatever I can come up with.

[Huehnerschaender]

You should think the other way.

The way you get your level into Newton world makes your models have the mass = 0, which makes them immovable.



And in fact, there is no reason to let your level rotate or move. You should let the world around it rotate and move! Understand what I mean?

[vgo]

Yes, I understand that, but it doesn't solve the problem of two collision trees next to each other, one of them has to move and I can't work around that just by rotating/moving the world or the collisions won't work.

I have to try that though, if I can wrap my head around that concept.
Guess my game engine needs some major modifications too, which may still mean that I'm out of the competition. We'll see...

Anyway, I couldn't even imagine that this would be any kind of problem for a physics engine, guess it's true when they say that Newton is pretty much the worse physics engine out there... Haven't tried any other engine though, I downloaded some and there's mostly just C source which I can't compile and usually not any kind of Delphi headers either.

[vgo]

Time for a compromise.

Last night I solved the collision problem by transforming the points manually and then building the collision tree. The drawback is that whenever the objects move I have to recreate the collisions.

I noticed some strange behaviour when I still had the body matrix set and then when I transformed the vectors with this matrix the points were still in their original positions. Newton did some sort of inverse transformation on them. When I set the body matrix to a identity matrix, then the points appeared to be where they should have been in the first place.

Obviously this means that my space stations cannot rotate/move anymore, but I have to compromise to keep things going. Maybe I'll change this after the competition is over...