Povray - Open Source --- MA_Tussi

Obviously Tussi stands vor Tiny Ugly Science Satellite (and) Impactor. The impactor at the moment is missing, it gets delivered subsequently. Its ordered at SpaceX, so it can take a while.

Tussi isnt pretty and will not in the future, she is a proving-ground only for other macros and functionalities. And will serve as a welcome object in space-related scenes.

Screenplay compatibility

As some others of my packages Tussi ca be controlled with Screenplay in longer animations. Inside her macros she sometimes asks what she has to do and how she has to look like.

How to do this I showed in an Example, the result can be seen on Youtube. Also the whole sourcecode is available in the Screenplay-Zip and should answer the most questions.

Appearanace and functionality

The appearance can modified on different ways. Yo can use the variables at the top of the include-file, or use the 3rd macro-parameter instead as described bit lower.

Also it has some built-in functionality that modifies the visible hardware. The solarcells can be rotated and unfold, the engines activated and other things. For all parameters have a look into the include-file.

Simple example to call Tussi:

#local Params = "sc-angle:90;sc-tilt:-30;engine-active: 1;engine-flame-dist:1.3;";
object {
	TU_Tussi ("", "", Params, "")
	rotate <45,0,0> //Side-view
}

CenterType

The fourth parameter is named CenterType and defines which point of tussi is centered. An empty string means the center of the can will be centered, recommended if you like to rotate her.

With "standing" or "standing-real" all Hardware are in Y+ (ignoring a maybe visible exhaust-plume of the engine), to place her somewhere on a surface, without knowledge how high she is.

Usage of GetParam-Macros

To make Tussis appearance as dynamic as possible, I heavily use the macros MA_GetParam_*() from MA_Helpers. All parameters are stitched together in one string as parameter/value pairs. Many times inside the Tussi-creation-macro you will find calls of MA_GetParams*() to extract the choosen value out of the string.

The definition of all parameters happens in the upper part of the include-file:

/* original default-values defined in ma_tussi.inc */
#ifndef(TU_Params_Default)
	#declare TU_Params_Default = concat (
		";body-dia:            4",
		";body-height:         6",
		";engine-height:       2.0",
		";engine-dia:          1.0",
		";engine-flame-height: 3",
		...
		";sc-angle:            90",
		";sc-tilt:            -40"
	);
#end

/* Creation in an example-file */
#local Params = "body-dia:2";
object {
	TU_Tussi ("", "", Params, "")
	rotate <45,0,0> //Side-view
}

The concat() is used only to list the parameter readable one below the other, certainly they can be stored in one long string (#declare TU_Params_Default = "body-dia:4;body-height:6 ..."). Parameter and value are separated by "=", two pairs of parameters/values by ";".

The defaults gets overwritten by new parameters delivered with the macro-call, in the example above the diameter of the main spacecafts body. Behind the call of MA_GetParams() some of the values gets modified. The last parameter of MA_GetParams() is a default-value which gets returned if the string doesnt contain the choosen parameter. In Our case it is more or less obsolete, because I mention all possible parameter inside the string.

#macro TU_Tussi (mParentName, mNewName, xParams, mCenterType)
	#local mParams          = concat (TU_Params_Default, ";", mParams);
	#local mRadius          = MA_GetParam_F(mParams, "body-dia", 2) / 2;
	#local mHeight          = MA_GetParam_F(mParams, "body-height", 5);
	#local mSolarWingAngle  = MA_GetParam_F(mParams, "sc-angle", 0) * -1;
	#local mSolarWingTilt   = MA_GetParam_F(mParams, "sc-tilt", 0) + 90;
	...

A few times inside the main-macros other macros gets called to create separate parts of the spacecraft. With their call I send them the complete parameter-string, so the sub-macros can look itself for parameter, without direct contact from the outside, an often occuring problem when constructing complex marcros and objects.

#macro TU_Tussi (...)
	...
	#local mSolarWing1 = object {
		TU_SolarWing ( mParams )
		rotate <0, -mSolarWingTilt, mSolarWingAngle>
	}
	#local mSolarWing2 = object {
		TU_SolarWing ( mParams )
		rotate <0, +mSolarWingTilt, mSolarWingAngle>
	}

Inside Tussi I maybe use this function a littlebit too often, but I wanted to test the functionality in a real model. As it is we could save all parameters in separate variables, it would boil down the same thing.

Commonly I make use of it in other ways. When I create a new macro I insert all values directly as they are needed and often it works for a long time. There is no need for parameters.

#macro GetSphere(mParams)
	sphere { 0,1
		texture { pigment { color rgb <1,1,1> } }
	}
#end
GetSphere("")

But sometimes I need the same macro but with slightly changed behavior, and then I can insert new parameters and code, without testing all the source-code that uses this macro. The old values are the defaults which gets overwritten if passed inside the parameter-string delivered by the first macro-parameter.

Resulting in:

#macro GetSphere(mParams)
	#local mPos  = MA_GetParam_V(mParams, "position", <0,0,0>);
	#local mSize = MA_GetParam_F(mParams, "size", 1);
	#local mCol  = MA_GetParam_V(mParams, "color", <1,1,1>);
	sphere { mPos, mSize
		texture { pigment { color rgb mCol } }
	}
#end
GetSphere("")
GetSphere("position: <2,2,7>; size: 3; color: 1,0,0;")

Looks a littlebit complicated but I dont do it just for fun. The more the own collection of source-code grows over time, the more helpfull this type of modification will be. When my sourc-code for the ISS will get published, constructions like this will appear everywhere.

Download

ma_tussi.7z => 680 kB 7-Zip, Version 1.0 from 29th December 2024