3d Engines ?

[Wegg]

We have keyframe interpolation, e.g. for models from md2/md3 files, and skeletal based for the other animated formats, namely x, ms3d, b3d.

Oh cool! My character animation package of choice has an .x exporter already! Yay! One thing it doesn't have though is UV and texture export in the .x file. Are there tools/methods that could be use to use .x files as an animation reference to an already textured character?

 

[sindbad]

I'd like to experiment with PySoy or PyOgre on it. Either of those ported would be enough for me.

 

[davidgutierrez]

I haven't looked at PySoy / Soya3D 's dependencies; but if somebody makes a Ogre3D port (something very doable), a PyOgre port shouldn't be too dificult. I love Python, but remember that if you use PyOgre instead of Ogre3D you'll have to spend about 40 MB of RAM in Python interpreter. Those MB could be used to make a better game.

 

[hybrid_irr]

We have keyframe interpolation, e.g. for models from md2/md3 files, and skeletal based for the other animated formats, namely x, ms3d, b3d.

Oh cool! My character animation package of choice has an .x exporter already! Yay! One thing it doesn't have though is UV and texture export in the .x file. Are there tools/methods that could be use to use .x files as an animation reference to an already textured character?

Well, .x supports both UV and texture paths, so it could be easily be done already within one file, also with the other files. But you could also you some other tool to texture map your model. Irrlicht will also get an interface to copy animations over to another mesh. Right now you can add such things manually, so it's basically a question of writing some kind of a loader. However, if you do it this way instead of putting all of this information into one file you'll get an overhead on load time.

 

[squeakypants]

I haven't looked at PySoy / Soya3D 's dependencies; but if somebody makes a Ogre3D port (something very doable), a PyOgre port shouldn't be too dificult. I love Python, but remember that if you use PyOgre instead of Ogre3D you'll have to spend about 40 MB of RAM in Python interpreter. Those MB could be used to make a better game.

Would psyco improve that, or only the cpu usage?

 

[davidgutierrez]

Would psyco improve that, or only the cpu usage?

From the official page:
http://psyco.sourceforge.net/introduction.html
QUOTE
Drawbacks
Psyco currently uses a lot of memory. It only runs on Intel 386-compatible processors (under any OS) right now. There are some subtle semantic differences (i.e. bugs) with the way Python works; they should not be apparent in most programs.


I think you could be interested in Pyrex (the language used to make Soya3D):
http://www.cosc.canterbury.ac.nz/greg.ewin.../Doc/About.html
QUOTE
The fundamental nature of Pyrex can be summed up as follows: Pyrex is Python with C data types.

QUOTE
The Pyrex compiler will convert it into C code which makes equivalent calls to the Python/C API.

 

[sindbad]

Pyrex is probably the best choice here and I've had great results with it. Way faster than java and less than half the code. Cython deserves being mentioned (the bleeding edge version of pyrex).

Also, psyco doesn't have an ARM version, only x86 and it's not going to. PyPy will have JITs for multiple architectures though.

 

[barzoule]

those engines do look nice... but i'll probably end up writing my own (or rather try porting my (deadly slow) gp2x 3d engine to OpenGL ES)

 

[hybrid_irr]

Ok, Irrlicht's OpenGL-ES 1.x version is now functional with an almost complete feature set (regarding Irrlicht's features). Due to non-support of the BGRA extension, the whole color handling has been quick-hacked from the original Irrlicht color coding to OpenGL conforming RGBA. That's the reason why that driver is not yet available to the public - we'll have to improve the color handling in a more flexible way.
The OpenGL-ES 2 driver was then started from the 1.x version (since things like immediate mode were already removed in the 1.x driver). I assume that only the material stuff needs to be ported now (from TEXENV to shaders). The general shader setup should be ok as is in Irrlicht, and information such as transformation matrices are already stored and available to the shaders. So besides the actual shader implementations there's hopefully not much more to do before an initial demo set could be generated.

 

[Chip]

So besides the actual shader implementations there's hopefully not much more to do before an initial demo set could be generated.

Sounds like you guys have everything under control

I can't wait to see some of your demos.

 

[barzoule]

i've just been looking at the irrlicht website and the features and all... looks really good! any estimate about when the ES2 version will be done?

 

[hybrid_irr]

I'm currently redesigning the material setup to allow several variants of the same material (e.g. for fixed pipeline, GLSL, and ASM shader). After that, it's "only" making the shader implementations. But since I need pretty parametrized versions of the shaders, and I'm also just beginning to learn shader programming, it might take several weeks. But since the Pandora chips are said to be delivered not before Q308 I guess I'll make it in time ;-)

 

[DDd]

Do you have a repository that we can check out the source code?

Did i understand correctly that you have a running OGL ES 1.x version running? What is the environment?

This version should run on Pandora... The PowerVR GPU has a driver that runs the OGL 1.x code on top of the OGL 2.x hardware. Also it would be cool to see it running on iPhone or iTouch (both use OGL 1.x GPUs).

 

[Xmas]

Due to non-support of the BGRA extension, the whole color handling has been quick-hacked from the original Irrlicht color coding to OpenGL conforming RGBA. That's the reason why that driver is not yet available to the public - we'll have to improve the color handling in a more flexible way.

