[comp.sys.amiga] Sculpt 3D hidden commands revealed

hrlaser@pnet02.cts.com (Harv Laser) (12/14/88)

By popular request.....

Hidden Sculpt 3D commands 
------------------------- 
 
By disassembling a little code, I found some more undocumented
features of the Sculpt 3D ray tracing program. If some of these don't
work for you, check your version. I am using v1.102. If you have an
earlier version, you can get an update from Byte by Byte. The newer
version is supposed to have some optimizations for faster rendering
speeds. 
 
By clicking on the DOWN window, and then pressing CTRL-D you bring up
a requestor that asks you for a magic number. The valid entries and
their effects are described below. 
 
    123     Palette and Exposure lock 
            Enables additional menu selections. COLOR LOCK and COLOR
            UNLOCK are added to the Observer/Mode menu, and LOCK and
            UNLOCK are added to the Observer/Exposure menu. These
            features are described in detail in the documentation for
            the latest release of MOVIE! by Eric Graham. These
            commands lock the palette and exposure of consecutive
            renderings so they may be compressed for animation. 
 
    100     Set mirror recursion depth 
            Brings up a requestor that allows you to change the mirror
            recursive depth value (default is 5). 
 
    101     Set glass recursion depth 
            Brings up a requestor that allows you to change the glass
            recursive depth value (default is 5). 
 
    1044    Set the debug value 
            Brings up a requestor that allows you to set the debug
            value From what I saw, it seems that 0 doesn't output
            debug data, non 0 does send debug data to standard output
            (you should invoke Sculpt 3D from CLI so the output will
            go to the CLI window, or you could probably redirect it to
            a printer or file). Small numbers cause mostly timing data
            to be displayed. Large or negative numbers cause
            additional data to be displayed if the scene has mirrored
            or glass objects. It looked like the code also tested for
            debug values of 3, 4, and 5, but I couldn't see any
            difference in the output. 
 
What puzzles me is why the debug code, and the many tests against its
value are in the release version of the program at all. Why increase
the size of the program, load times, and execution times with runtime
debug tests and code when it could have been conditionally compiled
code, present during development, and absent from the release version.
But this is a small complaint for a very good program. 
 
Steve Hatchett c/o HUBERT bbs (Nevada) 
                   702-322-8877

----------------[end of buffer dumpo]--------------

Harv Laser, Sysop, The People/Link AmigaZone.  Plink: CBM*HARV
UUCP: {ames!elroy, <backbone>}!gryphon!pnet02!hrlaser
INET: hrlaser@pnet02.cts.com
<---open            Push down while turning           close tightly--->

dale@boing.UUCP (Dale Luck) (12/15/88)

Flames from Duck.

In article <9584@gryphon.COM> hrlaser@pnet02.cts.com (Harv Laser) writes:
>By popular request.....
>
>Hidden Sculpt 3D commands 
>------------------------- 
> 
>By disassembling a little code, I found some more undocumented
>features of the Sculpt 3D ray tracing program. If some of these don't
>work for you, check your version. I am using v1.102. If you have an
>earlier version, you can get an update from Byte by Byte. The newer
>version is supposed to have some optimizations for faster rendering
>speeds. 

Postings and activity like this piss me off. Don't you have anything
better to do with your time?  I hope when a new version of sculpt3d
comes out and you undocumented features don't work anymore or are
different that you don't complain about incompatibility.

> 
>What puzzles me is why the debug code, and the many tests against its
>value are in the release version of the program at all. Why increase
>the size of the program, load times, and execution times with runtime
>debug tests and code when it could have been conditionally compiled
>code, present during development, and absent from the release version.
>But this is a small complaint for a very good program. 
> 
>Steve Hatchett c/o HUBERT bbs (Nevada) 
>                   702-322-8877
>


Stuff like this really pisses me off.

   The amount of code added to support the debug stuff and maybe
some unfinished features is probably less that 5% of the total
code size. So instead of loading in 10 seconds it takes 10.5
seconds. My heart bleeds for you, buddy.

 You really don't understand computer software and the support game.
Scuplt3d is an incredably complex program.  It is running on a
tremendous variety of amigas with all kinds of wierd hardware attached
and any manner of software running at the same time.
   If a user has a problem with Sculpt3d, by using the debug features
ByteByByte may be able to get a better idea about what problems may
be occuring in the field. 

-- 
Dale Luck     GfxBase/Boing, Inc.
{uunet!cbmvax|pyramid}!amiga!boing!dale

vic@zen.UUCP (Victor Gavin) (12/17/88)

In article <528@boing.UUCP> dale@boing.UUCP (Dale Luck) writes:
>Flames from Duck.
>
>In article <9584@gryphon.COM> hrlaser@pnet02.cts.com (Harv Laser) writes:
>>By popular request.....
>>
>>Hidden Sculpt 3D commands 
>>------------------------- 
>> 
>>By disassembling a little code, I found some more undocumented
>>features of the Sculpt 3D ray tracing program.
>
>Postings and activity like this piss me off. Don't you have anything
>better to do with your time?

Some people relax in a hot bath, some go jogging, what do you do :-)

Seriously though folks, if Harv thinks his time is well spent wandering through
dis-assembly listings, let him.

Help yourself to an aphorism:
Horses for courses, swings and round-abouts, one mans meat...

>Dale Luck     GfxBase/Boing, Inc.
>{uunet!cbmvax|pyramid}!amiga!boing!dale

		vic
--
Victor Gavin						Zengrange Limited
vic@zen.co.uk						Greenfield Road
..!mcvax!ukc!zen.co.uk!vic				Leeds LS9 8DB
+44 532 489048						England

