3D FPS in MMF2 - Should I keep going? (OpenGL)

Forget it.
The phrase "ten thousand spoons, when all you need is a knife" springs to mind. MMF2 does a lot of things really well, but 3D is definitely not one of them. There are other tools out there which are much, much better suited to what you are trying to do (they will make development easier, and the end result will be far better because they are based on modern 3D engines). I appreciate that you probably want to use MMF2 because you're already familiar with it, but in the long run you will waste far more time and effort trying to get it to do something it was simply never designed for.
I know in theory, there are all these exciting 3D extensions (OpenGL, Mode7, Raycaster, etc), but in practice you just have to accept that MMF2 does not do 3D.

Quote from MuddyMole

Forget it.
The phrase "ten thousand spoons, when all you need is a knife" springs to mind. MMF2 does a lot of things really well, but 3D is definitely not one of them. There are other tools out there which are much, much better suited to what you are trying to do (they will make development easier, and the end result will be far better because they are based on modern 3D engines). I appreciate that you probably want to use MMF2 because you're already familiar with it, but in the long run you will waste far more time and effort trying to get it to do something it was simply never designed for.
I know in theory, there are all these exciting 3D extensions (OpenGL, Mode7, Raycaster, etc), but in practice you just have to accept that MMF2 does not do 3D.

There are some new 3D objects in development, though. If he doesn't mind waiting a while for them to get released, (3-9 months at least, I'd say,) then he could use those.

Wait, what 3D objects? I heard Stephen say something about 3D a while back (Last year) but I didn't know if that was continued or not.

I think that proves my point.
It's hardly to comparable to this: Please login to see this link. (scripting options include Javascript, which is very simple and intuitive)

LavaFlaminG6 has been getting more progress on his 3D game. He's been posting links to the latest version on ClickConverse for me occasionally. It actually has some pretty decent graphics now when compared to what they were before. I'd say at least N64 quality, possibly better.

IMO it's only viable if you pair it with XLua, and even then it's very far from ideal. Jitted Lua is fast, but it's not exactly a first choice for writing a rendering engine.

Hello LavaFlaminG6,

Loading Large MS3D files into the internal storage is not necessary, load each model at run-time.

There is no-way to have the MS3D object handler flip you objects i believe. but flipping meshes with bones in Milk-Shape is not so complicated.

Adding a Sky-box ? in the MS3d system... too easy... and since frog mentioned the N64 here's a skybox in hyrule.
Please login to see this link.
Please login to see this attachment.Please login to see this attachment.

Depending on your operating system; edit boxes may be drawn after OpenGL; but the best HUD achievable would be drawn in OpenGL.

Now i must say i agree entirely with Retriever2, the combination of Xlua and OpenGL is extremely powerful, easily on par with the very popular C# and XNA system.

Also unlike with the MS3D object-handler and OpenGL combination, Xlua and OpenGL includes access to all of OpenGL's awesome features including fog.
( which you might enable such )
gl.Enable( gl.FOG )
gl.Fog( gl.FOG_MODE,gl.LINEAR )
gl.Fog( gl.FOG_START, 64 )
gl.Fog( gl.FOG_END, 128 )
gl.Fog( gl.FOG_COLOR, { 1, 1, 1 } )

To Reduce memory consumption; memory thrashing must be avoided and garbage collection must be handled.
Both these tasks are very easy to accomplish with Xlua.

Memory thrashing in Lua only occurs when tables are declared excessively.

Certain operations such as
returning multiple objects as in 'return a1,a2,a3' produces alot of garbage as it is equivalent to 'return {a1,a2,a3}'
instead tables within functions should be produced as globals and only there pointer should be returned as in 'a={} return a'

garbage collection in Lua is very straightforward but must not be used excessively.
'collectgarbage("collect")' calls the garbage collector into action; returning your programs memory usage to it's current actual requirement.
Beware tho, it can take several milliseconds and could cause visual stutter in your game, i suggest calling it every few-hundred frames right-after switching the visual buffer.

Thanks for your interesting questions. good luck with your project. and seriously next project you should give Xlua - OpenGL a go.

Quote from Nerv

Hello LavaFlaminG6,

