Merging Meshes

You guys are gonna hate me.  I am really new to Java, JME and OpenGL in general.  I have been programming for years (QuickBasic > VB4-6 > C > ColdFusion > Actionscript > C# > Java), but never anything in 3D… (stop gritting your teeth!)  I mainly deal with multi-threaded number crunching apps and recently alot of training material in Actionscript/Flash for a living now and I’ve always been fascinated with 3D programming.  I’d love to be able to use it in our training to enhance the learner’s reception.  (That whole educational gaming field is what I’m being asked to delve into)  I started looking into Papervision on AS3 and it just doesn’t have the horsepower for what I’d be looking to do.    JME’s scenegraph(?) structure makes sense to me and I figured I’d start here.  Java itself is not hard to me… just the new aspect of thinking in GL.  I have read up on 3D programming (OpenGL on C mainly) over the years and most of the terminology is not foreign to me, but I will never claim to know it all.

Playing around, I’ve created a simple program to draw a whole bunch of boxes to create a sort of 3D maze.  (15,000 boxes to be exact, but I think I can add more if I merge these  }:-@)  I don’t know what it would be called, but I am adding a Box to the rootNode, and moving a box width on either the x, y, or z axis depending on a random number.  The problem is, I want to place a camera/character inside this collection of Box objects and be able to move from Box to Box.  Now, when I create the boxes, it of course creates all six sides and I was wondering if it’s possible to detect face collision and remove the faces that are in the same coordinate space.  I figure I would have to place all the boxes, and iterate through each one removing the faces and create one huge mesh.  Right?

Edit:  Here is basically what I’m doing with the boxes…

Welcome to the jME community! :slight_smile:

Merging meshes can be done with geometry instancing in jME, you can find a test (somewhat like a tutorial in jME) in the package jmetest.scene.geometryinstancing, and some more documentation about it on the forum.

Look for "GeometryBatchCreator" and "geometry instancing", and you'll be in mesh merging heaven!

About the face-removal thing, wouldn't it be better (faster) to pre-create your maze structure (something like a 3d linked list springs to my mind here), and then just add the "walls" as squares (Quad in jME-terms) where they are needed? That data structure can also later be used as a cheap substitute for collision detection, and/or culling. (Great, now you have me thinking about re-inventing BSP for the rest of the day  XD )

You’re probably better off creating larger structures than boxes and then making use of sharedmeshes/nodes, locking and a good culling algorithm.  As you can see from this screenshot, you can go a long way with that (and this was on a older machine with an older card, fwiw)

I did turn the box into a instanced object using the GeometryBatchCreator and could duplicate it about 50,000 times (I tired 100,000, but I ran out of memory … oops.)  And the SimpleGame renderer couldn't fit the entire object on the screen because of the view distance (which isn't a problem since I don't expect the "player" to be able to see the entire length of the thing.)

@renase:  I guess I don't understand why it would matter if I made them boxes or complex structures (except that complex structures would have "openings" designed into each side of them.)  However, then your stuck with an object with a bunch of doors that lead nowhere and should be covered somehow.  Unless I don't understand what your saying.  You'd still have to determine what object to place.  (ie: Room_NE, Room_NEWS, Room_NW … signifying what openings the "room" has.)  Is this how you did that?  If not, how did you open up your hallways to each room?

Well, I'll just go into the reasoning for complex objects…  Your video card likes to receive data in larger chunks.  Also, this decreases JNI overhead (fewer calls).  But you're going that way with your idea of combining meshes.

Do you really need all of your rooms in memory at once?  Why not load them into memory as you get close and remove them from memory as you move away?

No, I can load them as I need them, but I was fooling around and wanted to find a way to remove the faces and simplify the mesh.  It's more of a test for me than an actual product goal so I wanted to see if I could do it.  I guess the preferred method would be to build up an array or track a list of "room coordinates" and draw the walls as needed from what you guys are saying.