Standards: For some of the big ones, I see scaling, rotation and translation
as a fact of life when you're placing objects in SDL.  If you use other
peoples' #includes, I'd say expect to let people make their objects in
whatever measurement system and coordinate handedness they want.  But from
the opposite standpoint, when you go to make #includes that other people
might use just make sure it's documented and flexible/easy to use:

1. Document what coordinate and measurement systems it's in, and where the
origin is in relation to it.

2. Add commented-out lines to convert handedness (etc) if you're feeling
nice.

3. If your #include uses macros to create objects, make sure they're
flexible enough to handle different situations.  E.g. it would be better
for the macro to define an object/union to be placed by the user, giving
them a chance to modify/convert scale etc, than for the macro to also place
the object(s). Otherwise, the macro should be sufficiently parameterized.

4. Include a sample scene (like most do)! or... one thing I like to do is
make #inc's self-renderable.*


Charles


PS
*(Defines variable Main_POV_File if it does not already exists at the
beginning of the file, and then uses strcmp() on this variable at the end
of the file to determine if it should use a sample scene & camera.  I.e., a
convienient way to get a preview which can be easily defeated by somebody
not wanting to use this system.)

E.g. my "manager desk.inc" starts with this line:
#ifndef(Main_POV_File) #declare Main_POV_File = "manager desk.inc"
#ifdef(Red) #declare Main_POV_File="nRed already definedn"#end
#ifdef(camera) #declare Main_POV_File="nCamera already definedn"#end
#debug Main_POV_File #end


PPS, it'd be really cool if POV-Ray had a built in string constant named
main_pov_file or main_scene_file or primary_sdl_file or something like that
based on whatever file is the first one parsed.

Post a reply to this message