Some devices with PowerVR hardware expose the GL_IMG_texture_format_BGRA8888 extension which lets you use the (internalformat, format, type) combination GL_BGRA, GL_BGRA, GL_UNSIGNED_BYTE, with GL_BGRA = 0x80E1. Maybe this is helpful to you, even though support is limited.
OTOH, the bandwidth cost of 32 bit textures is quite substantial on embedded devices, especially those with shared memory, so they should only be used when absolutely necessary.

I'm currently redesigning the material setup to allow several variants of the same material (e.g. for fixed pipeline, GLSL, and ASM shader). After that, it's "only" making the shader implementations. But since I need pretty parametrized versions of the shaders, and I'm also just beginning to learn shader programming, it might take several weeks. But since the Pandora chips are said to be delivered not before Q308 I guess I'll make it in time ;-)

Don't hesitate to ask if you need any help. You could also ask over at the Khronos.org Boards or the PowerVR Insider Forums.

 

[hybrid_irr]

Thanks for the info, that's quite interesting.
Yes, the ogl-es 1.x version is running under the PowerVR emulator for 1.x. However, I need to clean up the code before I can create a branch in the Irrlicht repository. Also, I want to sync with another 1.x driver which had been developed before by someone else. The driver is indeed targeting for iPhone, our Mac maintainer is already prepared to test it, but lacks time currently.
Using RGBA is not that problematic, however it's not easily merged back into the library. And since textures are adapted to the necessary color formats upon load it's also no major run-time penalty to use one or the other format. The memory issues are important, though, which would at least require to make such things optional. Hence, I'll go for just some working version first, and unify the stuff with the official library later on.
I'll definitely search for some help once I have an extensible framework for the material properties. Some shader guys on the Irrlicht forum already helped me to start into the right direction, so I have enough for my initial tests. And the orange book also contains lots of fixed function replacement shaders for a first version. So I'm pretty optimistic that it will be feasible
Once I make substantial progress I'll post here. Until then, please contact me via PM or mail if you want to test some things or if you want to contribute code.

 

[fusion_power]

A little bit Off Topic but I would like to know, whats the Advantage of these "Irrlicht" Engine compared to "Sauerbraten" for example. (I say Sauerbraten because its the only free Engine I have a little bit Experience with, especially the Editor is funny. ^^ )

 

[Holokauston]

A little bit Off Topic but I would like to know, whats the Advantage of these "Irrlicht" Engine compared to "Sauerbraten" for example. (I say Sauerbraten because its the only free Engine I have a little bit Experience with, especially the Editor is funny. ^^ )

Sauerbraten is a game engine while OGRE, Irrilicht etc are 3D engines, Sauerbraten is designed for FPS games, much like the Q3 engine, OGRE and Irrlicht are designed just to handle the 3D part of an application, this way you create the game engine yourself, for ex. a MMO or RPG engine looks different from a FPS engine, so using Sauerbraten for an RPG might be tricky since you would have to redesign the engine anyway.
If you create a MMORPG game engine with OGRE, then OGRE is just a part of it that handles the graphic part while use have to add something to handle sound, networking, character creation etc.

Sauerbraten is a finished game engine that you just add models and skins to, if you're designing a FPS game this would be much faster to use.

As for advantage, depends on what you are building actually, a FPS Sauerbraten would probably be a much faster and "better" way but using OGRE you would create the game engine yourself and there by have more control over what you want it to do and not have to follow the "Sauerbraten way". =)

EDIT: I see that Sauerbraten engine is being used for a RPG game but the difference still stands, ORGE and Irrlicht are just graphic engines while Sauerbraten is a game engine

 

[hybrid_irr]

I'd say Sauerbraten is a game engine which targets at a very distinct type of games. Maybe it's even not really intended for creating completely separate games (at least that way my impression when reading the intro on their homepage).
Irrlicht is a general purpose 3d render engine, hence no direct support for physics, network, audio, ... But it's applicable in a very general way. Many of the 3d apps created with Irrlicht are no games at all (but e.g. CAD tools).
Moreover, Irrlicht explicitly targets smaller systems (e.g. with its software renderers, specialized device types for mobile and embedded systems, ...). And Irrlicht tries to provide an intuitive, consistent, and easily extensible API.
More suitable alternatives would be Ogre3D or CrystalSpace, but both are LGPL'ed while Irrlicht uses zlib license.
Ok, I hope I don't start flame wars now from all the other engines. I cannot say much about them, so I just leave it as is. The only thing I can say is that it is feasible to get Irrlicht running on the Pandora, and that's what I'm trying to achieve currently

Ok, you beat me to it

 

[fusion_power]

Ah, OK. Yes I should known the difference between "GAME Engine" and "3D Engine".
I have a little bit Experience with BLENDER so I think Irrlicht goes more into these direction than Sauerbraten.
Does Irrlicht support ".blend" Files from Blender? Blender is very crappy to use but now that I have a little bit practise with it (only modeling) maybe I could try Irrlicht in the future?

 

[hybrid_irr]

No, because .blend files are not really an interchange format. But there are many exporters which do properly export all stuff from blender into Irrlicht.