That needed quite a lot of changes and additions to a couple of files, all listed in the readme.txt
http://festini.device-zero.de/irrchange.zip
Obviously requires recompiling or living with an OpenGL only Win32 build (binaries included).
Should support DXT1/2/3, most likely uncompressed as well and uses mipmaps when included (it will NOT build mipmaps if there aren't any in the file). It will however only use the first level, if the mipmap flag is set to false. Cube and volume map support is about 50% and won't be finished, as they are kind of useless without 3D texture coordinates.
And to state the obvious: make BACKUPS of all files you are going to overwrite. You don't want to download the whole engine again just to fix some bugged 2kb header file, do you?
Usage: I'm not even going to comment on that. If you have to ask that question you really DON'T want to use this.
Added support for DDS (OpenGL only)
-
Guest
Using compressed textures, so the benefits are the obvious ones. It requires less memory and is decompressed on the fly in hardware, where other formats like jpg might be small on hard disk, but will still be decompressed to a regular full sized bitmap (which obviously means longer load times and they are a really crappy format for textures anyway).
They can also include mipmaps and most tools/exporters offer some very high quality filters. The kind that takes a bit too long to use on the fly, unless you want the user to spend minutes waiting for the textures to be loaded.
But if you didn't feel the need to use dds so far, then I doubt you would really feel much of a benefit.
They can also include mipmaps and most tools/exporters offer some very high quality filters. The kind that takes a bit too long to use on the fly, unless you want the user to spend minutes waiting for the textures to be loaded.
But if you didn't feel the need to use dds so far, then I doubt you would really feel much of a benefit.
-
hybrid
I don't think so, and I'm wondering why you want to keep people from using your code? It seems to be really useful, and implementation seems to be pretty well done. But not knowing about a very specific graphics format shouldn't be too bad. Even after searching the web I first thought it's an invention of NVidia until I found the MSDN introduction on DDS.Anonymous wrote:But if you didn't feel the need to use dds so far, then I doubt you would really feel much of a benefit.
So having a file format invented for DirectX it might be a good idea to have the support for the DirectX renderer as well. Anyone out there volunteering for this?
I've made patch files from the changed sources such that backups won't be that necessary anymore. I also split the other additional methods for matrices and scene nodes into separate files to simplify adding the features to customized Irrlicht versions. Check the patch page for those files.
BTW: Guest, could you describe the problems with CameraSceneNode and your changes a little bit. The changes were quite dense
-
Guest
As far as I know it began as S3TC. MS used it for DX and renamed it DXTC and allowed it to be used directly in their direct draw surface thingy (dds). What I don't like right now is that my implementation isn't really "clean". It seems the image will be freed after the texture was created, so that part isn't too bad. But IImage shouldn't need properties like DataSize or ImageType (as it's per definition a 2D array of color values) or number of mipmaps. But as I couldn't use bytesPerPixel (as 4bits/8 is .5 which doesn't really work with int) I ended up adding these.
I thought Images might have a name that could be abused to store the filename, so when building a texture from an "empty" image it would try to load that. Basically the whole detour over Image is causing major trouble for everything that isn't a straight forward 2D image. So I guess my favorite solution would have been some clean way to bypass that part and directly load it as texture instead of passing down kind of special information through multiple layers.
The changes to the camera were a bit hasty and I didn't think about it creating wrong results when using setTarget/upVector for a camera that is attached to another node.
I got a bit irritated when I attached the camera node to a ship node and it only updated the position but seemed to keep looking straight ahead, completely ignoring the parents orientation.
With the current version, when you use these functions they will set the rotation according to the passed vector, but it changes the relative orientation instead of the absolute. I thought about a better way, but there are a few problems with doing it "right".
The best way would be to set the relative orientation in a way that the resulting absolute transformation will look the right way. For that I would need the transposed absolute rotation of the parent, but as far as I can tell it won't be updated until later on. In most cases lagging one frame behind won't matter, but you never know.
I thought about delaying the update of the relative rotation until the view matrix is built and the parent will have the updated absolute transformation, but that would mean returning wrong data in the meantime (one could of course argue that it's still better than never returning the correct rotation at all).
Personally I would have prefered to ditch setTarget and setUpVector, maybe replace them with a single lookAt function or offer storing a target node and automatically keeping that in view.
An even messier version would be doing the relative update immediately (as it is now) and correct the rotation when setting up the view. But the result in the meantime would still be wrong, if the camera is attached to something.
But no matter how, if a camera is attached to another node you could never rely on getRotation giving the right result between a call to setTarget/UpVector and setting up the view.
Another issue right now would be if someone tries to change the scale for a camera node (or worse, one of its parents, which is relatively likely). When I build the View matrix I assume that there is no scaling. Dividing that out would take a few square roots, so it might be easier to add getAbsoluteRotation and getAbsoluteScale to the scene node and just put it together without the scaling.
Though I guess the cleanest solution would be deriving a different camera class that simply doesn't have Target and UpVector in the first place. For most typical uses they aren't needed (3rd person, fps style, etc.). Only way to get correct and consistent results would be if something like a "lookAt" helper function would force an immediate update to all parents absolute transformations. But then... if I change a node it won't immediately update all children anyway, so I should stop worrying about the camera not being consistent at all times when pretty much no other node is.
I think I'll go and upload a different camera class instead, that seems to be better than changing the existing one any trying to keep it "backward compatible".
I thought Images might have a name that could be abused to store the filename, so when building a texture from an "empty" image it would try to load that. Basically the whole detour over Image is causing major trouble for everything that isn't a straight forward 2D image. So I guess my favorite solution would have been some clean way to bypass that part and directly load it as texture instead of passing down kind of special information through multiple layers.
The changes to the camera were a bit hasty and I didn't think about it creating wrong results when using setTarget/upVector for a camera that is attached to another node.
I got a bit irritated when I attached the camera node to a ship node and it only updated the position but seemed to keep looking straight ahead, completely ignoring the parents orientation.
With the current version, when you use these functions they will set the rotation according to the passed vector, but it changes the relative orientation instead of the absolute. I thought about a better way, but there are a few problems with doing it "right".
The best way would be to set the relative orientation in a way that the resulting absolute transformation will look the right way. For that I would need the transposed absolute rotation of the parent, but as far as I can tell it won't be updated until later on. In most cases lagging one frame behind won't matter, but you never know.
I thought about delaying the update of the relative rotation until the view matrix is built and the parent will have the updated absolute transformation, but that would mean returning wrong data in the meantime (one could of course argue that it's still better than never returning the correct rotation at all).
Personally I would have prefered to ditch setTarget and setUpVector, maybe replace them with a single lookAt function or offer storing a target node and automatically keeping that in view.
An even messier version would be doing the relative update immediately (as it is now) and correct the rotation when setting up the view. But the result in the meantime would still be wrong, if the camera is attached to something.
But no matter how, if a camera is attached to another node you could never rely on getRotation giving the right result between a call to setTarget/UpVector and setting up the view.
Another issue right now would be if someone tries to change the scale for a camera node (or worse, one of its parents, which is relatively likely). When I build the View matrix I assume that there is no scaling. Dividing that out would take a few square roots, so it might be easier to add getAbsoluteRotation and getAbsoluteScale to the scene node and just put it together without the scaling.
Though I guess the cleanest solution would be deriving a different camera class that simply doesn't have Target and UpVector in the first place. For most typical uses they aren't needed (3rd person, fps style, etc.). Only way to get correct and consistent results would be if something like a "lookAt" helper function would force an immediate update to all parents absolute transformations. But then... if I change a node it won't immediately update all children anyway, so I should stop worrying about the camera not being consistent at all times when pretty much no other node is.
I think I'll go and upload a different camera class instead, that seems to be better than changing the existing one any trying to keep it "backward compatible".
-
Guest
[wash]Holy mother of god and all her wacky nephews[/wash]
Finally uploaded an updated file with a completely new camera. Getting it to work somehow wasn't the problem, getting it to work without jerking and flickering movement was trickier and at least now I now that for whatever reason the absolute transformation is updated AFTER rendering???
Also didn't find any clean and easy way to remove the scaling after the fact, so things might look a bit weird right now. Anyway, both methods are now forcing an update of all absolute transformations along the way which seems to remove the jumpy motion. Might try to achieve the same result with less work when I feel the need for some more frustration and "wtf?!?" moments.
Right now the camera should work fine, no matter how many parents and how much scaling is happening along the way. lookAt is combining setTarget and setUpVector (no need to do all the work twice).
My "test" looks like this
A small test is at http://festini.device-zero.de/test.zip
For size and laziness it does not have the updated dll (which is at http://festini.device-zero.de/irrchange.zip), only jpg background and two binaries, one using lookAt and one just attaching the cam and never touching it again. (note: nothing of the visuals is mine, ship is from http://www.psionic3d.co.uk and background is taken from vegastrike)
Finally uploaded an updated file with a completely new camera. Getting it to work somehow wasn't the problem, getting it to work without jerking and flickering movement was trickier and at least now I now that for whatever reason the absolute transformation is updated AFTER rendering???
Also didn't find any clean and easy way to remove the scaling after the fact, so things might look a bit weird right now. Anyway, both methods are now forcing an update of all absolute transformations along the way which seems to remove the jumpy motion. Might try to achieve the same result with less work when I feel the need for some more frustration and "wtf?!?" moments.
Right now the camera should work fine, no matter how many parents and how much scaling is happening along the way. lookAt is combining setTarget and setUpVector (no need to do all the work twice).
My "test" looks like this
Code: Select all
node = sceneMgr->addAnimatedMeshSceneNode(sceneMgr->getMesh("ship/fighter.3ds"));
irr::scene::ISceneNode* n = sceneMgr->addEmptySceneNode(node);
n->translate(core::vector3df(2,2,2));
n->rotate(35, core::vector3df(1,0,0));
n->rotate(-15, core::vector3df(0,1,0));
n->setScale(core::vector3df(9.3f,2,3.21f));
irr::scene::ISceneNode* n2 = sceneMgr->addEmptySceneNode(n);
n2->translate(core::vector3df(1,1,-1));
n2->addChild(camera);
For size and laziness it does not have the updated dll (which is at http://festini.device-zero.de/irrchange.zip), only jpg background and two binaries, one using lookAt and one just attaching the cam and never touching it again. (note: nothing of the visuals is mine, ship is from http://www.psionic3d.co.uk and background is taken from vegastrike)
I installed the code using the patches from http://parsys.informatik.uni-oldenburg. ... /irrlicht/ and had some trouble with the camera.patch. I installed other patches before, so there might be conflict with another patch, thought i've been quite careful. The problem is, that after installing that patch, the fps-cam did not strafe anymore. On debugging i found out that the reason for that was, that the UpVector in the camara scene node was always set to (0,0,0). So maybe this patch doesn't work that well, when not using the camera as child of another node.
-
hybrid
Ok, I finally managed to test the camera patch on my own and yes, it does not work. I'll remove it from the patch page until fixes are available. Furthermore, one more patch from this package will be removed as the sceneNodeTransform.patch messes up some matrices. Don't know how, cause it simply adds some methods, but apparently somethings going on.
Thanks for the feedback! BTW: Are these compressed textures working? It's compiling, but I never tried them...
Thanks for the feedback! BTW: Are these compressed textures working? It's compiling, but I never tried them...
Sorry, i also haven't used the compressed textures so far. But i might have an (maybe stupid) idea why a class that just add's some functions can mess up working stuff. Lately i installed some patches and had the same problem - until i realized that i just updated the includes in the engine which i compiled, but not the one which where included in my game project. Because the new functions where not used yet in the game i got no compile warnings, but the shared lib and the headers did no longer match. Maybe worth checking out if you stumble upon the same problem.
-
hybrid