World of Graphics/WOGRAPH.BIN/764.TGA2POV.DOC

Text File | 1992-11-04 | 17KB | 404 lines

                               ===============
                                 TGA2POV 2.0
                               ===============

                    Converts B&W 8-bit Targa files (Type 3)
                               to PoV 1.0 objects

                          Copyright 1992 Scott Steeves


                             In the spirit of PoV,
                       this program is given as freeware.



    TGA2POV is a utility for PoV 1.0.  It will convert B&W uncompressed Targa
images to PoV 1.0 objects.  Being that I'm not a programmer (if I where, would
I be hacking in QuickBasic??), this is a simple program.  It doesn't output
the most optimized code, and it isn't the most optimized program.  But it does
work.  It's too simple not to.
    This was originally created to get some fonts into a couple of animations.
I just jumped into my favorite paint program, and typed the words using a
large font.  I then ran the Targa image through TGA2POV, and I had a PoV
object that I could rotate in the animation.  This is what is was designed
for, but it'll convert anything from a Type 3 Targa to a PoV object.


    Syntax:

    TGA2POV input output [/S] [/Bn] [/1]

    Where:

    INPUT is the Targa file, INPUT.TGA.  The extension .TGA is automatically
put on, so don't put it on the command line.

    OUTPUT is the PoV #include file, OUTPUT.INC.  Ditto about the extension.

    /S turns on smoothing.  More on this later.

    /Bn indicates the bounding level.  n must be a number from 0-9.  More on
this later.

    /1 will scale the object to a height (Y) of 1 unit.  The width (X) will be
scaled proportionately.  The thickness (Z) will not be adjusted, and will be
equal to 1 unit.  If you convert a large image and enable the scaling, you will
want to scale the depth, too.



    TGA2POV will create an .INC file declaring a composite with the same name
(less extension) as the Targa image.  The object will be 1 unit thick (in the Z
direction) and however high and wide the object was in the Targa image.  The
Targa image size has nothing to do with the output.  If the image itself is
1000x1000, and you have only a 2x2 block of black pixels in the image, then the
output will be a 2x2x1 box.
    It also declares a texture called Texture1.  When the .INC file is written,
Texture1 is simply "color red 1" so you'll have to edit the .INC file to get
the desired texture.

===========================================================================

    All TGA2POV does is read in the Targa file, line by line.  Whenever it
comes to a black pixel, it outputs a box{ (1x1x1) at the X,Y coordinates
of that pixel.  That's it!

    Well, it needed a little optimization from that method, so it checks to
see how many continuous black pixels there are in a row, and outputs a
box of those dimensions.  So that if a line has 10 black pixels in a row, then
TGA2POV outputs a box{ 10 units long (along the X axis) and 1 unit high (along
the Y axis) and one unit thick (along the Z axis).  Hardly optimal, but it
works.
    TGA2POV will compute some bounding boxes, which greatly speed the render
over version 1.  See the section on bounding boxes for more info.


    If your Targa file has a block of blacks pixels like this:

    XXXXXX
    XXXX
    XXXX

    TGA2POV will output the following three boxes, one 6 units long, and two
that are 4 units long.  (All of these boxes will be 1 unit high and 1 unit
thick.)  It also creates a bounding box around the boxes, and another bounding
box around the entire object.  (More on the bounding later.)

    An example output for this "image" would be:


#declare Texture1 = texture { color red 1 }

#declare EXAMPLE = composite {
    object {
        union {
            box { < 5  6 -.5>< 9  7 .5>}
            box { < 5  7 -.5>< 9  8 .5>}
            box { < 5  8 -.5>< 11  9 .5>}
        }
    bounded_by{ box{< 4.99  5.99 -.51>< 11.01  9.01 .51>} }
    texture { Texture1 }
    }
bounded_by{ box{< 4.98  5.98 -.52>< 11.02  9.02 .52>} }
scale < 0.333333 0.333333 1 >
translate <-8 -7.5 0>
}

    Scaling
    =======

    By default, TGA2POV makes no efforts to scale the object.  Thus, if your
Targa file has an object that's 100 pixels tall by 50 pixels wide, then the PoV
object will be 100 units tall and 50 units wide.  This way, all objects will be
proportionate to each other from one file to the next.  Since this was designed
to bring some alphanumeric characters into PoV, I decided that it was best not
to scale.  Then, every character done in 36-point Times Roman would be
correctly proportionate to the next.
    However, using the /1 switch will scale the object to a height (Y) of 1
unit.  The width (X) will be scaled equally, thus keeping the same proportions.
The thickness (Z) will not be touched, thus the object will always be 1 unit
thick.

    The objects are made entirely with boxes (and some intersecting planes if
you use smoothing), so you can scale it however you wish.


    Bounding
    ========

    TGA2POV will create bounding boxes around portions of the output
composite. The /Bn option controls how often a bounding box will be output.

    TGA2POV will read in a certain number of lines of the Targa image,
output the necessary boxes, and then output a bounding box to surround this
block of boxes.  It will then read another block of lines, output, etcetera,
until the entire image has been converted.

    If you specify /B1, a bounding box will be output for every 4 lines.
    If you specify /B2, a bounding box will be output for every 7 lines.
    If you specify /B3, a bounding box will be output for every 10 lines.
    If you specify /B4, a bounding box will be output for every 13 lines.
    If you specify /B5, a bounding box will be output for every 16 lines.
    If you specify /B6, a bounding box will be output for every 20 lines.
    If you specify /B7, a bounding box will be output for every 25 lines.
    If you specify /B8, a bounding box will be output for every 35 lines.
    If you specify /B9, a bounding box will be output for every 50 lines.
    If you specify /B0, a bounding box will be output for every 10,000 lines.
This effectively turns bounding off, unless you're insane enough to convert a
200 Megabyte Targa.

    The bounding option defaults to /B3, which is every 10 lines.


    Using this method to compute bounding boxes generates bell curves when
considering render times.  Take an imaginary file, and convert it at /B4.
Rendering the PoV object may take 5 minutes to render.  /B5 takes 4 minutes,
/B6 takes 3 minutes, /B7 takes 4 minutes, and /B8 takes 5 minutes.
    Obviously, /B6 is the best to use with this particular file.  It's easy to
see when you have these results in front of you, but it takes too long to test
each setting.  It would be best if the program could automatically compute
bounding boxes at the optimum setting.  I could not see any easy way to compute
an optimal setting, another than judging by file size.  While just judging by
file size seems like a good idea, a highly complex image may take much longer
than a very simple image of the same file size.  The complex image (a fancy,
cursive font, for example) will require more boxes than the simple (a sans-
serif font) image.  More primitives, more time.


    See the file BOUNDING.DAT for more information.  This file contains a ton
of information resulting from sixty renders, each at 640x480.  It also contains
few hints from what I have seen.  The file EXAMPLES.ZIP contains a few GIFs
which might help a bit, too.

    Please note:
    If you have any suggestions about this method, please let me know.  It
seemed best to me after running the tests.  But I'm not the most experienced
ray-tracer out there, and in light of this, I admit that I might be totally
wrong.  If I am wrong, then please be nice when you tell me.  Thanks.  :-)



    Smoothing
    =========

    Note:
    *****  Smoothing has not been changed from version 1.  It may not even be
