Irrlicht 1.4.2 Release candidate

hybrid · Post by **hybrid** » Wed May 07, 2008 8:03 am

EDIT:
Check somewhat down for the announcement of the 1.4.2 RC. We had to pushd the development of this bug fix release due to the OpenGL slow render bug which affected the 1.4.1 on several cards with OpenGL 2.x. So there are less bugfixes and changes this time, but hopefully without such major problems...

Old posting:
Ok, a little later than expected, but it's definitely time to finalize the 1.4.1 bugfix release. You can find the current revision in https://irrlicht.svn.sourceforge.net/sv ... leases/1.4
Please check this version for any show-stopping bugs and report them in this thread. Also documentation updates can still be reported here in order to make it into the next release.
However, we won't accept any larger changes to the code, so don't ask for arbitrary size RTTs, FSAA, or post-processing functions. Those will probably only be available in version 1.5 later this year. Only in cases where something's completely broken we can fix it before the 1.4.1 release, or postpone that release a little further.
If everything goes well, the RC phase will end on May 15th, and the final release will be prepared sometimes after that date.

CuteAlien · Post by **CuteAlien** » Sat May 10, 2008 9:30 pm

I just run some test here.

On Linux/OpenGL the example 13 (render to texture) seems to have some problems. It does not show the correct texture until I move the camera close to the cube first. Same example on Windows works with OGL and DX.

On windows I did not manage to compile it with the newest code::blocks so far. I still try to figure out what's happening there as the errormessages are so far simply confusing. Also for some reason code::blocks creates subdirectories for every single codefile - no idea if this is some strange feature of newer c::b or a problem of the project files.

Except that everything did run as well on Linux (tested with software, burning and OGL) as on Windows with VS (and DX9 + some OGL tests).
I had hoped for some more fixes (mainly that the wrecking of filenames would be fixed - this is a very serious bug!), but maybe in 1.4.2

But it's once again an impressive list of bugfixes, thanks for all the work guys :-)

hybrid · Post by **hybrid** » Sat May 10, 2008 9:41 pm

Sorry, we didn't have enough time to discuss most of the larger changes until now. However, I'm also not sure if the filename changes will go into the 1.4.x branch, because this behavior has been in Irrlicht ever since, so a change would be more proper for a major release...
The RTT suffers from the clipping problems under OGL (don't know if we should put the fix into 1.4.1, because we cannot test it enough), didn't seee any other problems yet. Because I also ran this example through OGL debuggers etc it's pretty hard to find the actual cause of such problems. So we may have to live with it for a little longer...

CuteAlien · Post by **CuteAlien** » Sat May 10, 2008 9:50 pm

hybrid wrote:However, I'm also not sure if the filename changes will go into the 1.4.x branch, because this behavior has been in Irrlicht ever since, so a change would be more proper for a major release...

I don't think of it as behavior if a library is changing filenames from the user, for me that is a clear bug. Behaviour would be if it just would ignore the uppercases, but that's not what it is doing. But maybe I just see this as more serious as that bug trashed all texture filenames in rather large amount of xml files for me.

edit: Please don't get me wrong. I appreciate that you want to write a perfect solution for the filenames. I'm just somewhat thin-skinned on that bug.

CuteAlien · Post by **CuteAlien** » Sun May 11, 2008 11:51 am

I managed now to compile it on CodeBlocks 8.02 at least on Linux (I guess it might work similar on Windows). I guess the current c::b project files are probably still for an older version of c::b.

If you get errors like: "calling fdopen: Bad file descriptor" then disable the precompiled headers (Settings - Compiler and Debugger - Other Settings - Advanced Options). I don't know enough about precompiled headers on gcc, so I can't fix that. Disabling those will by the way also stop gcc from creating a subfolder for every single header it compiles.

Next be sure to set the correct platfrom (properties - Project settings - platforms and Properties - Build Targets - platforms).

Remove cdjpeg.c within the jpeglib folder from the project.

That should compile now.

Compiling the examples works similar. But currently those project files seem to expect to run on MinGW, so on Linux you need to change linking to use Linux path (build options - linker settings - Other linker options).
Also you should add: -L/usr/X11R6/lib -lGL -lXxf86vm at the same place.

After that it runs the same like the usual Linux version - not really surprising ;-)

MasterGod · Post by **MasterGod** » Tue May 13, 2008 11:34 am

How about adding my fix to the next release

. IMHO if you accept my fix (which I don't know why you didn't already) it should get in the next bugfixing release.

Here it is:
CFileSystem::addFolderFileArchive() bug fix

Edit:
P.S

hybrid wrote:Only in cases where something's completely broken we can fix it before the 1.4.1 release...

It is completely broken ( the important method [void CUnZipReader::buildDirectory ( ) ] is empty..

).

Neirda · Post by **Neirda** » Wed Jun 04, 2008 6:42 am

