Irrlicht 1.8 beta phase
-
- Admin
- Posts: 14143
- Joined: Wed Apr 19, 2006 9:20 pm
- Location: Oldenburg(Oldb), Germany
- Contact:
Irrlicht 1.8 beta phase
Today we branched the trunk repository to branches/releases/1.8 in order to start the beta phase of Irrlicht 1.8. This means, the release is not yet ready, but we will only do some bug fixing now to ensure that no obvious major bugs that we have overseen will go into the release. But besides our own testing, it would be good if you all keep on giving feedback for this specific version (or SVN/trunk, which should stay rather close to the 1.8 bracnh while the release is not out).
Most important, we need to check for the shadow state and alpha blending issues that had been a problem thoughout the 1.8 development. Also please suggest to add some bug fixes that have been reported on the forum, but not yet integrated, in case they are more or less typo fixes. So no larger issues which need to be tested thoroughly, but minor issues which can be fixed on the fly.
Besides that, we should be ready for the release next weekend if everything goes well. Fingers crossed!
Most important, we need to check for the shadow state and alpha blending issues that had been a problem thoughout the 1.8 development. Also please suggest to add some bug fixes that have been reported on the forum, but not yet integrated, in case they are more or less typo fixes. So no larger issues which need to be tested thoroughly, but minor issues which can be fixed on the fly.
Besides that, we should be ready for the release next weekend if everything goes well. Fingers crossed!
Re: Irrlicht 1.8 beta phase
Shadow volumes aren't still perfect neither on the demo nor in the FX example. They look a bit distorted, or somehow misplaced. I will post some screenshots later.
The shadow rendering and the blending seem to work together again, though.
The shadow rendering and the blending seem to work together again, though.
"There is nothing truly useless, it always serves as a bad example". Arthur A. Schmitt
Re: Irrlicht 1.8 beta phase
In Sample 08 the Shadow disappears when behind the particles.
Re: Irrlicht 1.8 beta phase
That is much more due to the dwarf being behind the camera. The shadow volume is a child node and the dwarf isn't visible, so the children become hidden too. Not obstant the shadows should be visible even if the node isn't.
"There is nothing truly useless, it always serves as a bad example". Arthur A. Schmitt
Re: Irrlicht 1.8 beta phase
Something changed recently with the view fulstrum and broke the culling i was doing on my sub terrain patch i'm unsure if it's a bug or simply that is was not doing it the proper way
if it's not a bug how should i do it the proper way?
EDIT: i updated to the lastes SVN and it's been fixed my code now works again
Code: Select all
const SViewFrustum* frust = smgr->getActiveCamera()->getViewFrustum();
const matrix4 world = SceneManager->getVideoDriver()->getTransform(ETS_WORLD);
core::aabbox3df nodeBox = MyMB->getBoundingBox();
nodeBox.addInternalPoint(this->center);
nodeBox.addInternalPoint(this->center2);
world.transformBox(nodeBox);
//vector3df tempcent(0,0,0);
//world.transformVect(tempcent,this->center);
for (s32 i=0; i<scene::SViewFrustum::VF_PLANE_COUNT; ++i)
if(nodeBox.classifyPlaneRelation(frust->planes[i]) == core::ISREL3D_CLIPPED)
return ;
EDIT: i updated to the lastes SVN and it's been fixed my code now works again
Last edited by Granyte on Tue Oct 23, 2012 2:54 am, edited 1 time in total.
-
- Admin
- Posts: 14143
- Joined: Wed Apr 19, 2006 9:20 pm
- Location: Oldenburg(Oldb), Germany
- Contact:
Re: Irrlicht 1.8 beta phase
No, the shadow is indeed disappearing. It's not that obvious anymore, but if you go to the upper left corner of the room, such that the dwarf is on the bottom right, and you have the whole room in view, the shadow disappears when it should be in the back right part of the room. This is a bug for sure.
Regarding hte view frustum, not sure what you expect. Please provide a fully compiling and working example in a separate thread.
Regarding hte view frustum, not sure what you expect. Please provide a fully compiling and working example in a separate thread.
Re: Irrlicht 1.8 beta phase
> The shadow volume is a child node and the dwarf isn't visible, so the children become hidden too.
> Not obstant the shadows should be visible even if the node isn't.
Ahumpf - even if a node is not visible, it still casts a shadow and THAT may be visible.
But Irrlicht is doing fine here. The shadow(s) are even better than with the 1.7.3 release.
The disappearing is a minor "glitch" which surely will be found.
If you consider CG support and recently shadows for static meshes then Irrlicht has much
improved.
> Not obstant the shadows should be visible even if the node isn't.
Ahumpf - even if a node is not visible, it still casts a shadow and THAT may be visible.
But Irrlicht is doing fine here. The shadow(s) are even better than with the 1.7.3 release.
The disappearing is a minor "glitch" which surely will be found.
If you consider CG support and recently shadows for static meshes then Irrlicht has much
improved.
Re: Irrlicht 1.8 beta phase
Missing faces in a dwarf and sydney shadows are caused by bugged models (I think that Mel talked about it). I'll check a problem reported by Hybrid (shadow disappear when we are inside a room in example 08). What about Cg? We already support it.
Library helping with network requests, tasks management, logger etc in desktop and mobile apps: https://github.com/GrupaPracuj/hermes
-
- Admin
- Posts: 14143
- Joined: Wed Apr 19, 2006 9:20 pm
- Location: Oldenburg(Oldb), Germany
- Contact:
Re: Irrlicht 1.8 beta phase
Yeah, addition of Cg support was meant - an important new feature in 1.8
I guess that the problem here is once again the far value/infinity value. Because it only occurs at the very far ends of the room, not when the shadow is near the camera. I didn't play around with the infinity value, though.
I guess that the problem here is once again the far value/infinity value. Because it only occurs at the very far ends of the room, not when the shadow is near the camera. I didn't play around with the infinity value, though.
Re: Irrlicht 1.8 beta phase
I thinked that we already supported Cg in 1.7, so sry Yep, I checked it and when we decrease infinity or increase zfar value shadows looks fine when we are in a room's corner.
Library helping with network requests, tasks management, logger etc in desktop and mobile apps: https://github.com/GrupaPracuj/hermes
Re: Irrlicht 1.8 beta phase
hi,
after i digged a little bit in the direct x 11 driver i found the problem with the wrong textures on meshs.
the problem was that some textures arent power of 2. can we changed the size of all textures to power of 2 before the release or has the driver managed it on his own?
here is a image with before and after: (problem with billboard & faerie)
after i digged a little bit in the direct x 11 driver i found the problem with the wrong textures on meshs.
the problem was that some textures arent power of 2. can we changed the size of all textures to power of 2 before the release or has the driver managed it on his own?
here is a image with before and after: (problem with billboard & faerie)
Re: Irrlicht 1.8 beta phase
I think that this is very good idea to scale a textures from media to POT.
Library helping with network requests, tasks management, logger etc in desktop and mobile apps: https://github.com/GrupaPracuj/hermes
Re: Irrlicht 1.8 beta phase
here is a minor patch for opengl, dx9, nulldevice that reduces the draw calls of draw3dbox to one
patch
now example 12 renders 2 times faster
patch
now example 12 renders 2 times faster
Re: Irrlicht 1.8 beta phase
nice catch for dx11 and it revealed an issue for the render to texture sample
-
- Admin
- Posts: 14143
- Joined: Wed Apr 19, 2006 9:20 pm
- Location: Oldenburg(Oldb), Germany
- Contact:
Re: Irrlicht 1.8 beta phase
Please submit the draw3dbox patch on the tracker. We cannot change these things for 1.8 anymore. Only major bugfixes will be put into 1.8 as we want to release it within the next days.
The media won't be changed. In case the driver does not support NPOT (I doubt this for dx11, though), the texture generation has to scale the image. Due to numerous hw driver incompatibilities, this does not work correctly in all cases. But it's the correct way.
The media won't be changed. In case the driver does not support NPOT (I doubt this for dx11, though), the texture generation has to scale the image. Due to numerous hw driver incompatibilities, this does not work correctly in all cases. But it's the correct way.