Loading Large MS3D files into the internal storage is not necessary, load each model at run-time.

There is no-way to have the MS3D object handler flip you objects i believe. but flipping meshes with bones in Milk-Shape is not so complicated.

Adding a Sky-box ? in the MS3d system... too easy... and since frog mentioned the N64 here's a skybox in hyrule.
Please login to see this link.
Please login to see this attachment.Please login to see this attachment.

Depending on your operating system; edit boxes may be drawn after OpenGL; but the best HUD achievable would be drawn in OpenGL.

Now i must say i agree entirely with Retriever2, the combination of Xlua and OpenGL is extremely powerful, easily on par with the very popular C# and XNA system.

Also unlike with the MS3D object-handler and OpenGL combination, Xlua and OpenGL includes access to all of OpenGL's awesome features including fog.
( which you might enable such )
gl.Enable( gl.FOG )
gl.Fog( gl.FOG_MODE,gl.LINEAR )
gl.Fog( gl.FOG_START, 64 )
gl.Fog( gl.FOG_END, 128 )
gl.Fog( gl.FOG_COLOR, { 1, 1, 1 } )

To Reduce memory consumption; memory thrashing must be avoided and garbage collection must be handled.
Both these tasks are very easy to accomplish with Xlua.

Memory thrashing in Lua only occurs when tables are declared excessively.

Certain operations such as
returning multiple objects as in 'return a1,a2,a3' produces alot of garbage as it is equivalent to 'return {a1,a2,a3}'
instead tables within functions should be produced as globals and only there pointer should be returned as in 'a={} return a'

garbage collection in Lua is very straightforward but must not be used excessively.
'collectgarbage("collect")' calls the garbage collector into action; returning your programs memory usage to it's current actual requirement.
Beware tho, it can take several milliseconds and could cause visual stutter in your game, i suggest calling it every few-hundred frames right-after switching the visual buffer.

Thanks for your interesting questions. good luck with your project. and seriously next project you should give Xlua - OpenGL a go.

Display More

Wow. Sounds like you know more about OpenGL than most of us LOL. Maybe you could consider making a new OpenGL object set...

Hey Frog, Retriever2's very humble, he knows more than I, and his solution to MMF2 - OpenGL interaction is all most impeccable.

3D programs are hard to write, until you've picked-up the widely beloved language Lua.

Quote from Nerv

Hey Frog, Retriever2's very humble, he knows more than I, and his solution to MMF2 - OpenGL interaction is all most impeccable.

3D programs are hard to write, until you've picked-up the widely beloved language Lua.

Well, I've looked at C++ OpenGL code before, and, though I don't understand the code itself, programming OpenGL through Lua is almost exactly the same as doing it through C++. I still think that a new extension would be nice, so that people who don't want to have to learn OpenGL programming or Lua programming (or both, which is the case for me) can still make pretty good 3D games in MMF2.

Yes, that's a very good point.

It occurs to me that i (or someone) could write a Lua - OpenGL 3D engine which exposes it's functionality to the MMF2 event editor.
so long as enough functions are exposed you'll get the full power of OpenGL's commands and there would not be any need to understand or modify the Lua code inside... ( ofcoarse there would be some performance over-head from MMF )

If you are interested green frog, ill see about putting a basic version up.

This is why it's all a waste of time. If you're going to code the whole thing in Lua anyway, that completely defeats the purpose of using MMF2 - it's just going to be far slower and far more work than using a purpose-built, user-friendly 3D game engine (eg. Unity).

I hear what you are saying MuddyMole, and if it we're just a matter of performance i would also purport to the efficacy of Unity ( or Assembly )

but the matter here is a user-base of click-programmers; who have learned alot about programming thru a very effective visual channel ( the event editor ) and who wish to expand there understandings to the very edges of programmings domain; without abandoning this rich environment where learning seems to so freely thrive.

Quote from Nerv

Yes, that's a very good point.

It occurs to me that i (or someone) could write a Lua - OpenGL 3D engine which exposes it's functionality to the MMF2 event editor.
so long as enough functions are exposed you'll get the full power of OpenGL's commands and there would not be any need to understand or modify the Lua code inside... ( ofcoarse there would be some performance over-head from MMF )

