[color=rgb(51,51,51)][font=Georgia][font=arial]Long post ahead! This will mention several things. First, I still want to keep working on Meteor Engine but doing it concurrently with a game means I will not put as much time into it as I once did. However I will try to keep you updated in a better manner, so to seperate game progress from engine progress, I will be headlining them separately. (A changelog of my engine is found at my blog if you're interested.) I also want to do more visual documentation of my work. As of now I am a crossroads with my game and trying not to juggle too many things at once. I guess the scope of the project is starting to catch up with me, but I do not want to see this become another piece of abandonware.[/font][/font][/color]

[color=rgb(51,51,51)][font=Georgia][font=arial]Now back to the game. I'm at a point where I have several options to choose from on how to continue on with my racing game. I gave it a temporary name, Custom Racer, for now. It's gotten to where I would have to document and pre-visualise more plans for taking on the various aspects of the development process. Time to break out a pad of paper and start drawing out some stuff![/font][/font][/color]

[color=rgb(51,51,51)][font=Georgia][font=arial]So I have a terrain viewer, some test menus, and a screen system. I wanted to move first to the terrain editor, and I have some idea on how to implement some of the GUI, to activate different states, editing modes, etc. I tried a immediate mode GUI sample that works but I decided against it and just wanted to build on the menu system to make the editor GUI.[/font][/font][/color]

[color=rgb(51,51,51)][font=Georgia][font=arial]But I am stuck on how to write the functions to edit the terrain. More specifically, terrain-to-ray intersection code. It's stumping me. I have a RayPicker class that can cast a ray out from a spot where the mouse is clicked, and it can pick and highlight chunks of the terrain where the ray intersects. Progress! It looks neat and all, but I need to find out exactly where in the terrain the ray hits. I know how to apply triangle intersection code for finer level of picking in the mesh chunks, that's not the problem. The problem is I also want to know exactly where in the triangle the ray hit. Something of that precision is needed for my terrain brushes.[/font][/font][/color]

[color=rgb(51,51,51)][font=Georgia][font=arial]If I limited myself to only picking triangles, the triangle can be any of three points in the terrain. When looking straight down, all the triangles look like right triangles, so I can simply pick the point that is halfway along the longest edge. But I'm still snapping to points on triangle edges. I don't want the brush cursor (and its area) to be limited to jumping from point to point.[/font][/font][/color]

[color=rgb(51,51,51)][font=Georgia][font=arial]I'm using third party code for triangle picking and I don't know what some of its single-letter variables mean, and hoping they have barycentric coordinates so I can project from them the exact location on the map. Looking at this Lighthouse3D article for sample code, it returns a point with two coordinates, but barycentric coordinates have three, so those are probably not the same values (or at least not directly).[/font][/font][/color]

[color=rgb(51,51,51)][font=Georgia][font=arial]Also, I've been fiddling around with the menu system and trying to make it easier to use. This is not as big of a priority as the terrain editor, but some of its components will be used in the GUI anyways. The menu system is a mess of sprite batching, quad rendering, and skin objects with optional XML to load. All Menu components are drawn pretty much outside of the context of the Meteor Engine. Not good, you say, for tight integration, but as they are just 2D sprites that approach will have to do for the time being. Ideally the best way to make interactive menu movements and events is with scripting. But I'm not ready to deal with an added hassle of using a scripting engine. I'm fine with data-driven behaviors for now.[/font][/font][/color]

[color=rgb(51,51,51)][font=Georgia][font=arial]While working on this, I renamed the abstract GameScreen class to ScreenElement. It makes more sense to call them this because I tend to think of a screen as the program's window where everything is drawn, and several of these come together to fill up the screen. I'm deciding whether to make each text element and button its own ScreenElement, complete with transition animations.[/font][/font][/color]

[color=rgb(51,51,51)][font=Georgia][font=arial]This one has been on my list for a while and more to do with the graphics engine itself- how to interact with specific instances of a model. Right now they have no IDs- they're just a number in a list. Great for stuff you just want to set and forget, but if you want to make a hundred boxes and have them all interact as physical objects, there should be a way to keep updating all of their positions.[/font][/font][/color]

[color=rgb(51,51,51)][font=Georgia][font=arial]I knew that way back when, I did get physics to work with instanced objects, and it's good thing I still have the project. It was one of my first 3D XNA projects was some kind of test program with you controlling a ball similar to Marble Blast or Super Monkey Ball, and subject to the laws of physics. It would spit out 5 boxes in different directions which then become part of the world. It was also my first time using BEPU Physics, and thanks to the straightforward sample demo, I was able to get it working in my program quickly.[/font][/font][/color]

[color=rgb(51,51,51)][font=Georgia][font=arial]Looking back at the code I remembered how I accomplished this, which basically was putting in the physical Entity data into my drawing code, and always storing it in a Model. Straightforward for a simple game, but I now want to keep my graphics code and physics code separate. I can't simply make a function that passes both a physics Entity and a Model mesh to create a new instance because then the engine will have be aware of physics-related classes. So I will either make a wrapper class in the game to associate the Entities with the Models, or write a class extension to the engine. The class will also need to keep pumping the Entity data into the renderer to update it on every frame.[/font][/font][/color]

[color=rgb(51,51,51)][font=Georgia][font=arial]That's a lot of stuff I have to think about, but writing it out here helps me in planning it. There's gotta be other programmers out there that tend not to pre-visualize their projects for one reason or another, but somehow must follow through with it.[/font][/font][/color]