Irrlicht 2.0 - What's in store for the future!

[devsh]

dont user eigen, use our own vector class

if have any software renderer, have an OpenGL or DirectX reference renderer (CPU emulating GPU)

picking is impossible without collision so no basic picking
depreciate GUI and focus on improving the engine drawcalls and buffer management so any GUI engine can be hooked up without sacrificing 50% FPS (batching)
CMake is awful... from personal experience of large scale commercial release

[devsh]

Without runtime detection, you'd have to ship two binaries. Hardly an improvement.

if you're so worried why dont you get some proper tools like the Intel compiler?

[mongoose7]

I wouldn't like to use CMake. The Makefiles all reference Cmake so you can't make without Cmake. Stupid!

[Granyte]

Without runtime detection, you'd have to ship two binaries. Hardly an improvement.

if you're so worried why dont you get some proper tools like the Intel compiler?

the intel compiler is definitely not the "proper" tool as it does not detect only the cpu capabilities but also the brand of the cpu and discriminate against non intel cpu even if they have the capabilities

- and finally: use CMake for the build script. notably don't put everything in the /source/Irrlicht subfolder, this is quite messy

if oh please no CMake is a pain it infects every project it touches and after that they become non portable you lose the ability to use your compiler specific flags as cmake re run every damned time you wan to compile and it overwrite your project files so you need to ask all mighty cmake to swich your optimization flags or switch between x64 and x86 and if the original project creator did not think about the specific flag you are trying to use you get screwed for good



-collisions need to stay even if only for picking as i'm definitely not pushing and removing 110k object into and out of bullet or any physic engine only to allow for picking one of them ..... and as stated they are great for prototyping

-sse vectors are a must my personal implementation allow me to use 110k scenenode around 100 fps in in my galaxy viewer and it's not nearly optimized enough I still make use of a lot of set functions

- improvements on the gui would be great ideally batching and/or hardware buffer storage for mostly static elements would be great

-and bonus working DX drivers rightnow they are a mess the DX9 driver is a mess because it relies on the camps viewer that has been depreciated since dx8 as such every time you try to do something you never know if the engine will do it or if a random caps will prevent you ...

most of the other feature I need i'm trying to push them in the shader-pipeline branch

[devsh]

-sse vectors are a must my personal implementation allow me to use 110k scenenode around 100 fps in in my galaxy viewer and it's not nearly optimized enough I still make use of a lot of set functions

can I see/compare your implementation?

[Granyte]

sure ill post my code in your thread

[hendu]

if you're so worried why dont you get some proper tools like the Intel compiler?

Because I care about users on AMD and Via? Even the current ICC still produces very bad code for them.

Also a -1 for cmake, it's horrible.

[Darktib]

Wow, so much CMake hate^^. I partially understand, but from my experience CMake has the most features and it is possible to create the CMakeFiles without polluting the project (rule 0: don't put CMakeLists in your source folder). The only thing about cmake is that its script language is quite awful.
I also used premake, but I find that making it put the project files where you want is quite weird.
Cmake or premake, for both the tool will need either to be installed by the user or distributed with Irrlicht (like how doxygen is distributed with Irrlicht).

If ever (but seeing your reactions that's quite unprobable) CMake is choosen, I can write the scripts.

[kklouzal]

Down with cmake up with premake!

p.s. premake4.exe is only 275kb ;)

[christianclavet]

Things I don't want to lose in Irrlicht 2.0:
- GUI (I use it all the time, and now it's real easy for me to make my own variation of some gui)
- Collision. Could perhaps remove some parts, but I need the ray-cast tests, for picking and moving.

Things I would like to see:
- Support for truetype
- Reading/Writing in UTF8 natively (XML writer). So I could edit files with accented characters without too much conversion. (Right now converting from Latin1 to UTF8)
- OpenGL 4.0+ support
- Hardware skinning
- Deferred rendering
- Better support for animation data with skinned models (could allow editing from a mesh animation to another), "useAnimationFrom" is too limited. At least it's there.
EDIT: Found a way to have duplicates of IAnimatedMesh and not instances, so useAnimationFrom is useful again!

[devsh]

you dont want deferred rendering for sure.... pipeline would be too complex and too rigid, people choose to go deferred because of the flexibility of it... a usable deferred pipeline would be impossible to implement

OpenGL 4.0, you need OpenGL 3.2 core for that

[Nadro]

We would add deferred shading to irr examples.

[devsh]

thats an idea I like

[REDDemon]

agree with most points. GLM does not have a lot of usefull stuff like frustum, bounding boxes etc. Also C++11 would be a pain for windows users:

- VS 2013 still have compilation problems for a lot of c++11 projects (including mine, I had to make heavy hacks and still wait users try to compile it XD)
- VS 2012+ requires at least Windows 7
- There are still crashes caused by capturing lambda expressions

eigen, still doesn't support many usefull classes, it is not very intuitive to use and increase insanely compilation time.

Also irrlicht math is used everywhere, it's insane to make so much changes. If one day there will be any chance to use a 3rd math library I would go for the library of another Opensource engine (rendering or physics)

[christianclavet]

Hi, Just one other thing I've missed to mention. I know that Irrlicht when using mesh loaders assign material with a number, but it would be really nice that if the loaders could also check the material names and store it with the number. The material class would only need to store the name, and the work would be to have loaders get the material name and store it in the class.

In my current project, I will have to model characters with all their equipment on them (mostly clothes/armor, weapons will be attached to the character bones), then make their material visible based on what the character is equiped. That can be done by getting the material number and assign it, but if I could use the original name (as the artist defined it), it would surely make the process simpler.