Several bugs/problems | 1 more bug of shadow
Posted: Sat Oct 26, 2013 4:49 pm
I'm not a native English speaker, sorry for my poor English below. 
1.(BUG) matrix4::getScale() return incorrect value when rotation is (0, 180, 0), I modify it to
i.e. Add abs to every parameter for returning vector's constructor
2.(PROBLEM) COctreeSceneNode is slower than MeshSceneNode, I guess modern GPU handle the relating problem better than CPU. Any need to keep it in next release?
3.(BUG/PROBLEM) CAnimatedMeshSceneNode::getMeshForCurrentFrame() has been invoked in both OnAnimate() and Render(), this will slow down the engine significantly while using software skinning. Following code is what I do in OnAnimate():
Now, only when this node is culled, we update its bbox. Otherwise it will be updated in Render method. This may fix the problem with bad smell. I think we can do it better. Looking into the problem we met, I suppose we just want to update the bbox while Animating, right? However bbox is just used to optimize our program, it shouldn't be a bottleneck. So the bbox of node can be larger than its real bbox. Then we can calculate a min-max-bbox, a minimal bbox that contains every single frame's bbox, offline or create it while loading. Then if the node is culled, we can just set the node's bbox to the constant min-max-bbox of the binding mesh.
SKIN MESH IS VERY SLOW, WE SHOULDN'T DO IT EXCEPT FOR RENDERING PURPOSE
4.[PROBLEM] I hope hardware skinning can be supported in next release for its populararity.
5.[PROBLEM] I don't understand the design for CAnimatedMeshSceneNode::TransitionTime. In my opinion, transition should happen in any JointMode, not only EJUOR_CONTROL. Although we can use AnimateJoints() to support animation blending, AnimateJoints() took up extra time to synchronize joints and child nodes(It can be up to 5% of total execute time in my computer according to Visual Studio's performance analysis).
6.[PROBLEM] ISceneNode should hold a property: void* Userdata; then we can integrate irrlicht with other engine easily.
I've learned Irrlicht only a few days. If there is any stupid idea listed above, please point it out directly.
Thanks!
UPDATED:
7. [BUG] The author of CShadowVolumeSceneNode::createEdgeAndCaps(light, svp, bb) must have mistaken the parameter light, which is light position instead, for light direction. Following code can work properly:
1.(BUG) matrix4::getScale() return incorrect value when rotation is (0, 180, 0), I modify it to
Code: Select all
if(core::iszero(M[1]) && core::iszero(M[2]) &&
core::iszero(M[4]) && core::iszero(M[6]) &&
core::iszero(M[8]) && core::iszero(M[9]))
return vector3d<T>(abs(M[0]), abs(M[5]), abs(M[10]));
2.(PROBLEM) COctreeSceneNode is slower than MeshSceneNode, I guess modern GPU handle the relating problem better than CPU. Any need to keep it in next release?
3.(BUG/PROBLEM) CAnimatedMeshSceneNode::getMeshForCurrentFrame() has been invoked in both OnAnimate() and Render(), this will slow down the engine significantly while using software skinning. Following code is what I do in OnAnimate():
Code: Select all
// update bbox
if (getSceneManager()->isCulled(this) && Mesh)
{
scene::IMesh * mesh = getMeshForCurrentFrame();
if (mesh)
Box = mesh->getBoundingBox();
}
// other stuff omitted
// ...
SKIN MESH IS VERY SLOW, WE SHOULDN'T DO IT EXCEPT FOR RENDERING PURPOSE
4.[PROBLEM] I hope hardware skinning can be supported in next release for its populararity.
5.[PROBLEM] I don't understand the design for CAnimatedMeshSceneNode::TransitionTime. In my opinion, transition should happen in any JointMode, not only EJUOR_CONTROL. Although we can use AnimateJoints() to support animation blending, AnimateJoints() took up extra time to synchronize joints and child nodes(It can be up to 5% of total execute time in my computer according to Visual Studio's performance analysis).
6.[PROBLEM] ISceneNode should hold a property: void* Userdata; then we can integrate irrlicht with other engine easily.
I've learned Irrlicht only a few days. If there is any stupid idea listed above, please point it out directly.
Thanks!
UPDATED:
7. [BUG] The author of CShadowVolumeSceneNode::createEdgeAndCaps(light, svp, bb) must have mistaken the parameter light, which is light position instead, for light direction. Following code can work properly:
Code: Select all
for (u32 i=0; i<faceCount; ++i)
{
const core::vector3df v0 = Vertices[Indices[3*i+0]];
const core::vector3df v1 = Vertices[Indices[3*i+1]];
const core::vector3df v2 = Vertices[Indices[3*i+2]];
const core::vector3df lightDir = v0-light;
#ifdef IRR_USE_REVERSE_EXTRUDED
FaceData[i]=core::triangle3df(v0,v1,v2).isFrontFacing(lightDir);
#else
FaceData[i]=core::triangle3df(v2,v1,v0).isFrontFacing(lightDir);
#endif
// omitted
}