Page 2 of 3
Posted: Sat Apr 04, 2009 12:57 pm
by L o
Sorry I have to ask again.
I just cannot put textures on the faces.
Code: Select all
vertbuf->Material.MaterialType = video::EMT_SOLID;
vertbuf->Material.Shininess = 20.0f;
vertbuf->Material.SpecularColor.set(255,255,255,255);
vertbuf->Material.setFlag(video::EMF_LIGHTING, true); // enable dynamic lighting
video::ITexture* sample_texture =
SceneManager->getVideoDriver()->getTexture("/home/philipp/cprogs/ODF/odfl_reader/fake_texture.tga");
(whereas vertbuf is my meshbuffer)
The result: the whole level has the same color and it does not look like any of my textures.
I tried looking into the documentation, but I only found the Doxygen-stuff. Aren't there any tutorials about writing a meshloader?
Posted: Sat Apr 04, 2009 3:50 pm
by hybrid
Just check the SMaterial API, you'll find a place to attach the textures.
Posted: Sat Apr 04, 2009 3:55 pm
by L o
Oh sorry, I forgot to post this line:
Code: Select all
vertbuf->Material.setTexture(triangle_count, sample_texture);
(whereas triangle_count is iterated in a for-loop)
What's missing?
Posted: Sat Apr 04, 2009 5:32 pm
by hybrid
triangleCount? You should use 0 for most material types. Iterate over the meshbuffers/materials for other parts of the mesh.
Posted: Sat Apr 04, 2009 5:59 pm
by L o
Shall I create a meshbuffer for each material? Because, I don't see a function in the meshbuffer which lets me append a texture to a specified face.
Posted: Sat Apr 04, 2009 8:30 pm
by hybrid
Yes, that's exactly the idea with meshbuffers. There are several reasons why you want to add a new meshbuffer. Logical grouping is one, but the main reason is to add a new material. Meshbuffers have the same material for all faces of that buffer.
Posted: Sun Apr 05, 2009 10:29 am
by L o
So does it mean that some meshbuffers contain the same verts? Did I get that right? oO
So for sharing memory, could I put a vector of vertices into my loader and then just give the references to each meshbuffer? Is it allowed to put multiple references on one variable in C++? oO
Posted: Sun Apr 05, 2009 10:45 am
by hybrid
If you have multiple materials at the very same 3d position you'd need duplicated vertices, one for each mehsbuffer. Don't know what you mean by references in this context.
Posted: Sun Apr 05, 2009 12:33 pm
by L o
core::array wants a reference:
So can I have a vertices and then push back its references in different arrays? (because I get strange valgrind SIGSEGV errors after the mesh is loaded)
Posted: Sun Apr 05, 2009 1:20 pm
by L o
OK, I found out that two references on the same variable are allowed.
Now that I put all in seperate meshbuffers, it is displayed wrong. Valgrind says, that memory is accessed which was deleted, which was latelely allocated using the push_back() function:
Code: Select all
face_buffer->Vertices.push_back( odfl_verts.at(second_point) );
These segfault errors occur AFTER the mesh is loaded.
Is a reallocation segfault issue known?
Posted: Thu Apr 09, 2009 10:09 pm
by L o
Code: Select all
for(unsigned int count2=0; count2 < face_count; ++count2)
{
SMeshBuffer* face_buffer = new SMeshBuffer;
ODFLFile->read(&connects, 2);
short start_point, second_point, third_point;
ODFLFile->read(&start_point, 2);
ODFLFile->read(&second_point, 2);
face_buffer->Vertices.push_back(odfl_verts.at(start_point) );
face_buffer->Vertices.push_back(odfl_verts.at(second_point) ); // !!!
for(short connect_count=1; connect_count < connects-1; ++connect_count)
{
ODFLFile->read(&third_point, 2);
face_buffer->Vertices.push_back( odfl_verts.at(third_point) );
face_buffer->Indices.push_back(start_point);
face_buffer->Indices.push_back(second_point);
face_buffer->Indices.push_back(third_point);
second_point = third_point;
++triangle_count;
}
odfl_faces.push_back(tmp_face);
mesh->addMeshBuffer(face_buffer);
face_buffer->drop();
}
The line with the !!! seems to cause the segfault. The vertice I push back is ok, so I think the face_buf->Vertices is the problem.
Posted: Sat Apr 11, 2009 4:49 pm
by L o
Please Help Me
Posted: Sat Apr 11, 2009 8:47 pm
by hybrid
Well, your second index seems out-of-bounds. Simple like that.
Posted: Sat Apr 11, 2009 9:38 pm
by L o
No, definetely not. It would have throw()n an exception in this case.
Posted: Sat Apr 11, 2009 11:36 pm
by hybrid
Well, push_back won't bail out either.