This is likely to generate one or two unintelligable responces...

I'm currently working on - ok, well actually I'm currently working on about
half a dozen things; I usually am! But anyway, one of the things I'm
currently working on is me optical (laser-powered) Enigma machine. I've had
about 4 goes at it now, and every time the code gets more and more
complicated, and it gets harder and harder to follow what's happening, never
mind change anything.

This is probably one of the most complicated scenes I've ever attempted! (My
usual work consists of a few spheres, some texturing, and one of POV-Ray's
advanced features - photons, media, that sort of thing.) The only other
thing I've ever made which was this complex was when I tried to make a model
of a 4-stroke engine. I eventually gave up on that because it got too
complicated.

Anyway, clearly this doesn't bother anyone else. So I was just wondering...
how do you folks build complex scenes who's sources can still be read and
modified? (Or are you all just supremely fluky and get it perfect first
time? ;-)

Not a very specific question I know, but let's see what kinda answers I
get...

nam et ipsa scientia potestus est!
Andrew.

Post a reply to this message

Hm. How do I do it?

Rather heavy commenting on very excessive scenes, breaking
stuff into readable parts (several #declared objects that
are stitched together later), and using excessive commenting
to know what I've actually modelled, where it belongs
etc. If I'd use diagrams for reference, I'd probably save
those to disk and use the names I've been given (or have
given) from those diagrams, but I hardly do that.

Most of the time, my code is pretty readable, because my
scenes aren't heavily complicated, but drawing some
simple sketches helps a lot, even for more simple scenes.


--
Tim Nikias
Homepage: http://www.digitaltwilight.de/no_lights/index.html
Email: Tim### [at] gmxde

> This is likely to generate one or two unintelligable responces...
>
> I'm currently working on - ok, well actually I'm currently working on
about
> half a dozen things; I usually am! But anyway, one of the things I'm
> currently working on is me optical (laser-powered) Enigma machine. I've
had
> about 4 goes at it now, and every time the code gets more and more
> complicated, and it gets harder and harder to follow what's happening,
never
> mind change anything.
>
> This is probably one of the most complicated scenes I've ever attempted!
(My
> usual work consists of a few spheres, some texturing, and one of POV-Ray's
> advanced features - photons, media, that sort of thing.) The only other
> thing I've ever made which was this complex was when I tried to make a
model
> of a 4-stroke engine. I eventually gave up on that because it got too
> complicated.
>
> Anyway, clearly this doesn't bother anyone else. So I was just
wondering...
> how do you folks build complex scenes who's sources can still be read and
> modified? (Or are you all just supremely fluky and get it perfect first
> time? ;-)
>
> Not a very specific question I know, but let's see what kinda answers I
> get...
>
> nam et ipsa scientia potestus est!
> Andrew.
>
>
>

Post a reply to this message

> Anyway, clearly this doesn't bother anyone else. So I was just
wondering...
> how do you folks build complex scenes who's sources can still be read and
> modified?

Usually, my scenes end up having the following structure:

// so that i can remove certain elements for fast renders, i usually put
these in here...
#declare usethisthing = yes;
#declare usethatthing = no;
#declare usetheotherthing = yes;

#declare skymediacolor = <.3,.3,1>;
#declare skymediatype = 2;
// ...and more variables that make quick modification of the scene easy

camera {
location <blah,blah,blah>
// insert 10 other commented out locations here
look_at 0
}

// light sources here

#if (usethisthing)
...
#end

#if (usethatthing)
...
#end

#if (usetheotherthing)
...
#end

 - Slime
[ http://www.slimeland.com/ ]

Post a reply to this message

3db6dd90@news.povray.org...

> Anyway, clearly this doesn't bother anyone else.

Oh now it really does. My main scene files usually have 500-2000 lines
(without meshes) and I often reuse material from previous scenes so keeping
them organised and readable is a real issue.

> So I was just wondering...
> how do you folks build complex scenes who's sources can still be read and
> modified?

1) Comments, lots of them and visible separators between chunks of code
(like objects).
2) Indenting
3) Consistent names for objects, textures etc. For instance, size variables
in the x direction will get named xSomething.
3) Depending on what you're working on, generous use of include files. I'm
more into having everything into the same file now (apart the meshes of
course) but when objects can be autonomous putting them in separate include
files can help keep the chaos in check. .

Apart that, I don't believe in strict rules, it really is scene-dependent.

G.


--
**********************
http://www.oyonale.com
**********************
- Graphic experiments
- POV-Ray and Poser computer images
- Posters

Post a reply to this message

