Hi,

I would like to know, how you manage to keep track of the things in your
more complex scenes, 'cause I've problems with this.

I try to indent properly most of the time and that helps a lot to understand
what happens within one object or an CSG. But when it comes to declared
functions, predefined textures and objects, it becomes a lot more difficult.
I group these things by there categories, i.e. functions in one block marked
with comments at the beginning and the end, objects in another block, whole
parts of the scene in a third block and the scene at the very end. I put the
global_settings, lights, camera and background/sky most of the time at the
very beginning of the file.

That works, but I find myself often scrolling about large parts of the
scene, cause if I have to change the length of an iso-wood-beam, I have to
change the rbox-function, too and so on. But if I group this function with
the isosurface declaration, I break my block-scheme and it will probably be
much harder to use the same function elsewhere.

So, how are you doing these things?

Marc-Hendrik

Post a reply to this message

On Mon, 12 Feb 2001 13:53:52 +0100, Marc-Hendrik Bremer wrote:
>That works, but I find myself often scrolling about large parts of the
>scene, cause if I have to change the length of an iso-wood-beam, I have to
>change the rbox-function, too and so on. But if I group this function with
>the isosurface declaration, I break my block-scheme and it will probably be
>much harder to use the same function elsewhere.
>
>So, how are you doing these things?

I find that the best way to organize my code, though it takes a little
longer, is to generalize to the point of excess.  Macros are good for this,
as are good old fashioned include files.  I try to put everything that
has to do with a single physical object into one file, and everything that
has to do with the stage in another file, and finally include them all
into one big scene that's nothing more than #includes and object placement
and lighting and a camera.  I also try to have a test scene #ifdef'd at the
bottom of each include file, so I can preview the objects or the stage as
I model them.

Now, more about that "generalizing to the point of excess":  Basically, I
try to parameterize everything, so if that lamp needs to be a little taller
to fit in the scene, I just have to change one number and it becomes taller.
If it needs to be fatter, change one number and it's fatter.  This leads to 
a long list of variables at the beginning of the file, but it serves three
noble purposes:

First, it makes the object (which is in its own include file, remember) far
more portable to other scenes.  Reusability is good.

Second, it makes it very easy to use multiple variations of the same object
in the same scene without a lot of work, should that become necessary.

Third, it makes the object declaration itself far more readable, because
each magic number has a name that describes its purpose.

-- 
Ron Parker   http://www2.fwi.com/~parkerr/traces.html
My opinions.  Mine.  Not anyone else's.

Post a reply to this message

In article <3a87dce9@news.povray.org>, "Marc-Hendrik Bremer" 
<Mar### [at] t-onlinede> wrote:
>So, how are you doing these things?

Well, I make use of the "bookmarks" feature in the interface I'm using, 
if I find myself going to any particular place often.

If a file starts getting too large, I'll pull all of a certain category 
out (for example, all texture definitions) and put them into a separate 
file. I'll also look for macros and definitions that I might want to use 
in *other* scenes, and put them into the appropriate include file in my 
secondary includes directory.

