Find Me An Engine?

Yep, too young, I'm afraid. I need something which is robust and stable today.

Why have you ruled out irrlicht when there is already a full working and stable wrapper (well actually its built as a cross platform module) for it?

Just wondering as I am also in the same situation and atm I am looking at irrlicht.

Is there? Frankly, I haven't seen GMan around these parts for ages, so I just figured he wasn't actively updating his Irrlicht Module any more. If I've got that wrong, then I would seriously take a look at Irrlicht, because my only concern at this stage was having to write a huge wrapper for it.

Plash

I think gman has the most recent version of Irrlicht wrapped.

I just had a look. He has the next-to-latest version wrapped, and it does look as though I would need the latest, as it seems skeletal animation was on the CPU until this new release. But he is working on it, so it may well be an option.

Brucey

my only concern at this stage was having to write a huge wrapper for it.

... if you ever need a hand... :-)

well gman is working on it (says on his forum), and the official irrlicht release has only been out like 5 days. He has been pretty damn good at keeping it updates. He (or someone else) also converted all the irrlicht tutorials from c++ to blitzmax, which come with the download package.

I can't see why people can't get behind the irrlicht engine a little more. Given it supports old and new hardware, and is quite stable, has a beautiful editor and loads of third party libs, it seems like a far more viable alternative to Max3D (from what mark has said of it) for the casual gaming market.

Especially given that the most common GPU atm is the intel chip (info taken from the unity player stats), and Max3D doesn't seem like it will be supported for it.

with a flip of a variable you can use opengl, software renderer, dx8 or dx9 for the renderer. Or build your own renderer.

#10

another nice thing about the max irrlicht wrapper is that gman started to wrap the commands into a higher level b3d like functions. But didn't complete it (I think as minib3d came out).

If some people helped him out with that a little it would probably be the all the engine features with the command set we all secretly want.

#11

Hi Gabriel,

i guess you already know what i'm thinking about it but nevertheless let me suggest that you also consider porting the game to Unity for several reasons.

As it looks now Unity will be the best option for 3d casual game developers in the long run if they can afford it. A switch is reasonable in the respect that with the game you could build a basis for further work already. Depending on how your project is built up this might be more or less work (assets vs. code). For instance there haven been quite some Director projects which have been ported over in a reasonable amount of time.

Unity isn't available right now on windows but it will be quite soon. In the meantime you could start getting a feeling for it on the forum, reading the documentation online, asking questions, continue with your asset work/level design, getting familiar with either C#, Javascript or Boo, breaking up the logic the way Unity works.

All the gfx things you have been asking for are available in Unity and work a lot more reliabel than in any other engine i've used so far, so a lot less headaches here. And if they don't, they mostly get fixed over time. I'm not sure about the animation because i don't know how you layed out yours, here is what Unity is able to do.

-> http://unity3d.com/support/documentation/ScriptReference/Animation.html

What you obviously won't get is that it's useable with BlitzMax anymore but you have to weight what's more worth to you. The time you have to invest for learning something new and porting your already done work vs. the time you'll spare yourself with second class 3d engines and how much it's worth to you having built a basis with a reasonable product then.

If you want to stay with BlitzMax i really don't see a satisfying solution right now. Either the engines don't fulfill what you need, aren't really nice or they aren't released yet and you know what this option in practice means, good enough for playing around but in most cases not ready for a larger commercial product. If you just want to get it done with BlitzMax because you primary want to get it out then i'm not sure what to suggest, taking a look at Irrlicht and trying to get along with it, waiting for Max3D or even Flow?

AdrianT

#12

Flow should be out in beta for christmas and should support all your needs. You can try out the scene editor and see if you can get your media in. There are two exceptionaly good 3dsmax exporters for Ogre. Ofusion Pro is commercial and the free community lags behind the pro version, or OgreMax which is similar but doesn't have Ogre integrated into the 3dsmax viewports, and doesn't convert HLSL .FX shaders to Ogres native shader format.

Ogre supports unlimited animation tracks and blending between tracks using either keyframes or weights. Has hardware skinning and you can remove the GL rendersystem, CG, and CG program manager simply by editing the resource.cfg and deleting the files leaving you with HLSL or CG in DX9 and a much smaller footprint.

http://www.flow3d.org if you want to download and try your media media in the editor.

#13

How many people are working on maintaining and enhancing Flow?

Do you more do this as a side project or as a fulltime job?

Do you have any roadmap where you want to go with it?

Mr Errors Writer Man

#14

GMan has updated the Irrlicht wrapper very well thru the years, so I don't think anyone needs to worry about that.

I see that the new version of Irrlicht finally has VBOs. The lack of VBOs was one main reason why I stopped using Irrlicht. Uh oh, and Max3D is going to come out any minute now. I'm tempted. Must. Resist. Reinstall. Someone shoot me in the face!

#15