worthwhile until I can come up with a better method to get a smaller, smoother
object.  From some tests that I have done, I don't think that smoothing is
worth it at this point.
    Create your image as large as is necessary to have a smooth render.  It
might not always be necessary to create a huge image to get a smooth object,
depending on where you place the object.  If you scale the object to a smaller
size, or if you place it farther away from the camera, you won't notice the
blockiness.  See the files BOUNDING.DAT and EXAMPLES.ZIP for more info.
    Unless somebody loves this feature, I may just dump it from the next
version.

    To continue....


    If you use the "Smoothing" option, TGA2POV will fill in the "stairsteps"
with 1-unit boxes cut at a 45-degree angle.  For example, say your Targa image
had an object like this:
    {Zoomed x2 for greater detail.  :-) }

    XXXXXXXXX
    XXXXXXXXX
    XXXXXXX
    XXXXXXX
    XXXX
    XXXX

    Those stairsteps can look terrible sometimes, especially if the camera is
very close, or if you scale the object much larger.  TGA2POV's smoothing
option can "smooth" the edges by putting in some 1-unit boxes which have been
cut at a 45-degree angle.  The above object would then look like this:

    XXXXXXXXX
    XXXXXXXXX
    XXXXXXX /
    XXXXXXX/
    XXXX  /
    XXXX /

    The outside edges are smoothed off, and the object no longer has that
"blocky" look.


    Some notes on smoothing:

    1)  It adds a lot more primitives to the PoV objects, and thus more
        rendering time.  Sometimes it will double the number of primitives,
        and thus it greatly increases the renderingtime.

    2)  It doesn't always help.  If you convert a large Targa object (Like a
        72-pt "W") then you'll barely see the effects.  Since there are so
        many pixels in the original image, there will be a lot of boxes in the
        PoV object.  You'll have to scale it down to fit it on the screen, and
        the effects of the smoothing will barely be noticable.

    3)  If the stairsteps are more than a single pixel, the corner pieces are
        less noticable, since they're only 1x1x1.  So if you had an object
        like this:  (Actual size)

        XXXX
        XXXX
        XXXXXXX
        XXXXXXX
        XXXXXXX

        You'll only get one corner piece, like this:

        XXXX
        XXXX\
        XXXXXXX
        XXXXXXX
        XXXXXXX

        It doesn't make that much of a difference.  It seems like an option
        best saved for those small images, like 12-point characters.

    4)  It's not a very intelligent option.  That is, it checks no further
        than 1 pixel up or down, and one pixel left or right.  So if you have
        an object like this:  (2x actual size)

        XXXXXX
        XXXXXX
        XXXX
        XXXX
        XXXXXX
        XXXXXX

        Then you end up with two corners pieces, translated to the same
        coordinates.  You'll end up with a little "V", like this:

        XXXXXX
        XXXXXX
        XXXX /
        XXXX \
        XXXXXX
        XXXXXX

    All in all, smoothing looks like an option best suited to small objects.



    "Shadow Lines"
    ==============

    Sometimes, when the face of an object is exactly perpendicular to
