Irrlicht Engine

1)Support for OGL 2.1
2)More primitive node (addPyramidSceneNode, addBoxSceneNode (with draw3dBox is not posiible to texture the box,ext..))
3)Support specular light and antialiasing also in OGL
4)Improve pcx loader (?)
5)Support materials for md2 model ()
6)Support for md3 models (there is a patch!! Just include it in the irrlicht release!!!)

Bye all

1) Man, why always the same old story. The version of OpenGL supported is determined by your gfx card driver. If it provides ogl 2.0 you have ogl 2.0, if ogl 2.1 you have ogl 2.1. Irrlicht can use or give access to features provided by those versions, nothing more. So if you want features in then request (or better provide patches to use) those. But your request is nonsense!
2) Why not use CCubeSceneNode, it is a box And if you provide an implementation for such primitives it would be possible to add them.
3) Speculars are working with OpenGL Aliasing under Linux is implemented, but not yet tested. And for Windows I hope to get a patch by the end of the month. So yes, FSAA for OpenGL should be in the next release.
4)What's the problem?
5) Did you use my patch for 1.0? But .md2 only use one texture so it's rather simple to add it manually.
6) But it's a rather large patch (and yes, sice I'm hosting those patches I'm aware of its existence ). And the additions to IAnimatedMesh are also not neglectible. So it's just not as simple as you think. But you can use the patch meanwhile.

My plans for the next version are (besides FSAA and bugfixing) the additional geometry render methods (quads, triangle strips, lines, etc.) and thereby also rewriting the s3dvertex interface and integrating IIndexBuffer for 32bit indices from IrrSpintz. Though this is not for sure to be done until 1.2 Ah, and spot lights

Any other requests or plans?

2)More primitive node (addPyramidSceneNode, addBoxSceneNode (with draw3dBox is not posiible to texture the box,ext..))

I think there should be a geometry generator class that makes has methods createSphereMesh, createCubeMesh, createPyramidMesh, ... and each of those methods return an IMesh. Then there is no need to keep adding new scene node types. Just add a new method to the mesh generator and viola...

I would like to see the platform specific code removed from the video driver and into a platform specific window class. This would help to clean up some code duplication and the OGL driver. I'd also like to see an OGL 2.0 driver implemented just to get rid of all of those ARB function pointers.

I suggested to provide a meshbuffer generator which creates thos primitives. This would save another additional structure when using the primitives in the mesh loaders!
Which platform specific code do you mean? The windows part which does the context creation? This has been moved to device creation for Linux, which is also quite confusing. You have to do quite a lot of driver checking to choose the correct window and device setup
I think that a dedicated ogl 2 driver would be too much duplicated work. And skipping the additional methods and function pointers is probably not possible because several card drivers which claim to be OpenGL 2 conformant do not provide all necessary functions such that checking has still to be done. If all those methods are properly inlined it should even be useable without performance loss. But yeah, it's quite tedious to add all additional structures to add just one new OpenGL method

the idea of the mesh generator is very cool!!

Man, why always the same old story

I intended to say the support for the new features of OGL 2, like new shaders language. GLSL 1.5 is old. i know that OGL is a set of functions, and new release means new function or new ARB extention integrated in the standard

Why not use CCubeSceneNode, it is a box And if you provide an implementation for such primitives it would be possible to add them

i want a box with x dimension different by y dimension, not a cube.

So yes, FSAA for OpenGL should be in the next release.

why not in windowed mode? the possibility to choose the dimension of the matrix for the supersamplig is cool

i have some problems to load a pcx file. the gimp load it correctly, but when i call driver->getTexture, it return a NULL pointer, i'm building a demo. I publish it as soon as possible

an other request: radiosity!!! like quake 2 engine. i know that its implementation is very, very,very,very,...... hard, but it can improve the quality of the light a lot!!!

I've said it before and I'll say it again:
fresnel water - reflections and refractions etc

this is a my demo that show that pcx image loader in irrlicht is bugged.
You can download it from here (590kb): http://xoomer.alice.it/mancusoraffaele/pcx_demo.zip

irrlicht return an error message like "unsupported pal indicator". the demo uses irrlicht 1.1. Please not that pcx files that i can't load with irrlicht are a lots, but for the demo I choose a single small file. PLease also note that on my computer the program "the gimp" load correctly the pcx file.

Bye

hybrid said:Speculars are working with OpenGL

in my game and on my computer specular hightlights works with OGL. So
there is an error in irrlicht's documentation, at "irr::video::SMaterial::Shininess" paragraph (copy and paste, no modify):
"If set to 0, no specular highlights are being used. Currently, specular highlights are only implemented in the D3D9 and D3D8 driver. To activate, simply set the shininess of a material to a value other than 0"

MD5 file loader...

Mancuso Raffaele wrote:an other request: radiosity!!! like quake 2 engine. i know that its implementation is very, very,very,very,...... hard, but it can improve the quality of the light a lot!!!

??
Radiosity is best off used in content creation and making lightmaps.
I don't get how it would be implemented as part of the engine.
A radiosity solution is calculated prior to rendering and is global, so if you wanted the engine to do that (at loading time, prior to the scene being draw??) you would need much more precise lighting tools in the engine as well to get decent results.


My request: *.fbx support
IMO, better off to go with more pro formats rather than some of these archaic and obscure ones ("Ogre" format (?))

Here's a very easy request.

How bout adding a static method on the irr or video namespace for something like

(psuedo code)

public static bool IsSupported(E_DRIVER_TYPE myDriver){}

(/psuedo code)

That way I can check to find out which of the various drivers for Irrlicht is support on the client's machine. Otherwise, I normally just provide all of the drivers to pick from in a settings configuration. But it would be nice, if I could limit the list of available drivers to only the ones that work on that computer.

I know I could use Try Block catches and try to createDevice using each of the driver types, but it seems poor technique to do that and there's probably a much easier way buried deep that I don't know about

No need for try..catch, just check the device pointer for being 0.

directional light

greets,
Halan

edit: ah well and the gui extension from the star sonata guys as i postest in project announcements