IrrExtensions >> not for V1.3 !!!

[BlindSide]

SVN is an easy way to get in touch with development versions. It's just not compiled. But what would you want the beta version for if you cannot compile And getting a binary built each night will be much more expensive in all terms than getting an SVN update.
We get lots of feedback during the development phase, and almost as much when a new release is out. But people just showing up to say "I did not manage to use the new version" are neither helpful nor may expect to get their bugs fixed. If they want the engine to improve they should write bug reports or asked how the new features are to be used. Many people here know how to use the latest SDK or development versions and do help out whenever they can, and last it's often not really a problem of the engine, but of the users who did not really read the docs.
BTW: Which file formats?

Sorry I meant to say "mesh system", the one bitplane and luke are supposedly working on. That is if its going to be integrated. By beta version I mean before you release a stable branch e.g. 1.4. Release a 1.4 Beta and get some feedback from the community, tweak it accordingly, and then release 1.4. I dont mean to compile one every SVN! Just once before deciding to release. Every other project out there does this, its common sense.

I am not here to bag on 1.3 though, its just a suggestion. Like I stated above I havent even used it yet so I am not commenting on it at all. I am merely scared of all the propaganda floating around... (And several projects taking too long to support it...)

[hybrid]

Acki, once again: It's your house you better care for. irrEdit is NOT part of the SDK
Moreover, Irrlicht is not a huge application, but only a library which has to be compiled into another app to make it useful. So it does not really make sense to provide a binary beta, but we provide the sources so everyone can test them. But I might set up a script to provide the Linux and Win-gcc binaries sometimes. I'll announce it elsewhere when it works.
Anyway, really no one complaining in this thread ever made a 1.3 bug report. So prove me wrong and show some major bugs of 1.3. Otherwise keep whining in your own cellars.

[eric]

yes admittely, I did not make a 1.3 bug report. mainly to avoid double-posting.

and then, it seems people do not really care about bug reports. one short example given: on march 17 roxaz reported a bug concerning the skybox: (weird garbage stuff in corners of skybox). I noticed and experienced that too. This has been reported, but no answer has been given so far to clarify why this most annoying bug is present, all of a sudden. it definitely is not present in version 1.2

fine, roxaz decided for himself to use dx9 instead. might be a solution for him, is not solving the problem though.

even worse, the API changes are not or at least not very well documented at the moment. the documentation itself was not updated ...

i could go on and there are numerous other examples that could be given - would be a waste of time and space though. have a look at the bug report section and study the reports. the longest list of bugs i have ever seen, following the release of a new version.

also in agreement with acki: it seems a radical change of concept from the original is considered here. intending to push a top-class 3D graphics rendering engine into the direction to be one game engine out of the myriad game engines 3D games are built around. might be a pioneering approach to the serve the needs of script kiddies, but not terribly useful in general.

so, once again. a big NO when it comes to talking about or - not to mention - using version 1.3. Hopefully 1.4 will come out of Niko's hands again.

eric

[roxaz]

undocumented api changes is rly bad thing for sure. at least documentation should be right if such changes are made. if ppl dont know something they go to api reference and after that to forum (at least i do so)

[hybrid]

We don't have access to the online API, as both the web changes and the file releases come from Niko's hands. But you have the doxygen configuration in the SDK, just rebuild it yourself.
The skybox bug seems to be a rather local effect, no one else did reproduce it yet. Moreover, I thought that everything was related to the camera bug and considered this bug as fixed. Would have definitely helped if you would have posted another support post.
All API changes should be documented in the changes.txt file, even with hints on how to migrate.
I don't know how many SDK releases you followed, but in my opinion the 1.3 release had only very few bug reports. Even more, there was only one show stopper which could be easily fixed, though.
And finally your last point: I really don't see which part of the Irrlicht development makes the library change into a game engine. Niko and bitplane are developing some add-on tools which are pretty useful for development, but neither irrKlang (except for one binary) nor irrEdit are part of the SDK. The font tool will simply replace the old one which has been a part of Irrlicht ever since, and the gui editor will probably move to the external projects sooner or later. But none of these tools is in any way integrated into the library. Your arguments are complete nonsense.

[eric]

Criticism is hard to take but if you learn to use it then you can take yourself to an entirely different level ... and at this point we should really stop the tiring discussion of benefits and misfits concerning version 1.3. I am sure, the next version will be a better one. Keep up the good work and slow down a bit, trying to be more accurate: i.e. improve dynamic light handling, shader support etc. instead of introducing more and more features... that might help.

eric

[Strong99]

@ acki, seems the bug is returned in the file explorer, i fixed it with when no default height is found he uses 12 px but when i doesn't have default font how does it draw the font at all??

@the rest,
not only the team has to fix those bugs, why else do we have a community than?

[xray]

Hi Acki,

