g_alpha is the fading over time (will be 0.1 at 10% of the time etc). The dissolvemap, which is a noisemap with values distributed across the 0-1 spectrum. Alpha test will succeed when value is above 0.5.

I offset it with 0.5 to get the median values to fade in at around 0.5. If I do not use this offset, the first values (those that are 1.0 on the dissolvemap) will first start trickling in at 0.5. By offsetting it, I can get them to fade in at 0.333~. Which is also quite late...

To close the 0.333~ gap, I offset the g_alpha by 0.333~ from the main program, while scaling the timing by 0.666~, effectively removing the start gap while keeping the timing intact.

Anyway, the fading kinda works, but the bulk of the fading takes place in a too short time span. I have watched it up-close and it does fade over the entire time, but the beginning kinda trickles in and is not noticable from afar, and similar with the ending, making both beginning and ending not noticable. The result is a fast fade, that looks too much like a pop.

So my questions are:

- Is it possible to make a better distribution equation for the final color? (I have tried with exponentials but couldn't arrive at anything satisfactory)

- Can the problem be the dissolvemap? (IMO it looks fairly evenly distributed, I attached it (original is in .bmp, I saved as .jpg to save space here)

I am currently working on animations, and wanting optimal performance, I shifted loading multithreaded. When I shifted my refpose to loading multithreaded, however, something wierd happened. Suddenly my animated model collapsed after a few animations cycles and was completely distorted.

I tried to change back to non-multithreaded, and there was no error. Then I wrote out everything to files: Animations, boneweights, animationpose, refpose - everything. And I could see no difference between the multithreaded and the non-multithreaded.

After a long time of digging down to isolate the problem, I finally found out, that the bones of final pose, which are in matrix form, had its members _44 distorted. Since all the math takes place with quaternion+position, except an inverse-value that I have pre-calculated on each refpose-bone, the final bone-matrices would never have their members _44 overwritten through the animation, except when the inverse-matrix of the refpose would be continously multiplying with it, slowly skewing it.

I could solve this by resetting the final bones every iteration before using them, but I found it a bit unsatisfactory, that I would even have to do that, because it works fine when loading single-threaded.

Another solution was to set all the _44-values in the main thread once it gets delivered from the loading-thread.

- is it a normal problem, that floats created on one thread lose accuracy when transferred to another?

- should I reset the finalbones-matrices from iteration to iteration no matter what? Is it too unsafe to rely on a 100% good float?

PS: This debugging session must have taken me some 20 hours in all, what a nightmare.

The ODE demos run with the Z-axis as being up/down. I have tried to change this to work with my system, where Y-axis is up/down.

I got it to work with a heightfield. Unfortunately, there is an unfixed bug in the heightfield, so it will fail in certain areas. The solution is to use a tri-mesh.

So I took a look at the trimesh-demo to learn how to convert my heightmap data to an ODE trimesh. After failing again and again, I finally went to the root and tried to convert the ODE trimesh itself to use a gravity vector of -Y instead of -Z as it has now, while at the same time changing the trimesh to the new orientation.

I believe I have translated everything correctly, but the demo still fails, and behaves quite like the test in my own program.

I will write the entire file here.

Search for "Y-Conversion" to find the areas I changed from the original.

The original can be seen commented out at the bottom.

The easiest would probably be to substitute this one with the original while testing, if you have the ODE system installed.

Is ODE only working with Z-axis or did I miss something in conversion?

I wish to transfer an instancing vertex, that beyond the matrix has four very small integers, two of which are indexes into a texturemap shared by several different other objects - a texturemap holding many different kinds of grass and flowers. I call each of them "frames" and the texture a "framemap"l The last two define the dimensions (x/y) of the frame map, that the indexes point into.

From the max dimensions and the indexes, the shader will be able to calculate the offset into the frame map. I found, that this should be cheaper to transfer than simply the float offsets, if I used special types.

The integers are so small, that I can get away with only 4 bits for each, as I allow the frame map to have maximum 16x16 frames. Combined the indexes- and dimensions-variables will occupy 4x4=16 bits.