Generation of geometrically correct normalmaps.

[RVS]

Hello to all.
I am Robert Skuridin from Russia, mentioned by Fridger Shrempp here several times. I am physicist-theoretician and I work in the field of physical hydrodynamics.
In spring I contacted Fridger and proposed some ideas about normalmaps (and, in lesser extent, generation of big VTs in general). I am more familiar with Fortran, so my programs were written in Fortran. During one month, Fridger developed a set of C++ programs, referred as 'nmtools'. However, they are not released yet.
Meanwhile, I can provide my own current set of programs and instructions to all interested (as Windows executables with Fortran source code) via e-mail (I don't possess and don?€™t intend to possess a web-site). My programs are probably less flexible, than 'nmtools' (no pipelining, the interface is very crude), but the functionality is exactly the same. They by no way should be considered as an alternative to ?€?nmtools?€™, which are more consistent with the Celestia project on the whole (because in C++), comply to some standards, are multiplatform and have some additional options. I don't have time and possibility for detailed explanations of mathematics involved, you may ask Fridger (and, probably, this will be explained in the documentation for ?€?nmtools?€™). So, I suggest that only persons with basic understanding of VT functionality and file manipulating in Windows should be interested.
My final goal is not distribution of these programs, but the availability of good textures (in particular normalmaps), so I will be very happy, if someone finally creates a good set and distributes it.
Please, make your requests on the Forum in this tread, as I check the mailbox in the profile only episodically. If there will be several requests, I suppose to send one mail to all interested tomorrow.
Additionally, my programs work with little-endian files. The conversion between little-endian and big-endian format can be done by standart means in UNIX-like systems, but in Windows requires some special tool. I find easier to write my own converter for this, but it is quite slow. If required, I can include it as well, but I recommend using something else.
Also, if there will be any interest, the development of analogous utilities for the handling of other types of BIG VTs is possible.

With best regards, RVS

[Fightspit]

Welcome to the Celestia forum RVS
Of course, I am interested about your tool but I just want to know if this tool can generate several levels of VTs.
I want to say you a great thanks if you can send me it by Private Message (PM)

[abramson]

Oh, how I love Fortran. I will be delighted to have your tools, even though I have little time myself, one never knows. You can send them to my email address, it's here below. Many thanks, Robert!

Guillermo

[abramson]

You can send them to my email address, it's here below.

Oops! Sorry, I thought that my email was in my profile. It's abramson at cab.cnea.gov.ar. thanks again.
Guillermo

[RVS]

I sent a letter with my programs to Fightspit (on the address in his private message) and to abramson (on the address on his website), but both letters returned. Next suggestions? I?€™ll send source code without executables in private messages, but this is Fortran with Microsoft extensions, and Fridger had problems, when tried compile earlier variant of this programs five months ago.
RVS

[RVS]

Since RVS (Robert Skuridin) was impatient and sent around his FORTRAN-based Windows programs privately without my consensus and before publication of our joint official distribution (that I coded in C++ for cross-platform use), I have decided to stop collaborating/communicating with him...

It?€™s very interesting, why I can?€™t offer privately my own programs 6 (six!) months after our common programs were done.
Anyway, good-bye and a happy new year!
Robert

[abramson]

It?€™s very interesting, why I can?€™t offer privately my own programs 6 (six!) months after our common programs were done.

Hi, Robert. I'm sorry to hear this. Let me say that, despite my initial enthusiasm, other obligations have kept me away from playing with your fortran sources. If you wish, I will delete them from my system, I have no problem about that. Just let me know.
Happy new year for everybody.
Guillermo

[Fightspit]

Same,

Since the nmtool is available, I have no idea now what I will do with your tool and it is still on my system but if you want I delete it, let me know.

[RVS]

This message is addressed mostly to t00fri. I propose to study the following without any collaboration/communication just for the common good.
The idea is to use a single program to rescale a map from any given size to any required size instead of the current sequence '2pow2->2half->?€¦->2half'. I see the principal advantage in the elimination of round-off errors at each reduction step. Additionally, the entire procedure is somewhat easier. This is only a core part of the program, without any interface etc. It is purely speculative, absolutely not tested, and well may (and even should) include errors and allow optimization.
I suppose 'width' to be entered as an arbitrary parameter and specified in an external script shell to allow a maximal versatility, but something like desired tile size and target VT level may be invented instead.
The case 'ind0min=ind0max' is possible only when width>width0. If only size reduction is performed, this branch is not required.
The algorithm should produce the same result, as '2pow2', when applied to initial non-power-of-two map, but the subsequent maps should be more precise.
The application of the algorithm to 8/24/32 bpp images (where the precision is less than 3 decimal digits per channel, and the relative error is more important), if required, is straightforward.

Code: Select all

 
   double *vertOut = new double[width0];
    short *out = new short[width];
    short *h = new short[width0];

    double mr = (double) width / (double) width0, result;
    int i, j, k;
    int ind0min, ind0max, j00 = 0;

    readRowS16(stdin, h, width0);

     for (j = 0; j < height; j++)
     {
        ind0min = j * height0 / height;
        ind0max = (j + 1) * height0 / height;
        bool flagmin = j * height0 % height;
        bool flagmax = (j + 1) * height0 % height;

        if (ind0min == ind0max)
        {
           if (j00 < ind0min)
              readRowS16(stdin, h, width0);
           for (i = 0; i < width0; ++i)
           vertOut[i] = h[i];
        }
        else
        {
           if (flagmin)
           {
              if (j00 < ind0min)
                  readRowS16(stdin, h, width0);
              for (i = 0; i < width0; ++i)
                 vertOut[i] = h[i] * (mr * (ind0min + 1) - j);
           }
           else
              for (i = 0; i < width0; ++i)
                 vertOut[i] = 0.
           for (k = ind0min + flagmin, k <= ind0max - 1; ++k)
           {
              readRowS16(stdin, h, width0);
              for (i = 0; i < width0; ++i)
                 vertOut[i] += h[i];
           }
           if (flagmax)
           {
              readRowS16(stdin, h, width0);
              for (i = 0; i < width0; ++i)
                 vertOut[i] += h[i] * (j + 1 - mr * ind0max);
           }
        }
           j00 = ind0max;

        for (i = 0; width - 1; ++i)
        {
           ind0min = i * width0 / width;
           ind0max = (i + 1) * width0 / width;
           flagmin = i * width0 % width;
           flagmax = (i + 1) / width0 / width;

           if (ind0min == ind0max)
              out[i] = (short)nint(vertOut[ind0min]);
           else
           {
              if (flagmin)
                 result = vertOut[ind0min] * (mr * (ind0min + 1) - i);
              else
                 result = 0;
              for (k = ind0min + flagmin; k <= ind0max - 1; ++k)
                 result += vertOut[k];
              if (flagmax)
                 result += vertOut[ind0max] * (i + 1 - mr * ind0max);
              out[i] = (short)nint(result);
           }
        }
        fwrite(out, 2, width, stdout);
     }


[t00fri]

There is a forum specially devoted to the various texture tools packages (nmtools, F-TexTools) at Celestial Matters. Any proposals for new features should be discussed there.

http://forum.celestialmatters.org/viewforum.php?f=6

see also the CM WEBsite

http://celestialmatters.org

I have just recently released a substantially optimized version 1.5 of the nmtools, the code of which (nm2pow2, nm2half) has been completely restructured for reasons of speed. The new tools are about a factor of two faster than the original release (1.0.1). The results have been shown to be exactly identical by means of 'nvimgdiff' from the new NVIDIA texture tools.

Bye Fridger