Taumel: As I said, a visual tool isn't an option. It isn't just a question of BlitzMax codebase. I would consider porting to C# if it gave me a sufficiently good option, but I have far too many low level requirements that just aren't possible in a visual development environment. I could have listed them all, but I figured it was easier to simply say no visual tools and be done with it. I already dismissed Shiva and S2, both of which I already own, for the same reason. Yes, graphically, they're more than capable, but I need a level of control you only get with an SDK. I wouldn't be losing time to port to something like Unity, I would be losing the vast majority of the game features I value most. I'd love to say more, but.. you know.. they won't be valuable features if everyone knows about them.

Adrian: I'm afraid Ogre via Flow3D would fall into the same category as Max3D for me. I need something which is production ready now, not in beta. TV3D is already a few bug fixes away from production ready, and I know it because I have it here working. Anything else would be a step backward.

I dismissed PowerRender for the same reason as Ogre and Max3D. It's very good, but version 6 is a little bit outdated, and version 7 is not production ready.

Irrlicht looks good. The docs are good, I know GMan writes really good wrappers, so I know his work is rock solid. He's already declared an intent to update to the new version and as someone already said, that new version has only been out a few days.

I'm looking into one more today though, Elemental II. It's somewhat overkill, as it has a lot of features I don't need, but it's been ported to XBox360 and PS3, so I assume that we're talking professional developers here.

#16

Hope that you'll be satisfied with Irrlicht then, just keep in mind that you don't have to use the Unity editor at all, beside of the publishing settings for instance. Similar to Flash or Director you can use it but you also could throw almost everything just into one script and generate your stuff via code around you. Obviously you somehow would dismiss the advantage the editor but the option exists. Unity is way more flexible in this respect than Shiva and you also can customize the editor to fit specific needs. Anyway good luck with whatever you choose.

AdrianT

#17

I'm not that keen on Irrlicht although I haven’t really followed progress this last year. Initially we looked at ogre and irrlicht. Back then I got the impression that although there was a lot of enthusiasm in irrlicht the development wasn't very organized, no strict plan, or overal design focus. A lot of things being patched in and fixed later. Kind of what you expect in a lot of open source projects.

Back then different media formats used different animation systems and you had to use a different one depending on what rendering features you required. B3d if you wanted multiple UV's, but no animation support,If you wanted baked lightmaps that was the only format that supported it. Another format if you wanted bone anim etc. And different formats used completely different functions for animation to work. The whole thing seemed like a mess.

Ogre was quite different with a mature, experienced and disciplined core team, a consistent design plan, and very strickt approach to developing and supporting features.

Flow has three developers. Lina, an exceptional C++ fanatic, who's very disciplined and works in a very structured methodical way, picked up Bmax very quickly and thinks its a great prototyping language.

Cygnus who has been using Blitz languages since the beginning, he's a veteran blitz coder with a lot of talent.

I've been the technical artist, having worked in teams on commercial games my role has been more of a producer, and with flow I've mostly been involved with high level stuff like scripting, UI, and assisting in the design and development of flowed and a CAD visualization tool that brought about our requirement for a modern render engine in Bmax.

Initially all our efforts were aimed at a lucrative contract job, so flow as a game dev tool got a back seat. But we spent most of the last year working part time, focusing on turning what we had into more of a game development framework. Primarily for in house use, but feel that its also very useful tool for the Blitz and Ogre community.

We have had a lot of swings and roundabouts, the biggest hurdle has been finding a good C++ coder that also sees enough value in Bmax to stick around and put the effort into developing something like flow. Some of you remember the bad experiences we had early on which have largely been responsible for us not releasing anything sooner. After working together for 2 years now were confident in our teams ability to work together. Were mostly making flow for ourselves to use for contract work, we already had some success and that has been our primary motivation for developing flow. We do think that it’s a valuable asset for both the ogre and b3d communities.

To be honest if Gabriel is in a hurry to get his game out, Flow after 2 years is still in beta which means we think that in a lot of situations it will see you through. But there are still areas that need attention. I do think it's worth Gabriel looking at if he has time over the next couple of weeks. It's likely to remain in beta for a few months yet, once the beta is released we will be upgrading to Ogre 1.6 which was just released, and Newton 2.0 which is itself in beta.

#18

Although i also haven't looked into the latest version of Irrlicht i also would favour Ogre over Irrlicht as a 3d engine. Like AdrianT pointed out Irrlicht can turn into a mess. My problem with Flow, beside of that it's not in a finished state yet, is that it's not developed with the primary focus on it, it's more a sideproduct. I've already experienced how similar products went into a deadend situation and this is something i try to avoid whenever it's possible. Same goes with Max3D if Mark decides to concentrate on making games instead.

Leadwerks

#19

It must be for Windows.
-Yes.

It must be an engine you use with a programming language. I already own a few visual-based programming tools, and they're just not suitable for this project.
-Yes.

It must be useable with BlitzMax. I'm open to wrapping something written in C (easiest) or C++ (slightly harder) but it needs to be something which has a relatively simple API or it's going to be very difficult, if not impossible, to wrap everything.
-Yes:
http://www.leadwerks.com/files/Tutorials/Installing_Leadwerks_Engine_and_Writing_a_Simple_Program_BMX.pdf
http://www.leadwerks.com/files/Tutorials/Installing_Leadwerks_Engine_and_Writing_a_Simple_Program_BMX.wmv