Jerry
-- 
http://www.hoboes.com/jerry/
"Give a man a fish and you feed him for a day. Teach him to fish, and you've
depleted the lake."--It Isn't Murder If They're Yankees
(http://www.hoboes.com/jerry/Murder/)

Post a reply to this message

I tend to have everything in one file, and quite often copy wood textures
and the like into my main file.  

I have lights, camera and box (faster than plane), at the top. 

Then create the objects seperating each one with a comment line that's
easy to read and has the object name in it like:

// *************************  Open_Green_Box   ********************

Then at the bottom of the file I place my objects.  You can see examples
of my code on my web page.  I sometimes move the camera to the bottom of
the file because the object that I'm working on is always the last one 
before the object placememnt statements, I always work on an object untill
it's completely finished and then move on to the next object. 

As Ron mentioned I usually have a test variable at the top of my file so 
that I can turn transparency off on some objects to make tests go much 
faster. 

-- 
Cheers
Steve              email mailto:ste### [at] zeroppsuklinuxnet

%HAV-A-NICEDAY Error not enough coffee  0 pps. 

web http://www.zeropps.uklinux.net/

or  http://start.at/zero-pps

  6:52pm  up 10 days, 20:31,  2 users,  load average: 1.15, 1.32, 1.32

Post a reply to this message

Marc-Hendrik Bremer wrote in message <3a87dce9@news.povray.org>...
>Hi,
>
>I would like to know, how you manage to keep track of the things in your
>more complex scenes, 'cause I've problems with this.


Include files.  Lots of include files.
Textures usually go in one include file.  Each object or group of related
objects goes in another.  I have my include files set up so I can either
render them separately or as part of the main scene.

--
Mark

Post a reply to this message

Marc-Hendrik Bremer wrote:
> 
> Hi,
> 
> I would like to know, how you manage to keep track of the things in your
> more complex scenes, 'cause I've problems with this.
> 
> So, how are you doing these things?

My scripts use the following conventions:

CSG brackets are marked with the object being put together, such as:

union { // the camera
  union { // the camera case
    box { ... }
    sphere { ... }
    cylinder { ... }
    // etc...
    texture { CameraTexture }
  } // end of the camera case
  difference { // the lens
    sphere { ... }
    sphere { ... }
    material { LensMaterial }
  } // end of the lens
} // end of the camera

I always indent (or at least try to indent) each level of nesting.
An indent of two spaces is enough for me; your mileage may vary.

A lot of my .inc files make use of variables passed on by the calling
script.  The first thing in the .inc is code defining those values
that I may have neglected:

#ifndef(RobotArmed)
#local RobotArmed=false;
#end

In my current IRTC project (which will feature Rusty, Domo, and Rosie),
I have one script file which positions the robots, another that places
the camera, others that place the static objects, build the robots, etc.

Hope this helps,
John

Post a reply to this message

Marc-Hendrik Bremer <Mar### [at] t-onlinede> wrote:
: That works, but I find myself often scrolling about large parts of the
: scene

  That's exactly why there's an #include statement...
  It's perfectly possible to make your scene in several source files.

-- 
char*i="b[7FK@`3NB6>B:b3O6>:B:b3O6><`3:;8:6f733:>::b?7B>:>^B>C73;S1";
main(_,c,m){for(m=32;c=*i++-49;c&m?puts(""):m)for(_=(
c/4)&7;putchar(m),_--?m:(_=(1<<(c&3))-1,(m^=3)&3););}    /*- Warp -*/

Post a reply to this message

This is my approach also. A holdover from my programing days.

Ron Parker wrote:
>
<snip> 
> I try to put everything that
> has to do with a single physical object into one file, and everything that
> has to do with the stage in another file, and finally include them all
> into one big scene that's nothing more than #includes and object placement
> and lighting and a camera.  I also try to have a test scene #ifdef'd at the
> bottom of each include file, so I can preview the objects or the stage as
> I model them.
>

Post a reply to this message

If the file gets really big, strip common items out to include files, such as
textures. Then use highly visible comments to seperate portions of the large
file

// ********************
// * Things and stuff *
// ********************

(I try to avoid the /*...*/ style comments when possible so that if I later want
to exclude a large chunk of code I can use them to comment it out and nothing
will interfere.)

I notice a lot of instructional references use a sort of comment margin; if you
want to comment on a specific line tab over a certain distance and comment there
so that all your comments line up, and it's like you have a column of psuedocode
running down the right-hand side of the text.

--
David Fontaine  <dav### [at] faricynet>  ICQ 55354965
My raytracing gallery:  http://davidf.faricy.net/

Post a reply to this message

In article <3A8B4F3C.84255D7F@faricy.net>, David Fontaine 
<dav### [at] faricynet> wrote:

> (I try to avoid the /*...*/ style comments when possible so that if I 
> later want to exclude a large chunk of code I can use them to comment 
> it out and nothing will interfere.)

You do know that POV-style /*...*/ comments can be nested, right? The 
C-style /*...*/ comments often interfere with my work, because they 
don't nest, but I've never had a problem with the POV-style ones.

-- 
Christopher James Huff
Personal: chr### [at] maccom, http://homepage.mac.com/chrishuff/
TAG: chr### [at] tagpovrayorg, http://tag.povray.org/

<><

Post a reply to this message