Choosing a 3D engine

Community Forums/General Help/Choosing a 3D engine

Yasha(Posted 2012) [#1]
So I'm having a little problem with indecisiveness...

I need a 3D engine for the next project I'm working on. It needs to work on mobile devices, it needs to be open-source, and I want it to run on as low-end devices as possible because volume is more important to me than detail at the moment.

Unfortunately, I just don't have the experience to make a satisfyingly informed decision for myself on this matter, and also have difficulty in part because the main competitors seem pretty evenly matched (which I guess is good since it limits the damage of a poor choice). The big names in the open-source engine scene seem to be Ogre and Irrlicht. Has anyone had any experience using these?


Things to consider (or at least, things I think are worth considering, in my idiot way):

-- Realistically, how low-end do devices get in 3D terms? Will Ogre continue to perform adequately for simple scenes on weaker cards, or does it have a minimum threshold it needs before it will work properly? I can't find a satisfactorily clear answer to this.

-- In contrast, Irrlicht supposedly performs beautifully on low-end devices. Does this have negative consequences on higher-end ones? Does this have negative consequences for long-term support? I have heard that the Irrlicht architecture is quite chaotic (I have no idea what that means, not being a pro 3D engine author myself) and difficult to update compared to Ogre.

-- As a long-time B3D user, the whole fixed-function vs. shaders thing is largely baffling to me. I still think in terms of surfaces, vertices, textures, and CPU manipulation. How deprecated is this? Is there anything still on the market where the FF pipeline needs to be used instead of the shader one? Would using it cut a program off from running properly on high-end devices like an iPad? If both schools of thought are still current, is it even possible to make one program perform well on both kinds of device?

-- By extension, is it better to pick more than one graphics backend and target different devices separately?

-- As a long-time B3D user, I also think (for higher-level scene design) very much in terms of B3D's Entity system. How well does this map onto other engines? How much do scene management metaphors vary? Is B3D's system outdated, or quite standard?

-- I want a high level of control. Now it's clear that at the moment I have no idea what I'm asking for control over (do we still use CPU vertex manipulation in the real world?), but I want to be able to have my own code get in there and tweak the system as and when it is ready to do so. Is this feasible? Do engines exist that are very hackable at the application-level (i.e. I'm happy to recompile the engine if I have to, but I'd rather have access to a large number of medium-low level commands as well as the simple ones).

-- Features I want (note: not features I need, because I don't know how obsolete the things I want are and they may be a bad way to do things) include the ability to edit textures, the ability to quickly edit meshes on a per-vertex basis (e.g. B3D's CPU vertex control is good enough for frame-by-frame animation if you want), and control over medium-level things like the stencil buffer (because I'm too stupid to realise shaders are how to achieve that). Given those, things like file format support are a bit of a nonissue since writing a loader for a custom format becomes comparatively easy.

-- I don't "do" C++ (as some of you may have gathered from my multi-page rants), and will be writing either in C or through a C FFI. While wrapping the commands is no problem, assuming it hasn't been done (it's no problem to convert "o.meth(x)" into "meth(o, x)"), and it probably has been done, the nature of the API may be tailored to different application design philosophies, and I would rather like to use one that's more friendly to being wrapped and abstracted in this way.

-- I say Irrlicht and Ogre because they're what I know exist. If anyone has any other recommendations, I am interested. The open-source requirement is non-negotiable - it has to be a permissive-free-software licence (think BSD, zlib - not GPL) to comply with my needs for this project. Obviously I don't mind considering proprietary engines for use in the future, but they aren't suitable answers to this question.

-- I do know the difference, blurry as it is, between a rendering engine and a game engine. I am after a renderer that can be used in games, but I don't mind supplying everything other than the 3D with other libraries, and in fact would probably rather do that. I like minimalism.


I know "Ogre vs. Irrlicht" is a very dead horse, as is "pick me a 3D engine", but I hope I've supplied enough context to make this question a little more answerable.

Last edited 2012


AdamRedwoods(Posted 2012) [#2]
Have you considered minib3d+monkey or is there something that dissuades you? I know it's still in its early phase, but the number of targets it works on is impressive. Although I did encounter a few earlier android phones that it does not work on.

http://monkeycoder.co.nz/Community/posts.php?topic=3211

Fixed function pipeline is much faster on mobile devices than custom shaders, so early opengl still stands, and works on just about all android and ios devices out there.


Yasha(Posted 2012) [#3]
I'm not currently a Monkey user, so I didn't really think of it.

With the greatest respect to Si, I also have... reservations... about miniB3D (BlitzMax) and iMiniB3D (I have read and, I hope, understood the full source of both of those), and was hoping that there were optimisations that another engine might make (e.g. octrees? portal rendering? fast matrix math and no Eulers? I actually don't know, my opinion on this matter is probably worthless).

Anyway, worth a look. Good suggestion, thanks.

Also, added a point of clarification to the above re. FF features I want. I'm very much "locked" into the fixed-function way of thinking.

Last edited 2012


Kryzon(Posted 2012) [#4]
-- As a long-time B3D user, the whole fixed-function vs. shaders thing is largely baffling to me. I still think in terms of surfaces, vertices, textures, and CPU manipulation. How deprecated is this?

It's not deprecated, you still have surfaces, vertices, textures and all that.

The difference is that adding shaders gives brushes a 'local' configuration of rendering.
With Blitz3D, every single brush has 'shininess', 'fullbright', 'alpha transparency' and other visual parameters. This can be understood as "every single brush is being rendered by the same shader code" - the shader that's used by the fixed-function pipeline.

Now that you have programmable shaders, each brush can have custom parameters, for instance, 'normalMap', 'refractionStrength' - virtually anything the programmer wants. This is why shaders are essential for next-gen fancy visual effects.
You code the way you want the visual elements of the brush to be related. Maybe you need an additional parameter for the aliens in your game, a 'glowStrength' float value.
You can also have very small shader code for meshes that are very simple to render - say, an opaque mesh that never uses 'alpha transparency' or 'shininess'.

You don't need to worry about shaders, they do more good than harm.
You do need to get familiar with them: most devices run on OpenGL ES, which is a special version of GL that's purposed for embedded systems, and with this you'll not have access to a fixed-function pipeline but you can most certainly reproduce the same functionality.
There are various tools out there that produce "fixed-function like" shader code, which is a single shader program that contains several parameters such as 'shininess', 'alpha transparency', 'flat-shading', 'vertex-colouring' etc.

In your case, you would assign to all 'brushes' (or 'materials', or whatever container your engine uses to store visual parameters) the same shader.
This is the precisely the same as using a FF pipeline, same parameters\rendering scheme for all meshes.

Last edited 2012


Kryzon(Posted 2012) [#5]
As for do-it-all engines, these come to mind:

Maratis3D (free; open-source)

Cocos3D (free; open-source; iOS only)

GLBasic (commercial; closed-source)

Esenthel (commercial; closed-source)

Shiva3D (commercial; closed-source)

CryEngine (commercial; closed-source)

UDK (free*; closed-source)

Leadwerks3D (unreleased, TBA)

More here: Cross-Platform Engines


*Free for non-commercial projects.

Last edited 2012


Yasha(Posted 2012) [#6]
I've heard of Maratis, but with a lack of reviews I wasn't sure what to make of it. If you give it a personal recommendation, I guess I will give it another look. It markets itself as something to use through Lua... And I want that tasty C FFI. (Of course, a Lua FFI probably pretty much is a C FFI...)

I was aware the people behind Cocos 2D were working on a 3D engine, but for some reason I thought it was a way off delivery. I'll give it a look... Even if it is iOS only, it can't be bad to investigate.

The others I can't use. Unfortunately FOSS is a "business requirement" for this project. I'm as excited as the next person about Leadwerks though.


If I understand post #4 correctly, I can pretend to have a FFP if I want for little loss of performance, then? Handy stuff. That way the whole shader issue becomes something I can choose to adopt more gradually, then. And more importantly I assume that means any GLES systems offering a FF-like interface are likely just wrappers with a reasonable service life?

Thanks for the explanation!

Last edited 2012


Kryzon(Posted 2012) [#7]
If I understand post #4 correctly, I can pretend to have a FFP if I want for little loss of performance, then?

I lack the evidence, but it would actually be a bit faster than your average next-gen shader, since you wouldn't be using the complex calculations necessary for effects like normal-mapping, per-pixel lighting, blurring and others.

This FFP-like shader program would probably cost a bit more memory - you have to include all possible visual settings you want (like Blitz3D's FX flags), and this involves more code than a shader that exclusively performs a single kind of visual.
If I'm not mistaken, the keyword for this is über-shader, a bigger-than-average shader program that has several parameters so it can be used to render a whole lot of meshes and allow different visual effects by tweaking parameters.
It is viable for production use; this is the most important part. Your biggest concern will probably be the general performance of the game, keeping that FPS steady.

--

This is all very low-level. Most likely the engine you pick will already come with a pack of shaders that you can mess with, or some high-level material interface (like B3D Brushes) that takes away a lot of the hard work.
Once you're familiar with the engine, you can build your FFP-like, über-shader program and refine it so it's almost equal to a Blitz3D Brush, with multi-texturing, texture-blending, and down to the names of the parameters (shininess, alpha etc.).
When you find an engine you're comfortable with, you can post here so we look further on how to do that.

Last edited 2012


Captain Wicker (crazy hillbilly)(Posted 2012) [#8]
GameKit
http://code.google.com/p/gamekit/
just try it
there are
http://sio2interactive.com/ 'not free
http://www.stonetrip.com/
http://rzr.online.fr/java.htm
http://www.appgamekit.com/ 'not free
http://www.monkeycoder.co.nz/ 'not free
pick one already! :P

Last edited 2012


*(Posted 2012) [#9]
I would use monkey for 3d to be honest like max there is no official 3d module, minib3d does a lot to redress this but the reason I didnt use it was that its flaky on intel gfx chipsets so rather tjan have tons of email from disgruntled low end purchasers I went with Unity. At the time they were giving away the iOS and Android licenses free I dont know if they are atm though.

Monkey's 3d is rather like BlitzMax's you could roll your own engine or wait for someone to make one that works on as much as possible, OR you could look to other engines that are available at the moment and choose one of those.


Yasha(Posted 2012) [#10]
If there's no single good answer to the 3D question for Monkey, I think that means it's not much of an answer to this question, hmm? What am I then using it for?

The main thing about choosing an engine is that I was hoping someone had insight into what the APIs are like (so ...the main thing other than performance and whether it works at all, anyway). For instance, how stuck are you if you don't want to rely on the native mesh loading or want to do crazy custom animations? Blitz3D's vertex and pixel access was easy and fast enough that if you needed to, you could simply write a new mesh or texture loader at the API level, or even an animation system (I'm guessing for animation, vertex shading has taken over at lest some of the workload, but the point about accessibility of the manipulation is the same).

Wicker's GameKit suggestion is what actually inspired me to ask this question in the first place (after it was mentioned in General Discussion) - at the time, I hadn't realised it supports both Ogre and Irrlicht versions and therefore might actually showcase the differences and relative strengths fairly well. Will need to take a look.

If I can interpret Kryzon's answers as meaning that in terms of literal ability to run, there should be relatively little difference, than it might make anything I get from a simple test site more meaningful. So I will probably do that (I'm not eager to devise tests for systems that I don't know - there's too much I will miss, but maybe something will be learned).

Last edited 2012


Naughty Alien(Posted 2012) [#11]
http://gameplay3d.org/


Captain Wicker (crazy hillbilly)(Posted 2012) [#12]

I might try that. Looks promising! ;)


Kryzon(Posted 2012) [#13]
GamePlay3D and GameKit look great indeed, thanks for sharing.


Steve Elliott(Posted 2012) [#14]
For mobile devices I'd go with GL BASIC, but the language is so old school it's not for me, even though I bought it lol...not bought monkey so couldn't say what 3D Engines could be used.