next »

[flavio]

EDIT: To convert your file into an egg file, it seems like the developers (I know it's open-source) could have included a simple function that would have just checked to see if an egg file exists or is old, and if not, convert the mesh you specify into an egg file.

Would you prefer to do the conversion mesh->egg during the game execution, and not offline, really?

In release, this function would just load the mesh file.

In the "release", the egg is (automatically) converted to an optimized format (bam). And the function which loads the models loads egg or bam files depending on the context (i.e. if you are in the runtime or not).

[SolarLune]

Would you prefer to do the conversion mesh->egg during the game execution, and not offline, really?

I'd think so, yeah. It seems like the more that you don't have to worry about the better. Rather than running a tool to convert my mesh file to an .egg file every time I change it and then load up that file into the engine, I could just write a function to load up my mesh file in the engine. I wouldn't mind waiting for the process - I'd know what's going on. It'd only happen the first time, and it's still faster than doing it myself.

I forgot about the bam file, though.

[flavio]

I'd think so, yeah. It seems like the more that you don't have to worry about the better. Rather than running a tool to convert my mesh file to an .egg file every time I change it and then load up that file into the engine, I could just write a function to load up my mesh file in the engine. I wouldn't mind waiting for the process - I'd know what's going on. It'd only happen the first time, and it's still faster than doing it myself.

Unfortunately, the process which converts models to the format of the engine is not so straightforward, often there are many attempts before getting an output file which can be actually used into the game. And typically an artist would like to check how the file is converted and how it will be seen into the game. So, it may be possible to have artists who prefer to have this phase in the pipeline, and not in the engine.

So, there are reasons to place this step in the pipeline, anyway you could want to automatize the step of recreating the egg file when you modify the blend one, so in your build script (for example a SConstruct file) you can define a builder which detects if a blend file is modified, and in that case it invokes the Chicken Exporter and produces automatically the new egg file.

If you want this inside the engine, you could override the method which loads the model, invoking the exporter if needed. And this is exactly what you wrote at the beginning, so my words are only a different point of view about the reasons of where to place this step.

PS We are definitely OT, sorry.

[Mikademus]

I will add most systems mentioned to the list. In particular I think that Cube2, ioquake3 and 3D Game Studio should be included, and Game Core should be removed as dead.

However, 3D Rad (Rad3D?) and DXStudio seems to be visual editors. Since I had to prune the OP to make room for more entries a while ago the sentence "this is about programmatic game engine solutions, and therefore non-programmable systems such as Rad3D will not be considered" was cut. Amusingly enough then Moi suggested 3D Rad

So the question is, should we include and cover them, too? Or should it be in a sister thread? I think we really need to move this to a wiki format soon, because the forum limitation of 20kb posts is a bit too restrictive.

@Yaio: Np, some OT is OK as long as it doesn't start to dominate the thread since it can go to show how a system is to work with.

[moi]

didn't read the whole OP,but people interested in 3d engines should definitely consider these options.

[flavio]

I "vote" for a sister thread: there is a big difference between engines and editors. Separating them will imply that each thread would be cleaner. Besides, you could link at the beginning of the thread the other one, so if a reader is looking for the other thread actually, then she will be redirected.

[OscarRPR]

Hello everyone.

My team and I are considering design videogames for mobiles, especifically Android and iOS, but at this moment we want at first go with Android, but we encounter that in a previous games we spend a lot of time design some systems that cost us time which could be expend in more gameplay features. So, we think that it's best to use a engine for this, but because of our budget we decide to go open source in that area, so Unity is out.

We already check out AndEngine and Rokon, but in some many pages we find different positions from the concept and not from the point of development, so what open source game engine for Android is the best?, based on experience?

Thanks a lot..

[zine92]

I see that jmonkeyengine wasn't mentioned. It looks quite promising with opengl as renderer and uses java for scripting. And yeah it's open source as well.

[moi]

UDK barely runs on my computer and it's become a bit too complex to mod if you're not engaged in a huge AA project.
Also the lighting model went to shit again. The lighting model was shit in UE1, a bit improved in UE 1.5 (ut2k3), GOOD in UE2 (UT2k4), back to shitty in UE3 (everything is blinding shiny and nothing projects shadows anymore)

[UPDATE] I recently  realized my current integrated video device (geForce 7025) was totally shit, it was actually worse than some video cards I used ten years ago (lol). So I bought a cheap entry card and now UDK works flawlessly and the lighting is awesome, probably the best lighting on the market.
So despite the complexity of the modding process, UDK will probably regain first place in my little palmares.

But still I encourage people to take a lok at DX engine, it's amazing , and FREE.
It's like gamemaker but for 3D, only problem is you have to search deep for documentation but it's there.

[SolarLune]

Hey, Moi, you seem to like DX Studio, which has me looking at it. What's one of the big features about it to you? I think that while there's no cross-plaform editor, there is capability to use the Player on Mac, Linux, and Android.

[moi]

It just works nicely and is easy to edit. and has all the features that I consider essential for a 3D engine
The only problem is that there is no optimization for performance such as cached meshes and BSP and stuff like that, so you have to make a bit of background work to make complex scenes work smoothly.
also: it's free.

[SolarLune]

Hey. I'm currently checking out jMonkeyEngine 3.0, and it's looking pretty good. It's an open-source Java-based OpenGL-rendering game engine, and appears to be cross-platform as all get out. Graphically, it's impressive, and it comes with a lot of demos. I'm not versed in Java at all, but I'm willing to look into it. It seems like it's fast enough for a lot of different games, and I'm liking the 'node'-based scenegraph(?) approach (which, I think is pretty standard, but still).

EDIT: It also seems to have direct .blend file loading support, which is awesome. It's in Beta right now, but it seems to be extremely complete and have quite a few features that some engines don't even come close to having. In addition, some impressive games have been made with it, as you can see below.

Showcase Video

P.S. The :47 mark of that video is something that I would want to play now. :D

EDIT 2: P.P.S. It's also got a kind of scene editor, though I'm wondering exactly how it ties into the game... I guess I'll just have to find out.

[Schwiggy]

jMonkey is pretty good  . When I took a class on Java I was trying it out on my own time and that was when it was 2.x, people were regularly making stable commitments to the SVN and solving problems and bugs within a week of being reported. And that version was being used for commercial MMO's already.

[eyeliner]

I'm trying to get to grips with DX Studio, but the community over there is... stale as mold...

FFS, a company should at least make the forums active. Though the manual is alright, some tutorials are incomplete or are horribly outdated.

[bart_the_13th]

Well, DX Studio seems compeling enough to me, it got the postprocessing shader that unity free version lack of. And it also use the same encapsulation(OOP) style programing just like flash(AS3) and unity(JS/C#) do. Maybe I'll give it a shot.