[fixed] Billboard changes

[greenya]

Next message is not about "latest" svn commits but about revision 3983.
It is not critical but it is not that much time passed (2 weeks ago) after adding this commit, so maybe you decide to change something in close future.

1. We have inconsistency in naming:
a) setWidths() and getWidths() operates with "startEdgeWidth" and "endEdgeWidth" while setColor() and getColor() operates with "topColor" and " bottomColor" but indeed related to same terms;
b) i suggest to remove ending "s" in set/getWidths() OR add it to set/getColor();

2. get/set Height problems:
a) getHeight() is absent, but now we can call getSize().Height (since Height is the only field which we can be sure in);
b) setHeight() is absent, now if we need to set new height correctly, we should do next code:

Code: Select all

float s, e;
m_BillboardSceneNode->getWidths(s, e); // save widths
m_BillboardSceneNode->setSize(core::dimension2d<f32>(111, newHeightValue)); // "111" can be anyhting else
m_BillboardSceneNode->setWidths(s, e); // restore widths

3. Deprecation. I don't know about setSize(), actually its viable and valid in some point, BUT getSize() should be deprecated. (in my opinion both should be marked as deprecated).

4. Next one am not sure in, but want to report.
When i get 07.Collision example and test different width, i set "topWidth" to 20, "Height" to 20 and "bottomWidth" to 4 i am getting next result:

a) as you see kind of mix-up here (what is top and what is bottom; i checked OpenGL and DirectX, both have same result);
b) not sure, something wrong with texture coords, because billboard looks skewed (but it should look like trapezoid);

Thank you.
And sorry for wall of text above, i swear i tried to be short

[hybrid]

Ok, the start/end thing was not correctly adapted in the IBillboardSceneNode.h file. The source files were all correctly changed already. I've fixed this. The interface names are also now changed. Even further than you suggested. I've made an overload for setSize and getSize, which also takes and gets the height value. This should allow to get/set the values more easily and reduces the number of different names for methods. Hence, we will also keep the old getSize/setSize as is, the differences in size handling are clearly marked in the docs.
The bug is not clear to me. I've added a test case to render a trapezoid billboard and that worked correctly. I'll have a look.

[greenya]

The bug is not clear to me. I've added a test case to render a trapezoid billboard and that worked correctly. I'll have a look.

Sorry, i wasn't clear enough.
So to see what i talking about i take 07.Collision example, go to line "bill->setSize(core::dimension2d<f32>(20.0f, 20.0f));" and add after it one more line.
The image shows what do i mean:

So i see 2 problems:
- upside down trapezoid
- skewed texturing

[hybrid]

Yeah, I understood what you meant, but I was wondering why it worked for me when I tested the functions. Now that I checked my example, I realize that I only enlarged the billboards on top. Narrowing the billboard top makes the problem much more apparent. I'd also say that centering both edges will make the billboard look far more pleasant. I'll have to check this part. The rest of the changes will be commited right now.

[hybrid]

Ok, examined this problem. The centering actually works quite good. However, if the two widths differ significantly, one of the two triangles forming the quad shrinks to a very thin line. Due to the texture interpolation, the above result happens. There's probably no way around, unless we triangulate the billboard further. That's a larger change, though, as we need to handle several optimizations for this to work properly. Just avoid too large differences for now.

[hybrid]

Another idea here, but for now I'll close this problem... It could be enough to have three triangles for non rectangular billboards with rather good texturing. This would be ok as overhead, so we could add it later on. We might even use a more general approach and add a tesselation parameter and get more detailed meshes for billboards. We also plan for a generic view adjustment animator, which could take arbitrary meshes then to align with the camera... So many things left to do. But this one here cannot be easily fixed, so we take it as is. The problem is documented.