It does not require any audio, video, input, etc components.
-What are "components"?

It must be either DirectX 9 or OpenGL. DX8 is too restrictive on features and DX10 is too restrictive on install base.
-Yes.

It must either have a wide range of shader-based effects or let me use HLSL shaders which I've already written.
-Yes:
http://www.leadwerks.com/files/Tutorials/CPP/Post-Processing_Effects.pdf
http://www.leadwerks.com/files/Tutorials/CPP/Post-Processing_Effects.wmv
http://www.leadwerks.com/files/Tutorials/CPP/Materials_And_Shaders.pdf
http://www.leadwerks.com/files/Tutorials/CPP/Materials_And_Shaders.wmv

It must have robust shadowmapping or let me use my own (HLSL again. )
-Yes:
http://www.leadwerks.com/files/Tutorials/CPP/Rendering_Lights.pdf
http://www.leadwerks.com/files/Tutorials/CPP/Rendering_Lights.wmv

It must have good, cheap (ie:fast) water or let me use my own (HLSL again. )
-Yes:
http://vimeo.com/2411794

It must either reload/recreate textures and surfaces when they are lost or let me do it myself.
-Define "lost"?

It must have robust skeletal animation and at least feature blending between animations. Ideally, it would allow mixing animations.
-Yes:
http://www.leadwerks.com/files/Tutorials/CPP/Introduction_To_Animation.pdf
http://www.leadwerks.com/files/Tutorials/CPP/Introduction_To_Animation.wmv

It must have a means for taking a deformed mesh from the animated meshes, complete with vertex normals, texture coordinates, etc.
-Not exactly, because skinning is performed on the GPU, but you can transform the vertex positions yourself if you really wanted.

Preferences:

Ideally, it should be able to perform most or all of its effects on Shader Model 2.0 hardware.
-SM3 is required.

I much prefer DirectX9 over OpenGL.
-No.

I'd like at least a very basic fixed-function feature set. I've coded a nice flexible system of fallback materials and I don't need much to do this, but it is much preferred that I have this fallback ability. ( It looks for the keyword "intel" in the graphics driver name and engages automatically if it sees it :P )
-No.

The easier it is to wrap, the better. Sprawling behemoths like Ogre and Irrlicht - particularly Ogre - are a huge pain in the butt to wrap.
-Already works with BlitzMax.

I would prefer physics were *not* integrated as integration with the 3D engine usually restricts you from doing some funky things I'm doing. As long as it's optional, no problem.
-Newton physics are integrated, but you don't have to use it. I think our implementation is pretty good:
http://www.leadwerks.com/files/Tutorials/CPP/Introduction_To_Bodies.pdf
http://www.leadwerks.com/files/Tutorials/CPP/Introduction_To_Bodies.wmv

#20

The thing that puts me off the leadwerks engine, and will probabaly be the same for gabe is that am I right in thinking it insists on some pretty high spec PC?

as in will it run on a £200 netbook running on an intel chip? No. So thats the biggest market share gone before you even get started.

Plash

#21

am I right in thinking it insists on some pretty high spec PC?

Other than that, last I fussed with it, it sucked on ATI/AMD hardware.

Lumooja

#22

I think you loose much bigger market share if you make only low end games, because most people who play modern games have also decent hardware and don't buy crappy looking games.

#23

Thanks for the suggestion, but the Leadwerks engine is definitely not suitable. It can't do what I need with deformed meshes, which is vital, and the performance is not nearly good enough on the hardware I'm targetting.

Amon

#24

Gab, I was like that a while back looking for an alternative. The thing is TV3D really is the only option at the moment even with it's bugs, not necassarilly show stoppers, for quality game dev. I'm not in to this editor stuff like Shiva or Unity. Price is not really an issue when it comes to buying Unity but I can't use BlitzMax with it.

Not saying Unity isn't good but merely saying I don't have the coding prowess others have with dealing with curly bracket languages.

Leadwerks

#25

You can't have a robust shadow mapping system that runs fast on old hardware. It's one or the other.

Jeremy Paxman - Yeeeeeeeees

#26

You're probably right, Amon. I'm down another one bug in TV3D, so I'm getting closer to being able to use my first choice. There's still one big one and a few small ones remaining, plus any bugs with the license system. I'm optimistic.

You can't have a robust shadow mapping system that runs fast on old hardware. It's one or the other.

I'm not convinced that's true, being that I feel my own shadow mapping system is fairly robust and performs very well on what you consider old hardware. However, if I accept your premise, I'll drop robustness in favour of performance every time. Without performance, I have nothing.

#27

You can't have a robust shadow mapping system that runs fast on old hardware. It's one or the other.

low-end systems could use normal shadow-maps and sswift shadow's but designing a different shadow system for high and low-end systems would be a huge pain