Several bugs/problems | 1 more bug of shadow

[etnlGD]

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

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]));
 

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():

Code: Select all

    
        // update bbox
    if (getSceneManager()->isCulled(this) && Mesh)
    {
        scene::IMesh * mesh = getMeshForCurrentFrame();
     
        if (mesh)
            Box = mesh->getBoundingBox();
    }
    // other stuff omitted 
    // ...
 

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:

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
       }
 

[chronologicaldot]

With the exception of the matrix problem, which was already mentioned in this thread (http://irrlicht.sourceforge.net/forum/v ... =7&t=49131), I don't think the other things you've listed are "problems". The classes aren't optimized, but if you go about optimizing them, make sure the optimizations don't break something else. It's hard to tell what will break without test cases.

Concerning OnAnimate, this extra call to getMeshForCurrentFrame() may be because render() might not be called for some frames but the bounding box might still be needed. The bounding box might be used for other things (e.g. collisions).

Concerning void* Userdata, this would be tricky to serialize, and most of the time it isn't needed. For special cases, you'll probably have to extend ISceneNode anyways.

[etnlGD]

Concerning OnAnimate, this extra call to getMeshForCurrentFrame() may be because render() might not be called for some frames but the bounding box might still be needed. The bounding box might be used for other things (e.g. collisions).

Therefore, getMeshForCurrentFrame() in OnAnmate() can be omitted when node is not culled, isn't it ?
In my opinion, bounding box is just a method to make our program run faster, it needn't to be very precise. Bounding box of everything should only guarantee that it contains all vertices. So every bounding box that contains the exact bounding box of a node should be a bounding box of that node too. Of course we can and should make a min-max-bbox here.

[etnlGD]

I don't think the other things you've listed are "problems".

If I want to support animation blending, then Irrlicht will create JointChildSceneNodes in checkJoints() anyway. It's illogical.

[hendu]

You're correct about the double skinning call, but as chronologicaldot wrote, many people expect the bboxes to be accurate.

I propose pre-calculating all the bboxes on mesh load, for every frame. They only use a couple dozen bytes each, this would remove the need to skin in OnAnimate but also provide accurate boxes.

[hybrid]

Is it possible to blend the bboxes like animations? Otherwise the transition time for all modes at least would contradict the optimization of the pre-calculation. Otherwise this sounds like an interesting option. I guess we really need someone for the animation classes...

[hendu]

Yes, the aabbox code includes a linear interpolation function.