Mesh Combiner

[Brainsaw]

A month later, sure! It's no problem to use it in your code download. I wrote this code to help people, not for recognition; so if it helps you help people, that's even better!

Nice to hear. Didn't yet find the time to wrap it into a scenenode, but that's a hi-prio on my to-do list.

[Kuzy]

Hello mesh combiner experts,

I got a problem with the lighting/material of my combined mesh.
It looks completely different to the original. What do I have to change in the combined mesh to get the same appearence as the original?

Original:

Combined:


Thanks in advance,
Kuzy

[mongoose7]

Maybe you need to fix the normals?

[Kuzy]

already tried
k->setMaterialFlag(EMF_NORMALIZE_NORMALS,true);
or do you mean something different...

[mongoose7]

Yes, I mean, make them point in the right direction. Are you using lighting or are we just seeing gourard shading?

[Kuzy]

First: thanks for your answer.

I just started to learn about lighting and just played around with the flags.
Yes, you see gourard shading in the first picture...
If I turn it off it looks similar (but lighted in a differnt way

Original meshes:


The combined mesh just stays the same...

By which code would I set the a different normal direction to my mesh?

[Lonesome Ducky]

Hmm, I'm very confused as to why this isn't working correctly. It may be that I coded the normal transformations wrong, but I doubt it. If the materials had any special attributes before combining, you'll need to set the attributes again after combining. If that does not work, could you send me a copy of your mesh so I can fix the problem?

[Kuzy]

First: Ducky you did really great work. The speed up, I get by using your combiner is incredible. THANK YOU!
Back to my problem:

I already compared the mesh-material of the original to that of the combined one and found no difference.
Now I have a guess, but no solution:

I create the cubes out of single planes for each different side. When I used cubes, I had problems with the visibility of the cubes after combining (see picture).


If I look from the oppsite direction to my mesh, everythink looks ok, but the lighting seems to be different from the original as well.
It's not too easy to give my mesh to you, because it is generated on the fly. So I have no file to share. I could only save the whole scene.

[polylux]

Ducky,
thank you for this great piece of work!
Sadly, I am unable to use it in my project as the combineMeshes function never returns leaving cpu load and memory usage at around 100%.
I'm doing nothing more than just combine 50 static meshes representing trees (all static, nothing fancy).
Are there any known problems with it?

Thank you,
p.

[Lonesome Ducky]

@Kuzy:
Looks like a Z-Ordering or backface culling issue to me. Are you sure that the material type is non-transparent and z-write and z-buffer are enabled? If all else fails, you can send me some source code that reproduces the problem. If neither of those are good for you, try enabling the debug data to show the normals and see if there is a difference between the normals of the uncombined and the combined so I know if normals are the problem. Sorry that it's being such a hassle.

@polylux:
I'm not sure why it's not returning. It's not a problem I know of, since a while back there was a user who combined 2500 of the dwarf models with no hitch. You can try some debugging to see where it's catching, or send me the model so I can further look at the problem.

[polylux]

Thanks for your quick answer.

Meanwhile I did some debugging. The spot is the CRectPacker::fill(...) function which - dunno yet why - never increments mNumPacked after the first iteration.

cpp Code: Select all

// Fill the pack with rects
void CRectPacker::fill(int pack) {
        if (isPackValid(pack)) {
                for (int x = 0; x < mRects.size(); x++) {
                        if (!mRects[x].packed) {
                                if (fits(mRects[x],mPacks[pack])) {
                                        ++mNumPacked;
                                        split(pack,x);
                                        fill(mPacks[pack].children[0]);
                                        fill(mPacks[pack].children[1]);
                                        return;
                                }
                        }
                }
        }
}

This leads to neverending push_backs in the arrays mPacks and mRoots in the calling function ::pack() using up all my memory. I assume it's got smth to do with the textures? Though there's nothing fancy about them...

Hope that clarifies a bit.

Thanks,
p.

[Lonesome Ducky]

Very strange. Maybe the texture ends up not being able to fit, but I thought I coded it to allow enough padding to keep it safe. You may have the "perfect storm" of textures . Try switching out some textures to see if that works, and if so I'll know what needs to be fixed.

The texture atlas allocates space according to total estimated area, but if you have certain combinations of sizes, there will be blanks space left that may cause the actual total area of the atlas to be above the allocated. Anyway, if that didn't make sense, a better idea instead of changing the textures will be to pass a different tolerance variable on creation.

[polylux]

Very strange. Maybe the texture ends up not being able to fit, but I thought I coded it to allow enough padding to keep it safe. You may have the "perfect storm" of textures . Try switching out some textures to see if that works, and if so I'll know what needs to be fixed.

The texture atlas allocates space according to total estimated area, but if you have certain combinations of sizes, there will be blanks space left that may cause the actual total area of the atlas to be above the allocated. Anyway, if that didn't make sense, a better idea instead of changing the textures will be to pass a different tolerance variable on creation.

Yep, that did the trick. It was the trunk's texture, sizewise being far from what's a squared texture. Maybe that's the problem?

[Lonesome Ducky]

Yeah, most likely! Thanks for bringing this to light, I'll have to figure out a better method for packing and update it. Glad it's working, though!
In fact, a faster and always working method would be to not allocate any certain size. Instead, we'll put the textures in this empty space, then continue placing them next to each other in the position that adds least to size. That way we can have good positioning that always works. I really shouldn't have used the method I did, since it's really made for fitting the textures into a specified size which we don't really know what it will be. You've just given me something to do for the weekend!

[polylux]

Yeah, most likely! Thanks for bringing this to light, I'll have to figure out a better method for packing and update it. Glad it's working, though!
In fact, a faster and always working method would be to not allocate any certain size. Instead, we'll put the textures in this empty space, then continue placing them next to each other in the position that adds least to size. That way we can have good positioning that always works. I really shouldn't have used the method I did, since it's really made for fitting the textures into a specified size which we don't really know what it will be. You've just given me something to do for the weekend!

Hahaha, glad I helped to keep you 'entertained' during the weekend!

Cheers,
p.