I'm done with the boring stuff, I already have all 17 classes, one for each lump that loads the bytes from the file and saves them in java objects. I tried to get clean java classes, using Enums where appropiate, not using any jME class at all and having each class know what to do with it's bytes. Having dumb structures and then fill their values with code somewhere else is for C programmers (who btw eat to much pizza and don't have real girlfriends).
When I come back from work I will get into converting that stuff into something more useful than container objects filled with values…
Bonechilla said:
I'm slightly confused on this comment under bsp i have to find an alternative means to figure collisions other than that already in jME
When I'm done with this I will have the map in many Nodes, not just one, so I think I can later make a general way of figuring collisions for everyone.
The bsp code was pretty much the first thing I played with in JME as I knew a fair bit about them but not so much about JME - so it seemed like a good place to start.
The thing about this code is that it converts a bsp to a variant of a scene graph - whereby each bsp cluster becomes a node that knows which other nodes can be seen from it. There is no hierarchy to these nodes tho - they are all direct descendents of the single parent, which is where I was unsure about the usefulness of it as combining the bsp with other moving objects doesn't seem to work well in my head at the time :? (didnt get that for tho - easily sidetracked so need to get back to playing at it sometime)
Bonechilla said:
I'm slightly confused on this comment under bsp i have to find an alternative means to figure collisions other than that already in jME
When I was trying to work out the texturing problems, I needed to know which triangle I was looking at to get info about it. As we now have a kind of scene graph, I just added a mouse pointer to the scene and used ray casting to find the poly it looked at.
e.g. In the update I added -
if (MouseInput.get().isButtonDown(0)) {
Vector2f screenPos = new Vector2f();
screenPos.set(mouse.getHotSpotPosition().x, mouse.getHotSpotPosition().y);
Vector3f worldCoords = display.getWorldCoordinates(screenPos, 1.0f);
// Create a ray starting from the camera, and going in the direction
// of the mouse's location
final Ray mouseRay = new Ray(cam.getLocation(), worldCoords.subtractLocal(cam.getLocation()));
mouseRay.getDirection().normalizeLocal();
// Use a TrianglePickResults to get the "hits"
results.clear();
rootNode.calculatePick(mouseRay, results);
}
In the same class I had an instance of a TrianglePickResults class, and overloaded the processPick() method (this is the "results" used in the above clip.
TrianglePickResults results = new TrianglePickResults() {
public void processPick() {
// initialize selection triangles, this can go across multiple target meshes.
int total = 0;
for (int i = 0; i < getNumber(); i++) {
total += getPickData(i).getTargetTris().size();
}
// and now do whatever you like with the hits, ideally sort them to find the nearest etc.....
};
I have no idea how useful this is to anyone, and you probably know all this already, but it doesn't hurt to post :)
Tomygun - feel free to use any of my changes in any way you want, but note I just modified the original by Renanse that was in turn based on the one by David Yazel (I think) from the Xith3D Project Group.
I did start doing exactly what you are doing now writing my own loader that was a bit more OO, but in the end it didn't seem worth it as the loader was just the means to get stuff into the scene graph - and pretty much unused after that. So I started concentrating on trying to add the bits that were missing (ideally I wanted to get the shaders working, but haven't got all that far with it ).
It would be nice to have a proper project for something like this somewhere, so if you do set one up - let me know and I'll see what I can contribute (altho I don't have anywhere near enough free time these days tho).
Tomygun said:
I noticed by reading the code and reading "http://graphics.cs.brown.edu/games/quake/quake3.html" that the code does scene graph manipulation! That's absurd! It does Face Culling, and some kind of Frustum Culling or something that figures where the viewer is and worries to much about rendering. That should definitely be done by jME after providing a well structured node tree with all the stuff. I'm going to rewrite most of it as that is not good at all and makes it much harder to work with it.
Not quite sure what you mean there, the problems all seem to run into one another and I am unsure where one stops and the next one starts :D ... can you elaborate?
I'll try to reply with my (very) limited knowledge, and apologise in advance if I'm talking nonsense, but its what I think is correct :?
Converting a BSP file to a .blend . . . AFAIK you can’t directly. I know blender can export to .map format (which is the pre-compilation version of a bsp) but I don’t think it can import either format. q3map2 can export to ASE tho http://en.wikibooks.org/wiki/Q3Map2#Switches and a quick google says there is a addon for blender to import these but can’t say I have tried any of this. There may be other tools out there that might help . . . Bonechilla listed a few (in a post on this forum) a while back, but I never got round to looking at them
No idea. If you treat the map as a single model tho, then I would seriously doubt the frame rate is good… of course that depends on the complexity of the original model tho. BSP's split a map into "areas" and each area has a list of other areas visible from it - they are all you potentially draw, and that's what gives it its speed, but the definition of an area is very much left to the compiler, so you can't assume a room is just one area.
Not really sure what you mean here? Rebuilding a BSP tree (from the original .map model) is a far from trivial process (hell I remember compiling my first doom map and it took forever!! obviously things have improved since then, but its no less complicated :)) , as it modifies the structure of the map in doing so (i.e some single walls may be split into 2 or more in the process if they intersect the partitioning plane).
3) Not really sure what you mean here? Rebuilding a BSP tree (from the original .map model) is a far from trivial process (hell I remember compiling my first doom map and it took forever!! obviously things have improved since then, but its no less complicated :)) , as it modifies the structure of the map in doing so (i.e some single walls may be split into 2 or more in the process if they intersect the partitioning plane).
<>< JOC ><>
Imagine that you have a huge map and you succeeded in loading them but as a single model inside JME 2. Then, maybe you would like to split this single node into several smaller nodes organized like a BSP tree (as I try to do with my portalizer but without any tree), that is what I meant. Thank you for your answer.
Building an efficient BSP tree is a difficult procedure and involves running through many combinations to find the most efficient way of subdividing the map that involves splitting the least polygons along the way. Building a bad bsp tree is less complicated, but is still far from a realtime process. As I mentioned before, I remember the first time I tried to build a BSP for doom (albeit on a 20mhz 386 pc) - it took a couple of days I think!! and that was only a pseudo 3d map. I have to admit tho that I haven't built anything like this for - well a lot of years now, so maybe someone more up to date would care to disagree with me
