OGRE

There was talk of using OGRE engine, and also the question of what the hell BEATengine is.

BEATengine is an engine designed to generate and deform a 3d mesh, and textures/shaders. When it is done, it will be portable to any C++ (not C) program that can interpret it's mesh format (easy to do) or quite possibly anything that can load an unmanaged DLL. (If and when I separate the code to a DLL)

OGRE:

Ogre would be a welcome use for graphics, something i really haven't thought about much beyond making opengl calls.

Someone also said that OGRE would have to be modified heavily to accept a custom mesh format. This isn't true:

* Flexible mesh data formats accepted, separation of the concepts of vertex buffers, index buffers, vertex declarations and buffer mappings


If i remember correctly, it should have something similar to directx's Flexible Vertex Format (FVF), or OpenGL's Vertex buffer objects.

My thoughts?

There is no reason not to use it. Simple as that.

What we really need is someone to work on some form of core "Thrive Engine" which we can start plugging in other engines as they get built. I've started something along the lines of this among the BEATengine code, using a form of "module manager" so the code is already there. We just need someone to modify it to render using OGRE w/cegui instead of AGAR and OpenGL calls. Right now i'm more focused on actually getting the mesh generation of BEAT to actually generate meshes.

roadkillguy:

If you look into OGRE, keep me posted, and we'll discuss just how and where we are going to sit the core of Thrive. If need be, i'll strip down everything non "BEAT"-related and sit it as a callable DLL. I anticipated this happening, so i made the top level (the main loop) separate from the rest of the code.

I've actually been able to get a simple program running! I only downloaded a tutorial, and it's actually a pretty large file so I'm still getting the jist of it. So far, it's fairly simple. I'll look into custom meshes. It shouldn't be too hard.

Ill disect my code today. Encapsulate it into a DLL

I can write glsl shaders, by the way. I'm not too good (I'm shocking at math) but the shader languages themselves aren't too hard. Even the assembly-style ones :3

I was thinking of using say the scripting language we design on (I would say currently either lua or Falcon PL) to build a shader generator that outputs a string for the 3d engine to compile.

Now, for portability, i would say I have a pure virtual function that the bake() function calls which itself calls a function, possibly on the 3d engine, that takes a byte stream to the shader source and returns a pointer to the compiled shader.


So, the creature engine runs a lua script that is passed parameters for a given mesh, the script builds a vertex and fragment shader, and passes it back as a string. I'm thinking script as we can modify the generator script without having to recompile the engine. And also, scripting engines usually have superior string editing capabilities (all sorts of wonderful string functions, like .concat())


Which is also getting me thinking, we'll need to collaborate on some sort of standard interface between various components and engines and so forth.

Being the scale that it is, something like thrive will need many separate engines that all talk to a centralised system and push resources to it.


Papergrape and I actually started writing such a system,

We have a module manager, that holds a heirachy of modules.

Each module has an action() function that is called every frame. as well as load() unload(), enable(), and disable().

load and unload contains memory management code.

enable and disable is used to bring the module in and out of an idle state.
For instance, a module that controls a certain gui widget will ask the gui api to show its window on enable(), and hide the window on disable(). load() and unload() contains code to register and destroy the window completely from the gui api.

Moving on, all modules contain a pointer to an asset-manager singleton, that accepts all the assets spewed out by the various engines, like meshes, and also allows modules write access to existing assets. such as a physics engine module that needs to modify the coordinates of all objects on screen.

This has been mostly separated from the BEATengine stuff, and partially from rendering and api code, and i can segregate it even further, to create a base for the main Thrive core.


Ill also look into setting up module manager to load modules via DLL instead of directly.


Then we can easily throw OGRE right into the middle of things

Will it be possible to run any sort of mesh simplification (dependant on proximity to camera, for easily drawing many objects in game) with these, or will we need other systems?

LOD?

Yes, LOD isn't too hard to implement. you just drop polygons, or call the mesh generator with less iterations

Something like this would probably a little more complex...

You represent the surface as a quadtree and walk further down it the closer you get to the camera. for each subdivision, you displace the newly created points from the tree by a random amount., decreasing the displacement on every iteration.

After re-reading the original post :D:
Is OGRE really necessary then? After all, we are building our own engine.

Well, Ogre is only taking care of the graphics part, this should simplify our work quite a bit.

Commander Keen wrote:

Well, Ogre is only taking care of the graphics part, this should simplify our work quite a bit.

Yeah, I really dont think anyone here wants to write a graphics engine.

Yeah, and I've found OGRE has a LOT more features than just shading.. nevermind!

~sciocont wrote:

Commander Keen wrote:

Well, Ogre is only taking care of the graphics part, this should simplify our work quite a bit.

Yeah, I really dont think anyone here wants to write a graphics engine.

Actually, I'm working on one right now. Yes, this is in pure contradiction to what I said before, but I still am. I couldn't find a decent* mesh class in OGRE, and so I decided to write my own. You feed it vertices, triangles, and call a dandy little function (in progress) to calculate all the normals.

* By this I mean:

I couldn't find a way to look at all the current ManualObject vertex array, so it was hard to write a normal function.

Ubuntu users rejoice! I'll have a binary soon! Now just to upload it to SVN..

UPDATE: I have completed the vertex normal calculation. (It wasn't as hard as I thought it would be :D)

Anyway, now I just have to upload it to the source.. all of my previous projects have been just me