HUD (billboard behavior)

[Patrice Terrier]

Mike

Do you have any idea of what could cause a strange behavior when using #billboad with the newmtl plane4 in the attached project.

Both size and color are affected.

Indeed it should always look like on the screen shot.

[Patrice Terrier]

Here is a reworked version.

I have solved my billboad color problem…

There seem to be a scale factor of 960 / 680 = 1.4117647, aka: almost 30% bigger when using billboard compared to the correct size.

[Patrice Terrier]

And here is the gambler version, working around the oddities 

[Michael Lobko-Lobanovsky]

Wow, this looks amazing, my friend, thank you!

And I appreciate your (rare) experimentation with CrazyBump too.

However, being a sci-fi lover and Elon Mask admirer as I am, I cannot agree with your interpretation of the planet Mars.

• Your geoid (or rather marsoid) normalization is weird or unavailable at all. It's a sphere normalized as a cuboid. I don't know of any SW that can do such queer things. Or you probably spent this last weekend with a logarithmic ruler in hand to normalize it manually.
• Your normal map is all inverted. The martian Grand Canyon became a mountain range, and your "ambient occlusion map" of the planet is most likely a displacement/height map generated from its non-inverted (correct) normal map with shape recognition set at 99.
• There isn't a single minor detail of martian surface that any of those maps would enhance.

I realize this was apparently your first attempt at CrazyBump and the weird result you've got was probably attractive in this particular test case, but normally one would generate all the maps from one particular normal map setting in one session enhancing each map with its own set of options and leaving the normal map settings alone. Whenever the normal map settings change, the other maps should be re-generated accordingly.

Below is my variant of Mars mesh textures. They are just a tad exaggerated but the mesh is going to be transparent and therefore more washy and faded to an extent. That is why we're making the details more prominent to compensate for somewhat lesser sharpness.

Uncomment the #bump parallax meta (remove the extra leading sharp) to see thousand-miles high and low peaks and abysses. Prefer to observe the planet at a distance that allows the parallax approximation artifacts to be smoothed out. Just for lulz, you may also type #bump steep and watch the dry planet's sand deserts turn into oceans of fluid clay. Weird but may be handy in some cases, I think.

[Patrice Terrier]

Mike

My purpose was not to have a faithful mars planet, all i wanted is to have a red one with glowing parts to create a gloomy effect.
And the main purpose of this project was to understand why the billboard material size is slighty larger than when using a simple quad mesh.

About my sphere, it is a regular one using standard UVW mapping, the icosahedron is just there for the purpose of geometric HUD display, and to create a star effect hover the sphere (at the intersection of the 2 meshes).

Thank you anyway for the texture set.

[Michael Lobko-Lobanovsky]

My friend,

Billboards use a different render proc than all other meshes. It restores the BB virtual quad (not the original size mesh!) from its center pos and mesh radius, which it assumes to be half the quad diagonal. Without the original BB mesh aspect ratio (the mesh height, breadth and depth aren't stored in the mesh structure, but rather its center pos and radius only), they are sufficient to only restore a 2D quad or circle, or 3D cube or sphere.

The quad is relatively easy to create programmatically and re-orient parallel to the screen plane regardless of the actual viewing angle. See the void billBoard() proc in mobj.h that does just that. The BB virtual quad assumes that it is mapped to the corners of BB texture that has to be equilaterally quadric as well to avoid image distortion. That was exactly why I asked you to always create BB textures as equilateral squares. You have two options:

1. If the original BB mesh you hardcode in the model to have something to get the center point pos and radius from is not a quad, then map it to a square texture. Just make sure the mesh corners are mapped to the exact portion of the square texture you need. Then fill the square texture's unused areas with transparency for the BB restored virtual quad to maintain the same aspect ratio that the original mesh uses.

2. If you hardcode the actual BB mesh as a square, make sure its texture is again square and mapped to the mesh corners. Then draw whatever images with whatever aspect ratios into the transparent texture quad as needed. This way you will always get to see on the ObjReader screen exactly what you're seeing in your static 3D editor when modeling your current WIP.

Am I making myself clear enough this time to explain why you had to adjust your texture sizes by some 1.4.... times to fit their image sizes from your C4D editor into ObjReader? 1.4 is roughly how larger the virtual quad's diagonal (2 times the mesh radius) is going to be relative to the original non-square BB mesh average side. (Pythagoras pants and stuff, you know...)

[Patrice Terrier]

My friend

I am well aware of that, and i can grant you that both my mesh and the related texture are perfectly equilateral, hence my trouble. I think i shall have to look closely at the code to understand what is going wrong.

[Michael Lobko-Lobanovsky]

Patrice,

Again, plane4 has a weird texture size of 1808x1808 pixels. Who knows what code nVidia, GDImage64, and OpenGL mipmapping procs use to bring those queer horz and vert sizes to decent respective P.O.T.'s?