change color of part of a custom node

[MyGrandmaWheels]

Hi to everyone!
I have 2 questions for you guys, piled up during these days of sourceforge ko, but I start only with the more pressing.

I need to dynamically change the colour of specified faces of a custom scene node, and I have some problems.
my node is made by triangles, in fact I render with this line of code in my render() method:

Code: Select all

smgr->getVideoDriver()->drawIndexedTriangleList(vertices, VertIndNum, indices, triangles.size());

now, I need to highlight some faces of this node, for a sort of selection by the mouse, ok?
I thought to work on the vertices colour; so I implemented a member function of the same scene node class that, if the ray determined by the mouse intersect a triangle, change its colour:

Code: Select all

vertices[selTri->idxFirstVertex].Color = SColor(255, 255, 255, 0);
vertices[selTri->idxFirstVertex + 1].Color = SColor(255, 255, 255, 0);
vertices[selTri->idxFirstVertex + 2].Color = SColor(255, 255, 255, 0);

I also implemented a function to restore the original colour if it it's not selected anymore.
All this stuff, in the end, it works. But sometimes my application crash: looking in the call stack, while it's doing the render() function.

Anyway, before going deep in implementation details, I'd like to have some opinion about the method to do that: I don't know if my way it's the correct one to render the selection of part of a triangle custom node.
Help me please!

[CuteAlien]

I guess it depends on selTri->idxFirstVertex (and +1 and +2) contents if this works.

[MyGrandmaWheels]

ok, CuteAlien; now, assuming that my approach is suitable, I give some more details; so I describe the function I use to check the mouse ray.
First of all, PC3DModelSN is the class implementing the scene node; in the class declaration, as public, I have
 

Code: Select all

 
struct PCTriangle {
    triangle3df triangle;
    int idxFirstVertex;
};
 
// triangles of  3D model
core::array<PCTriangle> triangles;
PCTriangle *selTri;
 

so, selTri is a pointer to instance of the struct I use to store the only fundamental data, the idxFirstVertex, that is the index of the first vertex of the triplet that determines a triangle.

Code: Select all

bool PC3DModelSN::selectPlaneByTri(line3df valRay) {
    if (vertices == nullptr)
        return false;
    
    // check if the ray intersect a triangle
    vector3df outIntersection;
    f32 minDist = FLT_MAX;
    selTri = new PCTriangle;
 
    for (int i = 0; i < triangles.size(); ++i) {
        if (triangles[i].triangle.getIntersectionWithLine(valRay.start, valRay.end, outIntersection)) {
            f32 d = (valRay.start - outIntersection).getLengthSQ();
            if (d < minDist) {
                minDist = d;
                *selTri = triangles[i];
            }
        }
    }
 
    if (minDist < FLT_MAX) {
        // triangle found
        vertices[selTri->idxFirstVertex].Color = SColor(255, 255, 255, 0);
        vertices[selTri->idxFirstVertex + 1].Color = SColor(255, 255, 255, 0);
        vertices[selTri->idxFirstVertex + 2].Color = SColor(255, 255, 255, 0);
    
        return true;
 
    }
    
    return false;
}

do you think is there something messy in this coding?

[CuteAlien]

Are you certain your vertices are ordered in groups of 3 for triangles?
Because usually only indices are like that. So typcially you would have something like:
vertices[indices[selTri->idxFirstIndex]] because otherwise the next 2 might point to the wrong vertex or even outside the array. I really can't tell much more without seeing what you are really doing - you are hiding too much to analyse this code.

Also in case you haven't seen it yet - Irrlicht has an ITriangleSelector interface and several function to create those selectors. Those are probably pretty similar to what you are coding here. They are a collection of triangles created for an kind of mesh.

[MyGrandmaWheels]

Yes, I'm pretty sure of the consistency of vertices; In fact, more or less, it works.
Anyway, you're right, is quite impossible for you debug my code here! I don't expect that!
The real sense on my thread is: "I need to distinguish dynamically part of the triangles of my 3d custom solid, just like in a selection; is a good idea change the colour of the appropriate vertices?"

Furthermore, I realize that this approach has drawbacks: first of all, the selection receive the same material settings of the 3d model (lighting, in particular) and that's not good.

So I'm planning to implements in another way: I think to create a second scene node made of only the selected triangles and to render it overlapping the 3d model.
Of course it's not so simple: the triangles of this second node would be a duplicate of corresponding triangles of the 3d model, right? So I would experience some z-buffer fighting between the two nodes, right?
I thought to manage it by the PolygonOffsetFactor, so I created a simple test and it seems encouraging.

But there are things I can't understand.

In my test I render the same 3d model two times: first, like solid; after, like wireframe.
This is the code (I think it's easy to understand):

Code: Select all

void PC3DModelSN::render() {
    
    video::IVideoDriver* driver = smgr->getVideoDriver();
 
    material.Wireframe = false;
    material.Lighting = true;
    material.MaterialType = video::EMT_SOLID;
 
    driver->setMaterial(material);
    driver->drawIndexedTriangleList(vertices, VertIndNum, indices, triangles.size());
 
    material.Wireframe = true;
    material.Lighting = false;
    material.PolygonOffsetFactor = 1;
    material.PolygonOffsetDirection = EPO_BACK;
    
    driver->setMaterial(material);
    smgr->getVideoDriver()->drawIndexedTriangleList(vertices, VertIndNum, indices, triangles.size());
    
}

with this 2 lines

Code: Select all

    material.PolygonOffsetFactor = 1;
    material.PolygonOffsetDirection = EPO_BACK;

there's no z-buffer fighting between the solid and the wireframe: the wireframe is very well visible IN FRONT of the solid, and this is the first thing I can't understand: why EPO_BACK? if I set EPO_FRONT, I have the solid that overlap the wireframe... why??

furthermore:
I experimented various material.PolygonOffsetFactor, from 1 to 7. It seems it doesn't change anything; the only setting that make the difference is 0, that cause the z-buffer fighting.

What I am missing?

[CuteAlien]

Sorry, I never worked with that. From code I see it's basically that in opengl:

Code: Select all

 
        if (material.PolygonOffsetDirection==EPO_BACK)
            glPolygonOffset(1.0f, (GLfloat)material.PolygonOffsetFactor);
        else
            glPolygonOffset(-1.0f, (GLfloat)-material.PolygonOffsetFactor);
 

So maybe you can find out more about it when googling for glPolygonOffset.


Beside that it sounds like something that could work in theory.

You might also want to take a look at example 07 which does something similar.