I have some problems with your IrrExtension. I want to use the custom bones, because I really need direct access to the bones! So I downloaded your app and selected the custom bones setting, but your app says "wrong irrlicht version" when I choose "Erweiterungen erstellen". So I thought it would be no problem to modify the headers and source files by hand because all the information is in your tool.6 file for the custom bones right ? I did all the changes and started recompile the dll but the compiler says all the time "'amp' undeclared (first use this function)". So do I have to apply another tool xml file to the irrlicht source and headers ?

Im using Dev-C++ 4.9.9.2, winxp and Irrlicht 1.2

thanks
xray

[Acki]

No, it should also work with V1.3 if you change it by hand (IrrExtensions itself doesn't work with V1.3) !!!
But you made a mistake, you just copied the code out of the XML file into the source...
There are some codes you have to interpret correctly !!!
For example this amp thingy (correctly its &)
look at this:

Code: Select all

&   &
<       <
>      >
"   "
&apos;   '

so simply change all & to & !!!

@hybrid: off course irrEdit is now a part of the SDK !!!
look into the tools folder, there is a seperate folder for irrEdit (and other progs) !!!
the only reson why the exe is not included is because of keeping the file size at minimum !!!

For package size reasons, irrEdit is not included in this SDK, but you can download it from

right you now can say "there it stands: it's not included"...
but there also stands "For package size reason" !!!
so mainly it belongs to the SDK now...

[xray]

Thanks alot, now it works !

[xray]

Acki, did you also created your models with bones in blender ? Well Im using blender but Irrlicht crashes when I want to load the .X files! I cant belief that there is no 100% working file format for just a model and its bones. Creating a complex 3d engine like irrlicht is easier than creating a working 3d file format ??

Well I tried all three .X exporter from blender and Irrlicht loads this files without crashing, only when I didnt added the bones to the file. I also tried your example "_CustomBones - Simple Demo" with my .X file and there it is working perfect, also the bones are rotating fine... So what version of irrlicht are you using in your demos ? Maybe I can use the X mesh loader from there...

(I tried Irrlicht 1.2/1.3/1.3.1)

[bitplane]

if you're having problems loading a certain mesh, please post in bug reports detailing the problem and include a link to the x file so we can fix it.

[xray]

I figured out that it is not a bug from the Irrlicht. Maybe its more a bug from Acki's CustomBones ?

Acki, I implemented the source for the CustomBones first by hand and after that I also implemented it over your application. But when I load the "gelenk.x" file from your demo with the following code:

Code: Select all

	IAnimatedMeshX *mesh = (IAnimatedMeshX*) smgr->getMesh("gelenk.x");
	IAnimatedMeshSceneNode *skeleton = (IAnimatedMeshSceneNode*) smgr->addAnimatedMeshSceneNode(mesh);
	array<matrix4>* bones;

	if (skeleton) {
		skeleton->setMaterialFlag(EMF_LIGHTING,false);
		skeleton->setFrameLoop(0,0);
		array<matrix4>* bones = (array<matrix4>*) skeleton->getCustomBones();
		skeleton->useCustomBones(true);
	}

The application crashes! I figured out that something is wrong with the useCustomBones(). Because when I deactivate it like this:

Code: Select all

	IAnimatedMeshX *mesh = (IAnimatedMeshX*) smgr->getMesh("gelenk.x");
	IAnimatedMeshSceneNode *skeleton = (IAnimatedMeshSceneNode*) smgr->addAnimatedMeshSceneNode(mesh);
	array<matrix4>* bones;

	if (skeleton) {
		skeleton->setMaterialFlag(EMF_LIGHTING,false);
		skeleton->setFrameLoop(0,0);
		array<matrix4>* bones = (array<matrix4>*) skeleton->getCustomBones();
		//skeleton->useCustomBones(true);
	}

the application will not crash and I see the model! Any advice ?
Using Irrlicht 1.2

[xray]

Hey Acki, I got the problem! My code must look like this:

Code: Select all

		IAnimatedMeshX *mesh = (IAnimatedMeshX*) smgr->getMesh("skeleton.x");
		skeleton = (IAnimatedMeshSceneNode*) smgr->addAnimatedMeshSceneNode(mesh);

		if (skeleton) {
			skeleton->setMaterialFlag(EMF_LIGHTING,true);
			skeleton->setFrameLoop(0,0);
			skeleton->makeCustomBones();
			skeleton->useCustomBones(true);
			array<matrix4>* bones = (array<matrix4>*) skeleton->getCustomBones();
		}

...so I have to call first make- than useCustomBones and after that I have to access to the bones over the get function. But this is different to your examples in your demo "CustomBones 01 - Simple Demo". In there you wrote it like my post above. Maybe you could update your example codes...

[Acki]

The demos are correct, they use makeCustomBones() first...

Code: Select all

  // creating a node and get access to the bones
  IAnimatedMeshSceneNode* node1 = smgr->addAnimatedMeshSceneNode(mesh);
  node1->setMaterialFlag(EMF_LIGHTING, false);
  node1->setFrameLoop(0, 0);
  node1->setPosition(vector3df(-2, 0, 5));
  array<matrix4>* mat1 = (array<matrix4>*)node1->makeCustomBones();
  node1->useCustomBones(true);