Josh

The terrain commands do give you a lot of control. I posted some of the code the editor uses in the BlitzMax forum. Roads are just scripted entities, so you could actually just place and link them with code, although it would be much easier to use the editor.

Cool!

It should be clear how the directories are laid out. There's a "mod" folder in the Leadwerks Engine SDK directory "BMX" folder, as well as a "lib" folder in both. If you still have trouble I suggest reading on the BlitzMax forum about how to install a new module.

Put this .bmx file in C:\Leadwerks Engine SDK and run it: SuperStrict Framework leadwerks.ENGINE Local world:TWorld Local gbuffer:TBuffer Local camera:TCamera Local mesh:TMesh Local light:TLight Local ground:TMesh Local material:TMaterial GCSetMode(2) RegisterAbstractPath( "C:/Leadwerks Engine SDK" ) Graphics(800,600) world=CreateWorld() If Not world RuntimeError "Failed to create world." gbuffer=CreateBuffer(GraphicsWidth(),GraphicsHeight(),BUFFER_DEPTH|BUFFER_COLOR0|BUFFER_COLOR1|BUFFER_COLOR2) camera=CreateCamera() PositionEntity camera,[0.0,0.0,-2.0] material=LoadMaterial("abstract::cobblestones.mat") mesh=CreateCube() PaintEntity mesh,material ground=CreateCube() ScaleEntity ground,[10.0,1.0,10.0] PositionEntity ground,[0.0,-2.0,0.0] PaintEntity ground,material light=CreateDirectionalLight() RotateEntity light,[45.0,45.0,45.0] Repeat TurnEntity mesh,[AppSpeed()*0.5,AppSpeed()*0.5,AppSpeed()*0.5] If KeyHit(KEY_ESCAPE) Exit If AppTerminate() Exit UpdateAppTime() UpdateWorld(AppSpeed()) SetBuffer(gbuffer) RenderWorld() SetBuffer(BackBuffer()) RenderLights(gbuffer) Flip(0) Forever gbuffer=Null FreeEntity light GCCollect() End

By the way, the collision type pair is stored in an iVec2, a new class in Leadwerks3D, which is just a Vec2 with integers instead of floats. An operation overloader allows this class to be used as the key in an std::map, and the collision response is stored as a value for that key: void PhysicsDriver::SetCollisionResponse(const int& collisiontype0, const int& collisiontype1, const int& response) { if (collisiontype0>collisiontype1) { collisionresponse[iVec2(collisiontype1,collisiontype0)] = response; } else { collisionresponse[iVec2(collisiontype0,collisiontype1)] = response; } } The C++ programmers here might find that interesting.

You'll need to copy the contents of the "C:\Leadwerks Engine SDK\BMX" folder to "C:\BlitzMax". There's a BlitzMax module and a static library needed to compile.

CSG brushes will eventually have real breakage. No pre-made pieces have to be made. Scripted breakage of models can still be done the same in LE2, but typically no one bothers with something that requires more work in the art pipeline. I know there are some third-party tools coming out that will create pre-broken pieces for any triangle mesh, and that's something I'll look at down the road, but it's low-priority at the moment. Yes, I was missing one collision response I wanted.

I don't know what the previous constants were, off the top of my head. Debris means small fragments of things you don't want the player to affect, but will still collide with the scene and most dynamic objects. If you play around with Half-Life 2: Deathmatch you'll get a good feel for this. For example, if a piece of wood breaks in half, you don't want the player kicking small fragments around, but they would still need to collide with the scene and large physical objects.

As I was implementing the collision commands for Leadwerks3D, I noticed a few things that illustrate the differences between the design philosophies of Leadwerks Engine and Leadwerks3D. You'll easily recognize the new collision commands, although they have been named in a more verbose but logical manner: void ClearCollisionResponses(); void SetCollisionResponse(const int& collisiontype0, const int& collisiontype1, const int& response); int GetCollisionResponse(const int& collisiontype0, const int& collisiontype1); In Leadwerks Engine, the collisions were left to the end user to define however they wished. In Leadwerks3D, we have some built-in collision types that are declared in the engine source code: const int COLLISION_SCENE = 1; const int COLLISION_CHARACTER = 2; const int COLLISION_PROP = 3; const int COLLISION_DEBRIS = 4; By default, the following collision responses are created automatically: SetCollisionResponse(COLLISION_SCENE,COLLISION_CHARACTER,COLLISION_COLLIDE); SetCollisionResponse(COLLISION_CHARACTER,COLLISION_CHARACTER,COLLISION_COLLIDE); SetCollisionResponse(COLLISION_PROP,COLLISION_CHARACTER,COLLISION_COLLIDE); SetCollisionResponse(COLLISION_DEBRIS,COLLISION_SCENE,COLLISION_COLLIDE); SetCollisionResponse(COLLISION_PROP,COLLISION_PROP,COLLISION_COLLIDE); SetCollisionResponse(COLLISION_DEBRIS,COLLISION_PROP,COLLISION_COLLIDE); Each entity's default collision type is COLLISION_PROP, which means that without specifying any collision responses, all entities collide with one another. Of course if you want to scrap all my suggested collision responses and define your own, you can just call ClearCollisionResponses() at the start of your program. The main difference in design is that Leadwerks3D assumes the user wants some default behavior already specified, instead of being a completely blank slate. That's a design decision that is being implemented across all aspects of the engine to make it easier to get started with.

What are you expecting it to do? Freeing an entity deletes it.

I wouldn't worry about that, considering how many games use it.

If it runs regular graphics, it should work. I don't know enough to say for sure.

My only suggestion would be to install the latest drivers from NVidia.

The engine works really well with BMX, since it is written in that language.

Are your other 3D applications slow?

I don't know. I've never even heard of that.

Oh my god, it's a holodeck. How does it feel when you are walking around, from your view? Do you get disoriented?

Why would you want to use a special tool for scaling GMF files? Wouldn't it be easier to just open the file in your modeling program, scale it to the size you want, and save it?

Do you have a modeling program you can open FBX files in?

Post your map with textures so we can try it ourselves, please.

You have no idea how many people contact me saying "Please don't make me use a converter". I'm just trying to figure out why it's such an issue to some people. If we were loading FBX files straight into the engine, they would be very slow to load, and all I do is drag the FBX file onto a shortcut on my desktop, so I don't understand why it is hard.

You'll have to post renders of the FBX files so I know what you are expecting them to look like. I don't see anything out of the ordinary here.

Some time in 2012.

I can't tell what is going on from your images, but the position of a fixed joint doesn't matter much, since there is no axis of rotation. I suppose it would probably be more stable when the joint is near either body, and not 10000 units away, but that's the only difference I can think of.

That looks right, but I would need to see your scene to try it myself.