Irrlicht Engine

Posted: **Sat Jan 31, 2009 12:39 am**

Blindside, with respect to your efforts with XEffectsR and the fact that you have made it freely available, it kind of pisses me off to see you pimping it every second post when it in fact doesn't work properly (the examples keep spamming me endlessly about some floating point errors and other people have said the same). If you could make it a bit more robust it would solve all my Irrlicht lighting problems and I would stop going through the Ogre tutorials.

hybrid wrote:IMeshSceneNode is the base for all geometry related scene nodes.

This says otherwise.

hybrid wrote:Once you alter the mesh structures you'll have to know the exact internal implementation (because e.g. altering a vertex position in a static node is simple, but doing the same in a skinned mesh is rather ambiguous in which position (current frame, everywhere, weight controlled, ...) is to be altered and how. Hence, there's no general way without implementing very much which would be usually part of a 3d animation tool, into Irrlicht.

Perhaps a compromise could be reached. We could still have the extension point, but under the hood the generic triangle selector and shadow caster would query the node type and use the appropriate node-specific implementation. This would make it simpler for the end user.

Another thing I would like to see is support for VC6 finally dropped. There's no excuse for anyone to use it still, only silly nostalgic reasons.

Posted: **Sat Jan 31, 2009 5:22 am**

SSG wrote:Blindside, with respect to your efforts with XEffectsR and the fact that you have made it freely available, it kind of pisses me off to see you pimping it every second post when it in fact doesn't work properly (the examples keep spamming me endlessly about some floating point errors and other people have said the same). If you could make it a bit more robust it would solve all my Irrlicht lighting problems and I would stop going through the Ogre tutorials.

I'm sorry but, I don't see you reporting any bugs in the project thread.

Maybe you should learn to ask for help instead of quietly bitching and moaning to yourself and then suddenly lashing out at the creator?

Posted: **Sat Jan 31, 2009 6:14 am**

One report. And another one. I really do appreciate your work and it's my last hope for using Irrlicht unless the shadow issue is addressed soon. My apologies if I offended.

Posted: **Sat Jan 31, 2009 9:38 am**

SSG wrote:Another thing I would like to see is support for VC6 finally dropped. There's no excuse for anyone to use it still, only silly nostalgic reasons.

Code: Select all

E:\dev\1.5>dir /s/b *.dsw
File Not Found

E:\dev\1.5>dir /s/b *.dsp
File Not Found

What'chyo talkin' about, SSG?

Posted: **Sat Jan 31, 2009 12:38 pm**

Oops

I was confused from another discussion that mentioned Irrlicht catering to non-compliant compilers and/or STL implementations. Does Irrlicht 1.5 assume ansi/iso C++ compliance these days (perhaps not 100%, but as much as can be reasonably expected)?

Another thing I would like to see (and this will be controversial) is the removal of IReferenceCounted in favour of a smart pointer template, whether it be boost::shared_ptr or something else, such as a wheel reinvention. This is one case where I wouldn't mind a wheel reinvention because there may be valid reasons for some people not to have this dependency.

Posted: **Sat Jan 31, 2009 12:43 pm**

SSG wrote:One report. And another one. I really do appreciate your work and it's my last hope for using Irrlicht unless the shadow issue is addressed soon. My apologies if I offended.

First report saying they fixed their problem shortly after.

Second report making some progress (They got it working in OpenGL not in D3D)

Anyway all these issues were caused by outdated DX SDK and/or drivers, I doubt doing it any other way would solve these issues, they are more related to the way Irrlicht handles RTT, etc.

Posted: **Sat Jan 31, 2009 12:59 pm**

Ok, I'll recompile the examples with the 1.5 Irrlicht version I have which is built against the November DX SDK. Already have the latest drivers. I'll post any issues to the appropriate thread. Thanks again BlindSide.

Posted: **Sat Jan 31, 2009 3:30 pm**

SSG wrote:I was confused from another discussion that mentioned Irrlicht catering to non-compliant compilers and/or STL implementations.

Fair enough. There are still some workarounds in there for known compiler bugs (all MS AFAICR); we can't really take them out without porking anyone still using those compiler versions. However, I personally consider VC6 as unsupported starting with 1.5.

Regarding the STL-vs-irr::core issue, it's really up to an STL advocate to pull their finger out and actually do it. We're all peers here.

SSG wrote:Another thing I would like to see (and this will be controversial) is the removal of IReferenceCounted in favour of a smart pointer template

See above.

Posted: **Sat Jan 31, 2009 7:58 pm**

rogerborg wrote:Regarding the STL-vs-irr::core issue, it's really up to an STL advocate to pull their finger out and actually do it. We're all peers here.

SSG wrote:Another thing I would like to see (and this will be controversial) is the removal of IReferenceCounted in favour of a smart pointer template
See above.

Well it requires a bit more than one advocate. For it to be truly useful it requires some re-engineering of Irrlicht. Hence something closer to an Irrlicht 2. I have my own list of Irrlicht changes I'd like to see, in addition to STL compatibility, the big one being having a render queue instead of using the scene graph for rendering. So the question really is: Are people willing to work on a next-gen Irrlicht?

NOTE: This is not an empty question... When I ask such things it means I'm willing to devote work to it.

Posted: **Sat Jan 31, 2009 10:13 pm**

Let's rolllllllll!

Posted: **Sun Feb 01, 2009 2:36 am**

Heh, rendering queue, stl-based irr... You got me sir, I'm on this boat and if we get the agreement, I'll test, debug, submit patch, all I can ^^

Posted: **Sun Feb 01, 2009 5:09 am**

I'm certainly up for devoting time to a next gen irrlicht, although I don't have an abundance of time. Is there any next gen work in progress at the moment?

Render queues sound like a good idea too. And scene manager neutrality. But let's not get too much like Ogre. We should aim to maintain maximum ease of use which is definitely irrlicht's biggest selling point.

Posted: **Sun Feb 01, 2009 1:00 pm**

This whole stuff only makes sense if there are things which are impossible by the current implementation, or which are not possible without major performance impact. Both are not immediately clear. Moreover, establishing an NG branch next to the existing Irrlicht version has been done several times already, with varying success so far. After all, it would only weaken the community and standing of Irrlicht.
So things like STL containers are definitely possible under the hood of the existing containers. No one did an implementation so far, though.
Render queues are not necessary, at least not as explicit user accessable structures. Moreover, it would break with most if not all existing code so far.
Other extensions and add-ons will easily integrate into the current Irrlicht API, so why trying to reinvent everything from scratch while we can continue with the current way for several years at least?!

Posted: **Sun Feb 01, 2009 1:41 pm**

I'm a newby here, but for me irrlicht means, basically, multiplatform, stable and simple. If it turns complex, then i'd just go to Ogre, i think.
So, please, keep it simple (stupids

)

Posted: **Sun Feb 01, 2009 1:49 pm**

Oops, I did it again.
Made you believe we're more than just peers.
Oh baby
It might seem like a crash
But it doesn't mean that I'm serious
'Cause to lose all my references
That is just so typically me
Oh baby, baby..

Urgh, muh head... what did I say last night?

Let's rollllll... and deal with the current bugs, patches and feature requests first, shall we?

Irrlicht Engine

What's new features for Irrlicht 1.6