I am trying to create a library of POV-Ray components to be used in creating 
model rocket designs. (The same considerations would apply to any type of design 
application, though.) I need to make fins, fin sets, nose cones, fuselage size 
reducers, and other components all modular so that the rocket being modeled can 
be altered at will. If I were using a commercial design program this wouldn't be 
a problem, I guess, but the whole point here is to make it POV-Ray based and 
release it to the public domain.

Okay, so how do I do this? I have included a simple rocket file to show you what 
I am doing. Note that the surface texture is wrong; I still don't know how to 
paint a regular surface on to a curve. Heh. This is a farily accurate rendering 
of an actual model rocket I fly all the time:

   http://www.theschraderfamily.com/Marty/Images/SlugLaunch.jpg


// Rocket basic.pov

#include "colors.inc"
#include "textures.inc"

#global_settings { assumed_gamma 0.75 }

#declare AirframeColor = <1, 1, 1>;

/* Dimensions are in inches, since that is how
it is supplied from the airframe vendor */

#declare AirframeLength = 9.66;
#declare AirframeDiameter = 1.63;
#declare NoseConeLength = 4.67;
#declare FinBase = 2;

#default {
     texture { pigment { color AirframeColor } }
     finish { ambient 0.1 diffuse 0.9 }
}

background { White * 0.71 }

#declare Pov = (AirframeLength + NoseConeLength) / 2;

/*
camera {
     location <0, Pov, -(Pov * 2.5)>
     look_at  <0, Pov, 0>
}
*/
camera {
     orthographic
     location <Pov, 0, -(Pov * 1.8)>
     look_at  <Pov, 0, 0>
}

// main lighting
light_source {
     <0, AirframeLength, -10>
     color White
     shadowless
}

#macro Airframe(Diameter, Length)
cylinder {
     <0, 0, 0>,
     <0, Length, 0>, Diameter / 2
     pigment { checker White, Black scale 0.5 }
     rotate <0, 45, 0>
}
#end

#macro NoseCone(Diameter, Length)
#declare Radius = Diameter / 2;
lathe {
     bezier_spline
          4,
          <0, 0>,
          <Radius, Length * 0.3>,
          <Radius, Length>,
          <Radius, Length>
     rotate <180, 0, 0>
     translate <0, Length, 0>
}
#end

#macro Fin(Diameter, Base, Radian)
prism {
     linear_spline 0, 0.05, 3, <0, 0>, <Base, 0>, <0, Base>
     rotate <270, 0, 0>
     translate <Diameter / 2, 0, 0>
     rotate <0, Radian, 0>
}
#end

// ----- Final rocket -----
#macro Rocket(Diameter, BodyLength, NoseLength)
union {
     Airframe(Diameter, BodyLength)
     cylinder {  // launch lug
         <0, 0, 0>,
         <0, 1.5, 0>, 0.125
         pigment { color White }
         translate <(Diameter / 2), (BodyLength / 3), 0>
         rotate <0, 45, 0>
     }
     union {
         NoseCone(Diameter, NoseLength) translate <0, BodyLength, 0> texture {
             pigment { color Black }
         }
     }
     Fin(Diameter, FinBase, 0)
     Fin(Diameter, FinBase, 90)
     Fin(Diameter, FinBase, 180)
     Fin(Diameter, FinBase, 270)
}
#end

union {
     Rocket(AirframeDiameter, AirframeLength, NoseConeLength)
     rotate <-15, 30, 270>
}

Post a reply to this message

Marty Schrader nous apporta ses lumieres en ce 2007/08/17 15:44:
> I am trying to create a library of POV-Ray components to be used in 
> creating model rocket designs. (The same considerations would apply to 
> any type of design application, though.) I need to make fins, fin sets, 
> nose cones, fuselage size reducers, and other components all modular so 
> that the rocket being modeled can be altered at will. If I were using a 
> commercial design program this wouldn't be a problem, I guess, but the 
> whole point here is to make it POV-Ray based and release it to the 
> public domain.
> 
> Okay, so how do I do this? I have included a simple rocket file to show 
> you what I am doing. Note that the surface texture is wrong; I still 
> don't know how to paint a regular surface on to a curve. Heh. This is a 
> farily accurate rendering of an actual model rocket I fly all the time:
> 
>   http://www.theschraderfamily.com/Marty/Images/SlugLaunch.jpg
> 
Pack the macros for the components in an include file. Include required 
informations inside that include file.

Some components may best be modeled as meshes: ex.: fins.
Any part with linear sides can be modeled as cylinders and cones. This include 
the main parts as airframe, couplers, nose cones and size reducers/expanders.
Make all parts lined up along a specific axis. Have all parts expand from a 
common plane: base situated at <0,0,0> and expanding toward +Y.


-- 
Alain
-------------------------------------------------
War is an instrument entirely inefficient toward redressing wrong; and
multiplies, instead of indemnifying losses.
Thomas Jefferson

Post a reply to this message