Hi !

As niko suggested me to do, I'll draw your attention on this thread and the posts I wrote on Ambierra's IrrEdit forum.

http://www.ambiera.com/cgi-bin/forum/Bl ... /s-0/#num3

I quote :

Tested, and sorry dude, lots of issues on my side.
I loaded exactly the same scene with exactly the same properties (lights, materials, meshes) on IrrEdit 1.4 Alpha and 1.4 Final.
Here is what I got (all meshes are .obj, finally got rid of .x) :
http://placard.wizardsofsoweto.com/smodev/irrbugs.jpg

Note that there are other bugs that appear in your own example files :
http://placard.wizardsofsoweto.com/smodev/tree.jpg
All my trees & vegetation meshes that use trans_alpach and trans_alpach_ref textures get also screwed that way.

answer2

Course, I quite understand niko.
I'm just giving you some feedback, especially since my scenes use nearly every feature of IrrEdit, I see quite quickly what's wrong.

Actually talking about this, I'm thinking about downgrading directly to IrrEdit 0.71 and Irrlicht 1.3.1. Since Irrlicht 1.4 (alpha or not), the lightning and speculars render got also quite screwed somehow (you'll quickly understand what I mean if you load your example file "particles.irr" in both versions).

I'm not complaining, just give you my feeling and some clues, maybe you'll agree, maybe you won't.

It talks about the bugs and unhappy changes that appeared on the engine since 1.4.x versions.

Not being a programmer but a graphist (Smiers Online), I am absolutely unable to provide anything else than my feeling, but I quite acknowledged the tool I am working with.[/quote]

hybrid · Post by **hybrid** » Wed Jun 04, 2008 9:23 am

When using transparent materials you should usually disable zbuffer writing. This might already help for the trees. The lighting seems to be from an OpenGL rendering. You have to change the attenuation to make the light fade out at some distance. Try light->getLightData().Attenuation.set(0.f,1.f/radius, 0.f) where radius is the value (distance) you define when creating the light node. You should be able to define those values in irrEdit as well.

Neirda · Post by **Neirda** » Thu Jun 05, 2008 1:28 am

Unless this is a bug of the new version of IrrEdit, the renderer is definitely Dx9.
Disabling Zbuffer does not display the texture correctly either. I'll make a screenie to show you.
As for the lightning stuff, I'll try this thanks

EDIT : on the first link, second screen, you can also see the meshes get screwed up (on the stairs especially).

Neirda · Post by **Neirda** » Fri Jun 06, 2008 2:15 am

I made some other screenshots to point out the differences between the versions of IrrLicht :

First about the lightning render differences. I loaded the same scenes under IrrEdit 0.7 (IrrLicht 1.3.1) and IrrLicht/Edit 1.4.1, here is what I got :

Using DX9. Is that an expected change ? When moving the lights, they are much less "smoothed" and there is a big contrast (sorry dude, I suck at the technical voc).
For example : with the latest versions, if I load a big square plane composed of 1 single mesh, and I try to put a small light in the middle, the light will have no effect : or you light the whole plane with a big light, or nothing happens. Same about the speculars.
Maybe it's just some stuff that need to be adjusted by the user, if so forgive my lack of knowledge. Maybe it's unexpected.

Second is a screen pointing out my tests with trees. There's no way to get them look normal. Same on your side ?

hybrid · Post by **hybrid** » Fri Jun 06, 2008 7:36 am

You should set ZWriteEnable to false! For the lights - I don't know. Maybe it's the missing attenuation. Try to change the light setting in 1.4.1 and save the scene back.

Neirda · Post by **Neirda** » Sat Jun 07, 2008 12:11 am

I already tried, disabling ZWriteEnable does not correct the problem.

About the light, it's different from what I pointed out in the beginning. But I'll discuss that with my fellow programmer and eventually report to you if we can find out something valuable.

Lots of thanks hybrid !

BlindSide · Post by **BlindSide** » Tue Jun 24, 2008 7:38 am

Yes I noticed this happening with fixed function lights in D3D lately aswell, they seem to be missing attentuation/range. (The vertices pop in and out of brightness rather than smoothly fading like they do in OGL) I'll have to look through the materials code and see what happened.

hybrid · Post by **hybrid** » Fri Sep 12, 2008 8:44 pm

Ok, today I've applied a last patch which should make the 1.4 branch stable and complete enough to declare it the Release candidate for 1.4.2. Please check out this version (either by compiling it on your own from SVN-path in first posting- or by using the precompiled version from th enightl build server) and report problems as fast as possible. Problems which have been posted above should also be reposted if they are still not fixed for now, they will probably fixed only in 1.4.3 though in order to avoid last moment bug introduction...

dlangdev · Post by **dlangdev** » Fri Sep 12, 2008 8:57 pm

Good job, Hybrid.

Thanks for the hard work.