8 Replies Latest reply on Apr 6, 2010 12:34 PM by mchock

    CubeMapGen Source


      I've been working with the CubeMapGen tool as part of a toolchain in a content pipeline for a unannounced x360, PS3, Wii, and Win32 game. I need to be able to have the CubeMapGen executable (or something performing similar operations) run on a windows build machine as a service. The CubeMapGen as it is will not run without being able to display a window (which means I need to have the automated process run as a logged in user without the machine locked, not ideal...).

      To this end I've been looking at the CubeMapGen library. The big problem with the library being that it was built with VS2003, and doesn't have the image loading and exporting functionality that the CubeMapGen executable does. So I'd have to write my own importers and exporters.

      Since I'm feeling extremely lazy and don't want to write my own image loaders and exporters I thought I'd blast out a message asking if it is possible to get the full source for the CubeMapGen tool released.

      Releasing this source would be very helpful. Ideally it would be great if this tool could be put up as a Google Code group allowing other developers to contribute source back to it.


        • CubeMapGen Source

          We are looking into making CubeMapGen an open source project, but I do not yet have a timeframe on when it will be available.

            • CubeMapGen Source

              Just another vote for the source - just the library itself would be enough so it could be used with other compilers / platforms.

                • CubeMapGen Source

                  Another vote.. Pretty, pretty please...

                  I'm a developer with the Vegastrike open source project. I recently produced cubemaps for the entire game using CMG, but we're far less than satisfied with the results. The biggest problem (but not the only problem) is with the edge fix-up hack. It just doesn't work for the smaller mips. The whole idea for an edge fix-up is conceptually erroneous, we think: The correct solution is to map 90 degrees to (texture_size-1); --i.e.: make the centers of the last rows of texels map to a 45 degree angle. This would effectively overlap the edge rows of texels of adjacent sides. Computing filtered values for the border texels of neighboring sides would result in the exact same final color, and there would be no need for edge hacks.

                  This, and many other things we'd like to fix in CMG. Please, let us help you.

                  Alternately, if you wish a non-disclosure agreement, we can do that.

                  But we NEED this problem fixed, ASAP.



                    • CubeMapGen Source

                      And before you ask what the other problems are, --that I believe I could fix easier than I can explain--, here's a couple:

                      1) It's okay to use floating point arithmetic in the sampling loop for the filters; but the sample accumulators need to be double precision. I believe from looking at the results, that you guys are using floats for the accumulators. Floats are terrible when used as accumulators; you get aliasing precision losses (the first sample accumulated gets full precision; the last gets almost NO precision).

                      2) Lots of choices for filters... Cone, disc, gaussian, cosine... But none of them is the "right" filter for shininess modulation. The right filter would be a "Phong" filter:

                      Each mip level corresponds to a blur angle, which in turn corresponds, mathematically, to a shininess exponent. Call it S.

                      Then, the right filter would be,

                      sample_coefficient = pow( cos(angle), S );


                      Other features we'd like to add are:

                      1) Being able to save settings to a file

                      2) Being able to save side order and axis flips, when working with large numbers of existing cubemaps made up of individual textures.

                      3) Maybe... Automatic detection of face order and rotations.

                      4) Optional Auto adjustment of gains and gammas, for when a large set of existing cubemaps need to be "normalized" in brightness and contrast.

                      5) Optional color range stretching, to maximize precision, with correction factors used by CMG saved to a text file with the same name as the cubemap, so that correction data can be sent to the shader by code.

                      6) Batch operations.

                        • CubeMapGen Source

                          Seriously, I'm trying again; but if I get no reply, we'll just have to go ahead and write our own cube map generator, and if so it will be foss, and I can assure you it will work better. Do you want foss competition? So, let's work together.

                          There's really nothing to the algorithm; I don't understand why you'd need to think so much about whether to FOSS it or not to FOSS it. The hardest parts in coding our own cmg would be the user interface and dds encoding; but we'll do it if we have to.