If you are interested green frog, ill see about putting a basic version up.

I would be interested. I think some simple support for OBJ loading would be more than enough for just about anything, especially if you could still use the other objects (the other OpenGL collection objects) with it. You'd run a Lua function with the file name (and complete path), X Y and Z coordinates, etc., as parameters. Would that be easy enough, or is it too complicated?

You know, I'd actually settle for basic shape rendering (with textures, setting their X,Y,Z coordinates, and rotations, of course) if it would be a lot easier, since that would be enough for most games. I think that it would need: Cube, Pyramid, Sphere (with a not-too-high polygon count), and, of course, a lone triangle (for those who want to make an OBJ loader themselves). And, of course, it would need compatibility with the other OpenGL objects, such as the camera, lighting, etc. Ya know, now that I think about it, this second option sounds much better...

Some macro functions could work(like renderskybox/loadOBJ functions and such), but it would be impossible to do properly imo. The entire point of event editor is to provide easy to read code.
XLua: Push string param ("c:\3dmodel.obj")
XLua: Push floating param (5)
XLua: Push floating param (10)
XLua: Push floating param (15)
XLua: Call function ("LoadOBJ")

does not look that easy to read and only add more overhead.
It would be simplier to just call the "LoadOBJ" function directly from XLua. But it would be really nice having those macro functions.
And I think Looki made OpenGL Primitives extension that works with OpenGL base, not sure how well does it work tho.

@Frog, your idea of exposing the low-level drawing commands for geometry definition, for putting the defining of models within MMF, is really a brilliant one, the core pathway of rendering objects once assigned models can remain abstracted and optimized

I've started on the Engine
Please login to see this link.

It's got the groundwork down, but it has not yet got object handing / rendering

I'll see about adding those somewhat necessary features tomorrow, in the mean-time... perhaps you could re-load or explain this game you have been working on - as we will soon need a test game to implement.

BigHatLogan, some VERY good points, i shall have to take them especially into account tomorrow when i implement a first attempt at the interface.

The trick i suppose, is getting it into the events as much as possible.

To that end I've been considering a getter and primarily setter, oriented approach; where the overhead for storing lots of variables within locations accessible to the MMF expression editor is internally kept to a minimal.

Handled objects could be created, modified and destroyed based on string identifiers ( in Lua strings are stored as hashes so string lookup is optimized ) these objects would have a spacial location and 3D Model associated with them.

Models would be defined with MMF control, going down to triangles quads lines and so forth, models then-after would be stored in video memory as optimized display-lists. ( so performance SHOULD be okay )

I know it's messy, but as someone who learned Clickteams unique programming methodology long before ever having to type a written program, well, i can fully understand why its worth it to some.

Quote from Nerv

@Frog, your idea of exposing the low-level drawing commands for geometry definition, for putting the defining of models within MMF, is really a brilliant one, the core pathway of rendering objects once assigned models can remain abstracted and optimized

I've started on the Engine
Please login to see this link.

It's got the groundwork down, but it has not yet got object handing / rendering

I'll see about adding those somewhat necessary features tomorrow, in the mean-time... perhaps you could re-load or explain this game you have been working on - as we will soon need a test game to implement.

BigHatLogan, some VERY good points, i shall have to take them especially into account tomorrow when i implement a first attempt at the interface.

The trick i suppose, is getting it into the events as much as possible.

To that end I've been considering a getter and primarily setter, oriented approach; where the overhead for storing lots of variables within locations accessible to the MMF expression editor is internally kept to a minimal.

Handled objects could be created, modified and destroyed based on string identifiers ( in Lua strings are stored as hashes so string lookup is optimized ) these objects would have a spacial location and 3D Model associated with them.

Models would be defined with MMF control, going down to triangles quads lines and so forth, models then-after would be stored in video memory as optimized display-lists. ( so performance SHOULD be okay )

I know it's messy, but as someone who learned Clickteams unique programming methodology long before ever having to type a written program, well, i can fully understand why its worth it to some.

Display More

If you need a test game, I'll make one. Also, can you upload it to a different site next time? Last thing, it seems that you are getting good progress, even if it can't display any 3D shapes or anything like that yet.