the camera,  I have seen shadow lines drawn where two objects meet,
such as the junction of a box and a corner piece.  From what I have
seen, this is rare.  However, it does happen.
    If you see some dark lines in the middle of an object,and you know they
shouldn't be there, then you're probably seeing what I'm talking about.  If
this is the case, simply rotate the object on the X axis by a small amount.
I've had the "shadow lines" disappear by putting "rotate<.5 0 0>" in the PoV
scene file. If you can notice a ½-degree rotation, then you have better eyes
than I.



    Plans for the future
    ====================

    The cut boxes that the smoothing option adds can be done differently.  (I'm
too lazy to do this yet.)  Take the following chuck of code:

intersection{box{<-0 -0 -.5><1 1 .5>}plane{<0 1 0>0 rotate<0 0 45>}
    translate< 5  5 0>}
box { < 6  5 -.5>< 26  6 .5>}
intersection{box{<-0 -0 -.5><1 1 .5>}plane{<0 1 0>0 rotate<0 0 45>}
    rotate <0 0 -90> translate< 26  6 0>}

    That's a corner piece, then a box 20 units long, then another corner
piece. There's no reason why this can't be written with one object.  Just
make the box 22 units long, and intersect the two ends with those planes.
Something like:

intersection {
    box { <5 5 -.5><27 6 .5> }
    plane { <0 1 0> 0 rotate <0 0 45> translate <5 5 0> }
    plane { <0 1 0> 0 rotate <0 0 135> translate <26 6 0> }
}

    I don't know if that's the correct syntax (I'm tired and inexperienced),
but something like that.  At least, we've now got 1 primitive (although it's
a little more complicated) rather than 3.


    I'd also like to do the smoothing a little better.  If the object has a
stairstep that goes over 5 then up 1, the present smoothing does very little.
You end up with a stairstep that goes over 4 places, and angles up 1.
    I'd like to improve it so that a plane cuts this at the correct 5-to-1
angle so that the above stairstep disappears entirely.  Shouldn't be too
hard.  However, if it goes over 1, then up 5, it gets messy.  I'd probably
have to read the entire file into memory, and then test multiples lines up
and down.  I don't if I'm motivated and/or experienced enough to do this with
QuickBasic.

    I'd also like to check into computing larger boxes.  Test the entire image
for any 10x10 blocks of black pixels, and output a 10x10x1 box for each.  Then
test for 9x9 blocks, and so on.
    This might work against those complex images, though.  And it would
probably mean one of two things:  Either the program would have to be able to
fit the entire image into memory; or the program would have to use temp files.
Considering that I'm working in QuickBasic, the first might be impossible
once the image gets large, and the second is slower than hell.  Even with this
version, converting a 1.4M Targa took my 386/25 just over 11 minutes.  The idea
of also having to read and write some temp files makes me want to play Tetris.


    Targa Images
    ============

    TGA2POV reads in Type 3, B&W, uncompressed Targa images.  If your paint
package puts out a different kind of image then you'll have to convert it.
Sorry, but I can't program a GIF decoder, so....

    Whip out your copy of Alchemy (great program) and convert the image using
the following parameters:
    -a10 -c2 -8
    This will convert your image to a Targa, uncompressed without a footer, 2
color, 8-bit file.

    Or, start up Windows, and get into Paint Shop Pro (another great program).
Make sure that the image is only two colors.  Use the "Count Colors" under
"Image" to double check.  If the image has more than two colors, convert it to
two, then convert it to 256 colors.  Check the status bar to make sure that
it's an 8-bit (256 color) image.  Convert it to 256 colors if necessary.  Then
save the image as an uncompressed Targa.

    As long as your program will output an uncompressed, 8-bit Targa, you
shouldn't have a problem.


    Fini
    ====

    If you have any comments, I'd appreciate them.  At this point, the
program does what I want, and I can modify the code when I get to it.
However, if enough people mention that they'd like this improved, then I'll
probably get back to it.  However, I want to trace, and I haven't done a
thing since I finally started this a few days ago.


    Legal Bullwhippy
    ================

    Use at your own risk.  Regardless of what happens, I'm not responsible.
I don't care if you run this program and your computer implodes or starts
singing Barry Manilow songs.  You use it, you're responsible for your
actions.  I make no claims as the functionality of this program, and I have
no idea as to just how much damage this could do if you attempted to convert
a 22 megabyte Targa.  This program isn't complex enough to do any real
damage, but your hard drive could get thrashed if it runs into an infinite
loop.  However, inifinity is limited to 64-bit precision, so it shouldn't get
too far.  Good luck.

    Scott Steeves
    11-04-92