Two words: Hierarchy. Modularity.

  Try to build a logical hierarchy with your scene and make the different
parts of this hierarchy modular (eg. by encapsulation).

  There will probably be some main objects in your scene (which are composed
of tons of subobjects). One way of encapsulating is to put each one of
these big independent objects in their own files (which are then included
in the main pov-file). In these files use #local as much as possible
(which is a great keyword for encapsulation).
  If you are using algorithms to generate objects/locations/whatever, try
to make it as abstract as possible (usually with the use of #macros).
"Abstract" in this context means that the macro declaration does not
imply nor fix the way the macro is internally implemented (or if this is
not possible, then it should do so in a minimalistic way).

  Big objects should form a hierarchy. For example, don't put every and
each one of the primitives it's composed of in one big union, even though
this could be possible. Declare (with #local whenever possible) logical parts
of the object (as unions or whatever) and join them to form bigger logical
parts, etc, and at the end union all the biggest parts together to form
the whole object.
  If these parts can have different positions and orientations (eg. the arms
of a robot), don't fix these parameters inside the object definition, but
make it more abstract (that is, use identifiers to position and orient the
objects, and declare these identifiers in a logical place where they can
be easily found and modified). Also design the parts in such a way that
moving them in a logical way is as easy as possible (eg. to rotate the
arm of the robot it's enough to just modify a declared angle value).

-- 
#macro M(A,N,D,L)plane{-z,-9pigment{mandel L*9translate N color_map{[0rgb x]
[1rgb 9]}scale<D,D*3D>*1e3}rotate y*A*8}#end M(-3<1.206434.28623>70,7)M(
-1<.7438.1795>1,20)M(1<.77595.13699>30,20)M(3<.75923.07145>80,99)// - Warp -

Post a reply to this message

Thanks for the responces so far people. Going to have a go at doing some of
this stuff...

Andrew.

Post a reply to this message

Andrew Coppin <orp### [at] btinternetcom> wrote in message
news:3db6dd90@news.povray.org...

Here are a few things which I do. Some mentioned already, some not. I am
probably breaking some rules here, because I don't have any programming
experience except for SDL and a tiny bit of C++ which I learned off the net.

**Create a new folder for each project.

**Create a folder within that folder to store files which I will likely not
need again

**Save macro files with an *.inc extension

**Save object files like macro generated mesh and union objects which will
not be further edited with a *.txt extension. This hides the files when
looking in the folder for pov extensions and allows you to see only these
files by selecting *.txt from the drop-down menu. (at least in windows)

**Naming conventions. I use: My_Macro, MY_MACRO_PARAMETER, my_file, and
MyVariable.

**File naming conventions. I prefix each descriptive file name with the file
"type." This makes a file easy to locate when I want to open it. example:
create_dish.inc, view_building.pov, math_triangle.inc, mesh2_cover.txt etc.

**Create several versions of a macro or hide less often changed macro
parameters with the method I described in the "Macros in Macros?" thread.

**Comment *every* line of code

**Put a good description of every file and the date of the current version
at the top of the file in case I make an updated version from scratch or my
file name becomes unclear to me

**Keep parts of the scene in separate files so I can switch them off and on.
This works better for me than bool switches and #if blocks because the
mechanism is hidden more.

**Make a sample scene at the bottom of each macro page with a full scene set
up. I comment the scene out, but leave it there so I have a quick example of
what the macro does and the effects of the various parameters.

**Include my included object name declaration in my PoV file. Maybe an
example is better.
<included object file>
#macro Name_Object (NAME)
  #local NAME = mesh2 ..........
#end
<pov file>
#local UpperPlatform = 0;
Name_Object (UpperPlatform)
This makes for a lot of typing, but I don't have to remember the name I used
a month ago when I made the include file, and anyone looking at the file
will not have to wonder where the Hell the variable UpperPlatform came from.

**When writing a short macro, I give very long names to the parameters so
that it will be very clear what they do. I then rename them within the
macro.
example: #macro Compare_Vectors (COMPARE_THIS_VECTOR, TO_THIS_VECTOR)


That's all that comes to mind right now.
 -Shay

Post a reply to this message

in news:3db804f8@news.povray.org Shay wrote:

> **Create a new folder for each project.
> 
> **Create a folder within that folder to store files which I will
> likely not need again
> 
> [...]


More or less what I do. One addition, to the projectfolder I create one 
subdirectory named 'include' where all used include files go, third party 
ones and personal ones. In POVRAY.ini I have a line:
   'Library_Path=.\include' 

Ingo

Post a reply to this message