gsarff@meph.UUCP (Gary Sarff) (12/17/88)

In <528@boing.UUCP> article dale@boing.UUCP (Dale Luck) writes:
>Flames from Duck.
>
>In article <9584@gryphon.COM> hrlaser@pnet02.cts.com (Harv Laser) writes:
>>By popular request.....
     ^^^^^^^ ^^^^^^^
Did you see this?  We the USERS of this computer and software in order to...
>>
>>Hidden Sculpt 3D commands 
>>------------------------- 
>> 
>>By disassembling a little code, I found some more undocumented
>>features of the Sculpt 3D ray tracing program. If some of these don't
>>work for you, check your version. I am using v1.102. If you have an
  ^^^^^^^ ^^^^^^^^^^^^^^^^^^^^^^^^
  see below.
>
>Postings and activity like this piss me off. Don't you have anything
                            ^^^^^^^^^^^^^^^^ once.

>better to do with your time?  I hope when a new version of sculpt3d
It is HIS program after all, he paid for it and presumably owns it.

>comes out and you undocumented features don't work anymore or are
>different that you don't complain about incompatibility.

Yes if someone types control-d and the window doesn't come up then they will
know won't they?  How hard is that?

>
>> 
>>What puzzles me is why the debug code, and the many tests against its
                                                 ^^^^^^^^^^^^^^^^^^^^^^
>>value are in the release version of the program at all. Why increase
>>the size of the program, load times, and execution times with runtime
                                           ^^^^^^^^^^^^^^^  SEE below.
>>debug tests and code when it could have been conditionally compiled
>>code, present during development, and absent from the release version.
>>But this is a small complaint for a very good program. 
>> 
>>Steve Hatchett c/o HUBERT bbs (Nevada) 
>>                   702-322-8877
>>
>
>
>Stuff like this really pisses me off.
                 ^^^^^^^^^^^^^^^^^^^^ twice.  Was this called for?

>
>   The amount of code added to support the debug stuff and maybe
>some unfinished features is probably less that 5% of the total
>code size. So instead of loading in 10 seconds it takes 10.5
IN EXECUTION TIME!!, What if the debug tests are in some of the main ray-tracing
loops, hmmm?  What then?  I'd say, just offhand, that you'd get an
increase in execution time, wouldn't you?

>seconds. My heart bleeds for you, buddy.
                   ^^^^^^^^^^^^^^^^^^^^^ The friendly people of amiga.
5% of the code too, some people DO try to run sculpt3d on a 512K amiga too
you know, a few K can make all the difference in being able to open a screen
or multi-task at all.
>
> You really don't understand computer software and the support game.
>Scuplt3d is an incredably complex program.  It is running on a
>tremendous variety of amigas with all kinds of wierd hardware attached
>and any manner of software running at the same time.
>   If a user has a problem with Sculpt3d, by using the debug features
>ByteByByte may be able to get a better idea about what problems may
>be occuring in the field. 
>
>-- 
>Dale Luck     GfxBase/Boing, Inc.
>{uunet!cbmvax|pyramid}!amiga!boing!dale
>
I hope I do understand computer software, being a systems programmer and
doing device drivers, disk caching optimizations, for multi-user minis
(That have MMU's and a safe OS) and playing with my amiga 2000 in my spare
time, using among other things Sculpt3d.  One of those codes that was listed
(the 123 that locks the color palette from one ray-trace to another) has
been known by the public for some time.  It is ESSENTIAL to the use of
Sculpt3d by itself (along with something like the MAKEANIM and MOVIE PD
programs) to allow some people to make animations.  It was certainly before
any of us lowly users were blessed with Animate 3d because it wasn't available
yet.  You couldn't make an animation unless you could lock the color palette
because the pd programs that put together your iff pictures couldn't handle
a different palette in each frame.  So why did Byte by Byte hide this,
why wasn't it in the menu?  The obvious answer (to my cynical mind 8-)
was that we were all supposed to just wait for Animate 3d.  Only they
could do animations, we couldn't.  Oh well.  The other codes sound useful
too and if they don't work, then they don't.  They aren't documented after
all, and it is Our (mine, harv lasers, anyone else's )programs after all.

I have always been a calm person that just lets things on the net pass
because it is a free forum, I have never responded to any flames before
but something about this flame just upset me so much that I wrote this.
I really do not think that this was called for, if anyone has any shadowy
rights to criticize harv laser or the referenced Steve hatchet or anyone
else for this it is Byte By Byte, not you.  Did you have a bad day or
something?  Mellow out.  Lets all get back to our amigas.


------------------------------------------------------------------------
"Those whom the gods would destroy, they first make mad"
He who steals my core-dump, steals trash

hrlaser@pnet02.cts.com (Harv Laser) (12/20/88)

vic@zen.UUCP (Victor Gavin) writes:
>Seriously though folks, if Harv thinks his time is well spent wandering through
>dis-assembly listings, let him.

Read my posting again. *I* didn't disassemble the thing... see the name of
the guy who did? No no, not that Harv thing, before that. See? He's in
Nevada and runs a BBS?  He's the one. Yeah, him!  We all straight on that
now?  I'm too busy playing Dungeon Master to sit around wasting my time
disassembling Sculpt, even if I knew how to, which I don't.  Those "magic
numbers" have been published elsewhere too... for instance, look in the
docs that come with Eric Graham's dilbm/pilbm/movie programs. 

Harv Laser, Sysop, The People/Link AmigaZone.  Plink: CBM*HARV
UUCP: {ames!elroy, <backbone>}!gryphon!pnet02!hrlaser
INET: hrlaser@pnet02.cts.com
<---open            Push down while turning           close tightly--->