Okay, this is the kind of thing I am trying to sort out. If, for instance, I 
want to make a nose cone component, how do I specify the creation of that shape 
without any reference to whatever other parts may be there in the scene already? 
How do I go about creating macros or whatever so that individual parts can be 
included or not without affecting other components?

Post a reply to this message

Marty Schrader nous apporta ses lumieres en ce 2007/08/17 18:04:
> Okay, this is the kind of thing I am trying to sort out. If, for 
> instance, I want to make a nose cone component, how do I specify the 
> creation of that shape without any reference to whatever other parts may 
> be there in the scene already? How do I go about creating macros or 
> whatever so that individual parts can be included or not without 
> affecting other components?
You create the macro to take radius and lenght as parameters, with, optionaly an 
offset value to raise it to some elevation. A reducer/expander will take 2 
radius and a lenght: Bottom_Radius, Top_Radius, Lenght.
It's then a simple mather of summing the various lenght of the preceding parts 
to calculate the amount of translation to apply to the next part.

You simply call the macro with parameters setting the base diameter and lenght 
of the one element you want to show. You can then translate/rotate that object 
as you wish.

If you use an image_map to add a texture, or use a texture like checkers, you 
should use warp{cylindrical} to map that texture on the basicaly cylindrical 
part. Take a look to the documentation for the use of warp.

-- 
Alain
-------------------------------------------------
You know you've been raytracing too long when you have ever said "I don't need 
no steenking modellers!!!"
Stephan Ahonen

Post a reply to this message

Marty Schrader <mar### [at] parsecsystemsinccom> wrote:
> Okay, this is the kind of thing I am trying to sort out. If, for instance, I
> want to make a nose cone component, how do I specify the creation of that shape
> without any reference to whatever other parts may be there in the scene already?

The way to not affect other components is to keep your namespace
clean/consisitent and as Alain said, choose some standards like always
orienting things a certain way.  So if you have multiple nosecone types, if
it were me I'd do something like #macro NoseCone_Type_1() rather than
NoseCone()  Still, objects that have already been placed in a scene won't
be deleted even if their names get overwritten.

> How do I go about creating macros or whatever so that individual parts can be
> included or not without affecting other components?

You can always put one macro per include file as some people (not myself)
advocate.  #ifndef() is very handy for checking to see if something's been
included already or not.

#charles

Post a reply to this message

Ahh, I begin to see now. I need to add some sort of translation argument to the 
macro to indicate where in the scene the object is rendered. Then there would be 
a sort of "management" component that tells every other component where it 
starts and stops, essentially. Okay, I can work with that.

The selection of standards will be critical so that all the components work 
together. I will need to put some thought into this. Thanks for the help.

Post a reply to this message

Yeah, modularity is always a hassle when you are working with something that 
reads like C and lacks the objectivity of C++. Heh. The #ifndef thing has been 
around for decades.

I'm thinking that I might be able to add some sort of object abstraction by 
resolving namespaces through nested includes. This could be a dead end, of 
course, but I won't know until I try it or until somebody steers me toward a 
solution or a reason why it can't be done. Thanks for the assist.

Post a reply to this message

> Yeah, modularity is always a hassle when you are working with something 
> that
> reads like C and lacks the objectivity of C++. Heh. The #ifndef thing has 
> been around for decades.
>
> I'm thinking that I might be able to add some sort of object abstraction 
> by resolving namespaces through nested includes. This could be a dead end, 
> of course, but I won't know until I try it or until somebody steers me 
> toward a solution or a reason why it can't be done. Thanks for the assist.

One way to handle variables is just to use global variables and use #ifndef
and #declare to set default values in your include. Private variables in
your include can just be #local.  You might end up having a few variables
to determine which components to add when the #include is called...
Then just call your #include to create each rocket instance. The drawbacks
of this method are potential name collisions, and the need to reset some
global variables if you #include multiple objects. The positive is that
you don't need to set all the values every time you want a simple rocket.

Another way to do it is to pass all the values to macros, use #local
and have a "tree" of macros. The "rocket" macro might call the "fin"
macro, etc. Then for fins only you could just call the "fin" macro
directly to create an object. The drawback of this method is that
if you have a large number of variables they will all need to be passed
to the main macro. The positive is that you only need to #include your
file once to call multiple rocket instances, with no name collisions.

Or you can use a hybrid of the two methods. Use global variables,
don't bother with #ifndef, just #include at the top, and then call
into macros to create objects instead of multiple #includes.

Post a reply to this message

Good ideas. I'm already beginning work along these lines. Certain considerations 
can be tossed aside, such as rendering more than one rocket per scene. This 
whole project is meant to be used as a supplement to something like Rocksim or 
SpaceCAD, where the user can try out various lengths of airframe, transitions, 
nose cones, fin configurations, colors, stripes, etc. My plan was to make a 
design tool that simply creates a 3D rendering for appearance and sanity check's 
sake, not one that actually does any of the engineering calculations.

Of course I have to work out the baseline parameters that all rocket designs 
will share, but the trick will be creating a scheme for easily specifying how 
paint is applied, how custom fins are shaped, how external details are added, 
and so on. I don't expect to get this going overnight.

Post a reply to this message